mysterious SrvOpen/VNetRoot corruption

4: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

ATTEMPTED_WRITE_TO_READONLY_MEMORY (be)
An attempt was made to write to readonly memory.  The guilty driver is on the
stack trace (and is typically the current instruction pointer).
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fffff804272ee429, Virtual address for the attempted write.
Arg2: 01000001de5ec121, PTE contents.
Arg3: ffffa20c46501ff0, (reserved)
Arg4: 000000000000000a, (reserved)


4: kd> .cxr; k
Resetting default scope
Child-SP          RetAddr           Call Site
ffffa20c`46501df8 fffff804`21d50e57 nt!KeBugCheckEx
ffffa20c`46501e00 fffff804`21c1f786 nt!MiRaisedIrqlFault+0x363
ffffa20c`46501e50 fffff804`21e3c356 nt!MmAccessFault+0x3e6
ffffa20c`46501ff0 fffff804`22d621e9 nt!KiPageFault+0x356
ffffa20c`46502180 fffff804`22d6241c rdpdr!SmartPtr<DrDevice>::operator=+0x25
ffffa20c`465021b0 fffff804`22d78a74 rdpdr!GetDeviceFromRxContext+0x4c
ffffa20c`465021e0 fffff804`2a4bc419 rdpdr!DrIoControl+0x54
ffffa20c`46502270 fffff804`2a4cdb52 rdbss!RxLowIoSubmit+0x1a9
ffffa20c`465022e0 fffff804`2a473e86 rdbss!RxCommonDeviceControl+0x1c2
ffffa20c`46502350 fffff804`2a4ae9e6 rdbss!RxFsdCommonDispatch+0x616
ffffa20c`465024c0 fffff804`22d701f9 rdbss!RxFsdDispatch+0x86
ffffa20c`46502510 fffff804`21c37595 rdpdr!DrPeekDispatch+0x1e9
ffffa20c`46502570 fffff804`27a2e918 nt!IofCallDriver+0x55
ffffa20c`465025b0 fffff804`27a2e476 mup!MupiCallUncProvider+0xb8
ffffa20c`46502620 fffff804`27a2e3ad mup!MupStateMachine+0x56
ffffa20c`46502650 fffff804`21c37595 mup!MupFsdIrpPassThrough+0x16d
ffffa20c`465026c0 fffff804`26328282 nt!IofCallDriver+0x55
ffffa20c`46502700 fffff804`26325353 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x652
ffffa20c`46502780 fffff804`21c37595 FLTMGR!FltpDispatch+0xa3
ffffa20c`465027e0 fffff804`220606be nt!IofCallDriver+0x55
ffffa20c`46502820 fffff804`220b4d2d nt!IopSynchronousServiceTail+0x33e
ffffa20c`465028c0 fffff804`220b4de6 nt!IopXxxControlFile+0xc7d
ffffa20c`46502a00 fffff804`21e404e5 nt!NtDeviceIoControlFile+0x56
ffffa20c`46502a70 00007ffd`7acffa74 nt!KiSystemServiceCopyEnd+0x25
0000002c`12d7f788 00000000`00000000 0x00007ffd`7acffa74


4: kd> .frame /c /r 4
04 ffffa20c`46502180 fffff804`22d6241c rdpdr!SmartPtr<DrDevice>::operator=+0x25
rax=0000000000000000 rbx=fffff804272ee419 rcx=0000000000000000
rdx=fffff804272ee419 rsi=ffffc78283ff7810 rdi=ffffa20c46502278
rip=fffff80422d621e9 rsp=ffffa20c46502180 rbp=ffffa20c46502278
 r8=0000000000000000  r9=ffffc7828229d410 r10=fffff80421c33940
r11=ffffa20c46502320 r12=ffffc7828229d400 r13=ffffc7827abb2060
r14=fffff80422d6b950 r15=fffff80422d6b000
iopl=0         nv up ei pl nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040202
rdpdr!SmartPtr<DrDevice>::operator=+0x25:
fffff804`22d621e9 f0ff4310        lock inc dword ptr [rbx+10h] ds:002b:fffff804`272ee429=00a024b4









NTSTATUS rdbss!RxLowIoSubmit(PRX_CONTEXT RxContext, PIRP Irp, PFCB Fcb, PLOWIO_COMPLETION_ROUTINE CompletionRoutine)
{
    ...
    routine = get_routine();
    routine(RxContext);         // rdpdr!DrIoControl;   RxContext == ffffc782`7abb2060
    ...
}


NTSTATUS rdpdr!DrIoControl(PRX_CONTEXT RxContext)
{
    // RxContext == ffffc782`7abb2060

    SmartPtr<DrDevice> Device{};
    GetDeviceFromRxContext(RxContext, Device);
    ...
}


BOOL rdpdr!GetDeviceFromRxContext(PRX_CONTEXT RxContext, SmartPtr<DrDevice>& Device)
{
    // RxContext == ffffc782`7abb2060
    // &Device == ffffa20c`46502230+48 == ffffa20c`46502278, on stack;  *Device == 0

    PMRX_SRV_OPEN SrvOpen = RxContext->pRelevantSrvOpen;    // [ffffc782`7abb2060+48] == xxx1 (?)  rax
    PMRX_V_NET_ROOT VNetRoot = SrvOpen->pVNetRoot;          // [xxx1+28] == ffffc782`83ff7810      rsi
    ...
    VirtualChannel* Channel = [VNetRoot+0x28];              // fffff804`272ee419 Ntfs!NtfsCommonFlushBuffers+0x335  !!! INVALID DATA !!!
    Device = Channel;                                       // SmartPtr<DrDevice>::operator=(VirtualChannel*)
}


DrDevice& SmartPtr<DrDevice>::operator=(DrDevice* this, VirtualChannel* Channel)
{
    // &Device == ffffa20c`46502230+48 == ffffa20c`46502278, on stack;  *Device == 0
    // Channel == fffff804`272ee419 Ntfs!NtfsCommonFlushBuffers+0x335  !!! INVALID !!!

    auto* prevObject = [this+0x00];                 // 0/nullptr (empty smartptr)
    if (prevObject)
        prevObject->Release();                      // skipped here
    [this+0x00] = Channel;
    Channel->AddRef();                              // lock inc [channel+0x10]   << can't write to fffff804`272ee419+0x10 == fffff804`272ee429, BSOD
    return *this;
}






Potential further investigation:

::RxContext
dps ffffc782`7abb2060+48-20 L8
!pool ffffc782`7abb2060+48 2

::SrvOpen
dps poi(ffffc782`7abb2060+48)-20 L8
!pool poi(ffffc782`7abb2060+48) 2

::VNetRoot
dps ffffc782`83ff7810-20 L8
!pool ffffc782`83ff7810 2


But that'll hardly give actionable data.
So far we only know that either SrvOpen (== RxContext->pRelevantSrvOpen), or VNetRoot (== SrvOpen->pVNetRoot) was overwritten with bogus data. I'd say chance of bitflip is medium or below medium. NGL, situation looks suspicious.

What I would do:
1. Badmem theory: test host with memcheck for at least some hours (if downtime is acceptable).
2. Attacker theory: use gflags.exe to enable *Kernel Flags*: Heap tail checking, Heap free checking, Page Heap (if ammount of memory allows that). That'll force bsod the very moment something overflows the pool, so it'll be much easier to find the culprit.