This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
I have a custom built gaming PC that has recently been blue screening randomly and it seems completely unprompted. It happens when I'm in the middle of a game, or when I'm working on a Word document with Spotify playing, or when I'm browsing google chrome with nothing else open. I don't know what could be causing it.
The error I get is always "KMODE_EXCEPTION_NOT_HANDLED"
I recently had an issue where my computer would BSOD with the same error every time I woke it up from sleep mode. I got a warranty replacement for my RAM and that fixed that issue. These BSODs seem to be caused by something else. This also means that I find it highly unlikely that there's something wrong with my RAM.
Here is a link to the dump files I've gathered so far. I will add more as my computer continues to crash. It happens once every few hours, it seems.
https://drive.google.com/drive/folders/1_QM2imGRMNnQtNsdU8W98a16JUMTyj0d?usp=sharing
Does anybody know what could be causing this issue? Do the dump files point to anything specifically that could be causing the crashes?
Thank you
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
And to the person suffering from BSODs, if you can manage turning on Core Isolation Memory Integrity in control panel applet you will get rid of the shellcode (entirely), but only if you survive. Normally turning on Core Isolation is harmless, but now it isn't since something producing rwx kernelmode shellcode is lurking.
I looked at another one from "KMODE_EXCEPTION_NOT_HANDLED", 120524-10187-01.dmp, same. I didn't look at the remaining two anymore, because I'm pretty certain I will just see the same (and also lunch time is over ^^).
(No point in trying the corruption ones (CRITICAL_STRUCTURE_CORRUPTION). The bsod came too late and whatever happened already happened a while ago.)
2: kd> kb
# RetAddr : Args to Child : Call Site
00 fffff802`7647e16d : 00000000`0000001e ffffffff`c0000096 ffffd10b`64b1c9c9 00000000`00000000 : nt!KeBugCheckEx
01 fffff802`76412eec : ffff9c00`9d285780 247c8be7`034c0002 00000000`4116eb44 00000000`00000000 : nt!KiDispatchException+0x144dbd
02 fffff802`7640e2ef : ffff9c00`9d285840 89480575`003e8348 9824848b`480beb06 43f63089`4c000000 : nt!KiExceptionDispatch+0x12c
03 ffffd10b`64b1c9c9 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiGeneralProtectionFault+0x32f
04 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0xffffd10b`64b1c9c9
2: kd> u 0xffffd10b`64b1c9c9 L1
ffffd10b`64b1c9c9 0f22c0 mov cr0,rax
2: kd> !pte ffffd10b`64b1c9c9
VA ffffd10b64b1c9c9
PXE at FFFFF6FB7DBEDD10 PPE at FFFFF6FB7DBA2168 PDE at FFFFF6FB7442D928 PTE at FFFFF6E885B258E0
contains 0A00000004944863 contains 0A00000004947863 contains 0A0000083C2D2863 contains 0A00000839B1E963
pfn 4944 ---DA--KWEV pfn 4947 ---DA--KWEV pfn 83c2d2 ---DA--KWEV pfn 839b1e -G-DA--KWEV
Again nonpaged rwx shellcode of unknown origin trying to write changed bitmask (missing Write Protection bit 0x10 (16 decimal)) to cr0.
> On which dump did you execute that !pte command? That requires more than a minidump to work and I have not seen an example of this problem in a large dump.
I used "120424-11125-01.dmp" from the collection of "KMODE_EXCEPTION_NOT_HANDLED" for the pte command above.
The address used in the pte command was the one that caused the exception in 120424-11125-01.dmp.:
1: kd> kb
# RetAddr : Args to Child : Call Site
00 fffff802`0fe7e16d : 00000000`0000001e ffffffff`c0000096 ffff820a`fd317e88 00000000`00000000 : nt!KeBugCheckEx
01 fffff802`0fdff6e2 : 3b480008`c3d2058d 72042979`807674c8 697440a8`2c418b70 3d058d4c`084e8b4c : nt!KiDispatchException+0x144dbd
02 fffff802`0fdff6b0 : fffff802`0fe12ee5 ffffe780`14bd4180 fffff802`0fe07002 001fe067`bcbbbdff : nt!KxExceptionDispatchOnExceptionStack+0x12
03 fffff802`0fe12ee5 : ffffe780`14bd4180 fffff802`0fe07002 001fe067`bcbbbdff ffffc901`4f6c9100 : nt!KiExceptionDispatchOnExceptionStackContinue
04 fffff802`0fe0e2ef : 00000000`00000000 fffff802`0d39b6a0 fffff802`0d398ac0 00000000`00000000 : nt!KiExceptionDispatch+0x125
05 ffff820a`fd317e88 : ffffffff`b8797400 00000000`00000001 ffff820a`fd302017 ffffffff`b8797400 : nt!KiGeneralProtectionFault+0x32f
06 ffffffff`b8797400 : 00000000`00000001 ffff820a`fd302017 ffffffff`b8797400 fffff802`14e43740 : 0xffff820a`fd317e88
1: kd> u 0xffff820a`fd317e88
ffff820a`fd317e88 0f22c0 mov cr0,rax
Hello vivs_lunchtime,
On which dump did you execute that !pte command? That requires more than a minidump to work and I have not seen an example of this problem in a large dump.
On the dumps from Alex, the stack in the first trap frame contains this:
dqs @rsp+70 l 1
ffff928ae6356820 fffff8001ada1f90 ndis!ndisOidPreAddWakeUpPattern
The bold pointer is always ndisOidPreAddWakeUpPattern in Alex's dumps or is the routine reported by PatchGuard.
In Damian's dump. the equivalent stack content is:
dqs @rsp+70 l 1
fffffc8307d8e7f0 fffff802701a1ff8 tcpip!RtlCookUrl
So the first patch target system to be consistent per system but differ between systems.
In the PatchGuard dump from Alex, the patch to ndisOidPreAddWakeUpPattern looks like this (with surrounding unpatched bytes for context):
ndis!ndisOidPreAddWakeUpPattern+0x5d:
fffff802`4d1a1fed 83a79800000000 and dword ptr [rdi+98h],0
fffff802`4d1a1ff4 4885c9 test rcx,rcx
fffff8024d1a1ff7 7419 je ndis!ndisOidPreAddWakeUpPattern+0x82 (fffff8024d1a2012) Branch
ndis!ndisOidPreAddWakeUpPattern+0x69:
fffff802`4d1a1ff9 4c8d44 ac13 lea r8,[rsp+rbp*4+13h]
fffff802`4d1a1ffa 8d 44 ac 13 0a 92 54 54-10 00 00 8e be 09 61 54 .D....TT......aT
fffff802`4d1a200a 10 00 28 8e be 09 6e 54-10 00 3b 8e be 09 7b 54 ..(...nT..;...{T
fffff802`4d1a201a 10 00 77 8e be 09 88 54-10 00 73 8e be 09 95 54 ..w....T..s....T
fffff802`4d1a202a 10 00 8b 8e be 09 a2 54-10 00 00 8e be 09 af 54 .......T.......T
fffff802`4d1a203a 10 00 30 8e be 09 bc 54-10 00 00 8e be 09 c9 54 ..0....T.......T
fffff802`4d1a204a 10 00 80 8e be 09 d6 54-10 00 24 8e be 09 e3 54 .......T..$....T
fffff802`4d1a205a 10 00 e8 8e be 09 f0 54-10 00 30 8e be 09 fd 54 .......T..0....T
fffff802`4d1a206a 10 00 38 8e be 09 0a 55-10 00 48 8e be 09 17 55 ..8....U..H....U
fffff802`4d1a207a 10 00 cc 8e be 09 24 55-10 00 cc 8e be 09 31 55 ......$U......1U
fffff802`4d1a208a 10 00 cc 8e be 09 3e 55-10 00 48 8e be 09 4b 55 ......>U..H...KU
fffff802`4d1a209a 10 00 c2 8e be 09 58 55-10 00 01 8e be 09 65 55 ......XU......eU
fffff802`4d1a20aa 10 00 e8 8e be 09 72 55-10 00 41 8e be 09 7f 55 ......rU..A....U
fffff802`4d1a20ba 10 00 e8 8e be 09 8c 55-10 00 28 8e be 09 99 55 .......U..(....U
fffff802`4d1a20ca 10 00 cc 8e be 09 a6 55-10 00 48 8e be 09 b3 55 .......U..H....U
fffff802`4d1a20da 10 00 04 8e be 09 c0 55-10 00 00 8e be 09 cd 55 .......U.......U
fffff802`4d1a20ea 10 00 33 8e be 09 da 55-10 00 00 8e be 09 e7 55 ..3....U.......U
fffff802`4d1a20fa 10 00 77 8e be 09 41 80-78 21 14 73 09 c7 42 28 ..w...A.x!.s..B(
fffff802`4d1a210a bb 00 00 c0 eb 65 83 .....e.
fffff802`4d1a210f 65 83783004 cmp dword ptr gs:[rax+30h],4
fffff8024d1a2114 7310 jae ndis!ndisOidPreGetPMProtocolOffload+0x56 (fffff8024d1a2126) Branch
ndis!ndisOidPreGetPMProtocolOffload+0x46:
fffff802`4d1a2116 c74228140001c0 mov dword ptr [rdx+28h],0C0010014h
fffff802`4d1a211d c7404404000000 mov dword ptr [rax+44h],4
fffff8024d1a2124 eb4f jmp ndis!ndisOidPreGetPMProtocolOffload+0xa5 (fffff8024d1a2175) Branch
I can't imagine what the purpose of those bytes are...
Searching the web shows other possible instances of this problem stretching back many months - it is disappointing that anti-malware defences are not detecting anything.
Gary
short interruption: I looked at the dumps of KM exception, and it's 100% same.
(I naturally can't use the corruption ones because system is already corrupted and the bsod happened too late.)
It was rwx shellcode:
!pte 0xffff820a`fd317e88
VA ffff820afd317e88
PXE at FFFFA1D0E8743820 PPE at FFFFA1D0E8704158 PDE at FFFFA1D0E082BF48 PTE at FFFFA1C1057E98B8
contains 0A00000004944863 contains 0A00000004947863 contains 0A0000045BD44863 contains 0A000002FD8DE963
pfn 4944 ---DA--KWEV pfn 4947 ---DA--KWEV pfn 45bd44 ---DA--KWEV pfn 2fd8de -G-DA--KWEV
See: true rwx nonpaged shellcode
The nonpaged rwx shellcode at this instruction line (that cause the BSOD) tried (unsuccessfully) to make the whole memory writable regardless of read-only page protections. But as said, it failed, because the system rather chose to kill itself than allowing this.
The originator is currently unknown! Thanks to shellcode usage.