What is causing my computer to BSOD at random times?

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.

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

> 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

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.

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.