Despite memtest passing, I still believe this is a hardware issue. Possibly CPU at this point since memtest passed.
1st parameter address is of course invalid.
Just perusing the stack we can see we go off the rails on a memory manager function, which more or less with verifier enabled tells us that we're most likely not dealing with a driver issue here.
Taking a look at the trapframe for the unhandled exception regarding MiDeleteAddressesInWorkingSet, we can see rbp+28 was dereferenced. The instruction itself will result in a write to fffffa80`1806f958, which is our 1st parameter we saw earlier.
rbp is also invalid.
Bottom line, as I said, most likely hardware. Is there any way you can contact the OEM for repair and/or replacement? If so, you should do so.
Code:
6: kd> .bugcheck
Bugcheck code 00000050
Arguments fffffa80`1806f958 00000000`00000000 fffff803`e74a32a6 00000000`00000002
Code:
6: kd> !pte fffffa80`1806f958
VA fffffa801806f958
PXE at FFFFF6FB7DBEDFA8 PPE at FFFFF6FB7DBF5000 PDE at FFFFF6FB7EA00600 PTE at FFFFF6FD400C0378
contains 000000062FDFF863 contains 000000062FDFE863 contains 0000000000000000
pfn 62fdff ---DA--KWEV pfn 62fdfe ---DA--KWEV not valid1st parameter address is of course invalid.
Code:
6: kd> kv
Child-SP RetAddr : Args to Child : Call Site
ffffd000`3e8f4958 fffff803`e759b675 : 00000000`00000050 fffffa80`1806f958 00000000`00000000 ffffd000`3e8f4bc0 : nt!KeBugCheckEx
ffffd000`3e8f4960 fffff803`e74744a9 : 00000000`00000000 ffffe001`ab69f4c0 ffffd000`3e8f4bc0 fffff803`e77500d4 : nt! ?? ::FNODOBFM::`string'+0x1e6c5
ffffd000`3e8f4a00 fffff803`e7576d2f : 00000000`00000000 e4000008`02531025 fffff803`e7741300 fffff803`e77413b0 : nt!MmAccessFault+0x769
ffffd000`3e8f4bc0 fffff803`e74a32a6 : 94400004`20887c46 fffffa80`0c619950 00000000`00000144 fffff580`10804d40 : nt!KiPageFault+0x12f (TrapFrame @ ffffd000`3e8f4bc0)
ffffd000`3e8f4d50 fffff803`e7518015 : ffffffff`ffffffff ffffffff`ffffffff ffffe001`ab69f9a8 ffffe001`ab4a6880 : nt!MiDeleteAddressesInWorkingSet+0x526
ffffd000`3e8f5650 fffff803`e77ee1e3 : 00000000`00040000 ffffd000`3e8f5800 ffffe001`ab4a6880 ffffe001`ab69f4c0 : nt!MiBeginProcessClean+0x101
ffffd000`3e8f56a0 fffff803`e77c7360 : 00000000`00040000 ffffd000`3e8f5800 00000000`00000000 00000000`00000000 : nt!MmCleanProcessAddressSpace+0x67
ffffd000`3e8f5700 fffff803`e77e8e6f : ffffe001`ab69f4c0 ffffc000`c55c3500 ffffd000`3e8f5800 00000000`00000000 : nt!PspRundownSingleProcess+0xac
ffffd000`3e8f5790 fffff803`e78bfcec : 00000000`c0000005 ffffe001`ab4a6880 ffffd000`3e8f5b00 ffffe001`ab4a6928 : nt!PspExitThread+0x573
ffffd000`3e8f58a0 fffff803`e744cd7a : 00000000`00000000 ffffe001`a7da20f0 00000000`00000001 00000000`00000000 : nt!KiSchedulerApcTerminate+0x18
ffffd000`3e8f58d0 fffff803`e75719c0 : 00000000`0983e860 ffffd000`3e8f5950 fffff803`e744bfe4 00000000`00000000 : nt!KiDeliverApc+0x2fa
ffffd000`3e8f5950 fffff803`e757835a : 00000000`00000084 00000000`0983e860 ffffd000`00000010 00000000`0c67fbc0 : nt!KiInitiateUserApc+0x70
ffffd000`3e8f5a90 00007ffb`69e6273a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExit+0x9f (TrapFrame @ ffffd000`3e8f5b00)
00000000`0983e148 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffb`69e6273aJust perusing the stack we can see we go off the rails on a memory manager function, which more or less with verifier enabled tells us that we're most likely not dealing with a driver issue here.
Code:
Verify Flags Level 0x0002092b
STANDARD FLAGS:
[X] (0x00000000) Automatic Checks
[X] (0x00000001) Special pool
[X] (0x00000002) Force IRQL checking
[X] (0x00000008) Pool tracking
[ ] (0x00000010) I/O verification
[X] (0x00000020) Deadlock detection
[ ] (0x00000080) DMA checking
[X] (0x00000100) Security checks
[X] (0x00000800) Miscellaneous checks
[X] (0x00020000) DDI compliance checking
ADDITIONAL FLAGS:
[ ] (0x00000004) Randomized low resources simulation
[ ] (0x00000200) Force pending I/O requests
[ ] (0x00000400) IRP logging
[ ] (0x00002000) Invariant MDL checking for stack
[ ] (0x00004000) Invariant MDL checking for driver
[ ] (0x00008000) Power framework delay fuzzing
[ ] (0x00040000) Systematic low resources simulation
[ ] (0x00080000) DDI compliance checking (additional)
[ ] (0x00200000) NDIS/WIFI verification
[ ] (0x00800000) Kernel synchronization delay fuzzing
[ ] (0x01000000) VM switch verification
[X] Indicates flag is enabled
Code:
6: kd> .trap ffffd000`3e8f4bc0
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=0200000000000000
rdx=0000000fffffffff rsi=0000000000000000 rdi=0000000000000000
rip=fffff803e74a32a6 rsp=ffffd0003e8f4d50 rbp=fffffa801806f930
r8=0000058000000000 r9=0000000000000002 r10=0000000000001d77
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
nt!MiDeleteAddressesInWorkingSet+0x526:
fffff803`e74a32a6 48854d28 test qword ptr [rbp+28h],rcx ss:0018:fffffa80`1806f958=????????????????Taking a look at the trapframe for the unhandled exception regarding MiDeleteAddressesInWorkingSet, we can see rbp+28 was dereferenced. The instruction itself will result in a write to fffffa80`1806f958, which is our 1st parameter we saw earlier.
Code:
6: kd> !pte fffffa801806f930
VA fffffa801806f930
PXE at FFFFF6FB7DBEDFA8 PPE at FFFFF6FB7DBF5000 PDE at FFFFF6FB7EA00600 PTE at FFFFF6FD400C0378
contains 000000062FDFF863 contains 000000062FDFE863 contains 0000000000000000
pfn 62fdff ---DA--KWEV pfn 62fdfe ---DA--KWEV not validrbp is also invalid.
Bottom line, as I said, most likely hardware. Is there any way you can contact the OEM for repair and/or replacement? If so, you should do so.