You mention that it's BSODed more than once(?) but you uploaded only one dump. It's difficult making a diagnosis based only on one dump, however the dump does suggest that this may be an SSD problem...
The bugcheck code is a SYSTEM_SERVICE_EXCEPTION with an exception code 0f 0xC000001D - which is an an attempt to execute an illegal instruction. This is usually a third-party driver screw-up, but there are no third-party drivers referenced in the lead-up to this bugcheck. The process in control was MsMpEng.exe - a component of the built-in Windows security product and it appears that MsMpEng.exe was ending an operation to a storage drive when an invalid call was made.
I would initially sugest removing and reseating the M.2 drive. I've seen many problems caused by poorly seated M.2 SSD drives.
It would also help if you would download and run the
V2 log collector and upload the resulting zip file. That will give us all the troubleshooting adat we need to be more specific...
It's difficult to be more precise with just one dump. If you want the gory details the failure happened in a call to the nt!CmpDeleteKeyObject function at offset 0x310...
Code:
0xffffa900d6e8f388 : 0xfffff8061a42c63c : nt!KiExceptionDispatch+0x13c
0xffffa900d6e8f488 : 0xfffff8061a2ecd53 : nt!wil_details_FeatureReporting_ReportUsageToService+0x113
0xffffa900d6e8f4d8 : 0xfffff8061a738d40 : nt!CmpDeleteKeyObject+0x310
0xffffa900d6e8f528 : 0xfffff8061ac14410 : nt!CallbackListHead
0xffffa900d6e8f548 : 0xfffff8061a6f3499 : nt!IoDeleteController+0x9
0xffffa900d6e8f568 : 0xfffff8061a425a2d : nt!KiInvalidOpcodeFault+0x32d
0xffffa900d6e8f570 : 0xffffe603775d9060 : Trap @ ffffa900d6e8f570
0xffffa900d6e8f578 : 0xfffff806497e4b87 : bfs!BfsRegistryCallback+0xf7
0xffffa900d6e8f688 : 0xfffff8061a26a2ec : nt!ExAcquireResourceSharedLite+0x13c
0xffffa900d6e8f6d8 : 0xfffff8061a738d40 : nt!CmpDeleteKeyObject+0x310
0xffffa900d6e8f7a8 : 0xfffff8061a6af081 : nt!NtSetValueKey+0x711
0xffffa900d6e8f828 : 0xfffff8061a6f352e : nt!ObpRemoveObjectRoutine+0x7e
0xffffa900d6e8f888 : 0xfffff8061a2ec627 : nt!ObfDereferenceObjectWithTag+0xc7
0xffffa900d6e8f8c8 : 0xfffff8061a7437d4 : nt!ObpCloseHandle+0x2a4
0xffffa900d6e8f920 : 0x0076007200650053 : !du "ServiceC"
0xffffa900d6e8f9e8 : 0xfffff8061a7403a9 : nt!NtClose+0x39
0xffffa900d6e8fa18 : 0xfffff8061a42bbe5 : nt!KiSystemServiceCopyEnd+0x25
0xffffa900d6e8fa20 : 0xffffd1886e47a080 : Trap @ ffffa900d6e8fa20
4: kd> .trap ffffa900d6e8f570
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000010 rbx=0000000000000000 rcx=0000000000000010
rdx=000000000000000f rsi=0000000000000000 rdi=0000000000000000
rip=fffff8061a738d40 rsp=ffffa900d6e8f700 rbp=ffffa900d6e8f7c9
r8=0000000000000000 r9=0000000000000010 r10=ffffe60370340000
r11=ffffa900d6e8f660 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!CmpDeleteKeyObject+0x310:
fffff806`1a738d40 07 ???
As you can see from the ??? this resulted in a call to a function offset that doesn't exist, hence the illegal instruction BSOD. If we disassemble that part of the nt!CmpDeleteKeyObject function you can see that offset 0x310 doesn't exist...
Code:
nt!CmpDeleteKeyObject+0x302:
fffff806`1a738d32 488bc1 mov rax,rcx
fffff806`1a738d35 f0480fb117 lock cmpxchg qword ptr [rdi],rdx
fffff806`1a738d3a 488bc8 mov rcx,rax
fffff806`1a738d3d 493bc1 cmp rax,r9
nt!CmpDeleteKeyObject+0x31b:
fffff806`1a738d4b 8b4710 mov eax,dword ptr [rdi+10h]
fffff806`1a738d4e 4533c0 xor r8d,r8d
fffff806`1a738d51 4c8b7f20 mov r15,qword ptr [rdi+20h]
fffff806`1a738d55 8bc8 mov ecx,eax
fffff806`1a738d57 c1e909 shr ecx,9
.....
The question is why was this invalid call made? There is no evidence of third-party drivers on the call stack and we can discount a problem with the WIndows modules. That means that the hardware itself must have somehow caused the invalid call, and since we suspect the SSD drive that's where I'd look first.
Facebook
Twitter
Instagram