Looks like the crash is occurring when passing an NBL structure via the miniport driver. Well, without a kmd, here's what I can see.
Code:
0: kd> .bugcheck
Bugcheck code 00000139
Arguments 00000000`00000003 ffffd000`2136fda0 ffffd000`2136fcf8 00000000`00000000
Reason for bug check was corrupted LIST_ENTRY.
Code:
0: kd> knL
# Child-SP RetAddr Call Site
00 ffffd000`2136fa78 fffff803`27fdd7e9 nt!KeBugCheckEx
01 ffffd000`2136fa80 fffff803`27fddb10 nt!KiBugCheckDispatch+0x69
02 ffffd000`2136fbc0 fffff803`27fdcd34 nt!KiFastFailDispatch+0xd0
03 ffffd000`2136fda0 fffff800`8043ac3a nt!KiRaiseSecurityCheckFailure+0xf4
04 ffffd000`2136ff30 fffff800`804359ff ndis!ndisFreeToNPagedPool+0x59
05 ffffd000`2136ff60 fffff800`804559dd ndis!NdisFreeNetBuffer+0xdf
06 ffffd000`2136ffd0 fffff800`81364e19 ndis!NdisFreeCloneNetBufferList+0x292fd
07 ffffd000`21370080 fffff800`80430eee vwififlt!FilterSendNetBufferListsComplete+0x181
08 ffffd000`213700d0 fffff800`81e9e671 ndis!NdisMSendNetBufferListsComplete+0x4de
09 ffffd000`21370240 ffffe000`1a7b61a0 NETwbw02+0x1b1671
0a ffffd000`21370248 ffffe000`44049880 0xffffe000`1a7b61a0
0b ffffd000`21370250 00000000`00000001 0xffffe000`44049880
0c ffffd000`21370258 00000000`00000000 0x1
NETwbw02 calls
NdisMSendNetBufferListsComplete to ultimately return a NBL (NET_BUFFER_LIST) structure to the miniport driver that called it (which is NETwbw02). These structures specify the data that is transmitted or received over the network. NDIS then calls
FilterSendNetBufferListsComplete to complete the send request that the filter driver started by calling the
NdisFSendNetBufferLists function. If you notice, we can't see that function on the stack, so we need to disassemble frame #07.
Code:
0: kd> ub NdisMSendNetBufferListsComplete
ndis!NdisFSendNetBufferLists+0x32d:
fffff800`804309fe e9f0fcffff jmp ndis!NdisFSendNetBufferLists+0x24 (fffff800`804306f3)
fffff800`80430a03 cc int 3
fffff800`80430a04 4c8bdb mov r11,rbx
fffff800`80430a07 e916feffff jmp ndis!NdisFSendNetBufferLists+0x153 (fffff800`80430822)
fffff800`80430a0c cc int 3
fffff800`80430a0d 90 nop
fffff800`80430a0e 90 nop
fffff800`80430a0f 90 nop
NdisFSendNetBufferLists is called by filter drivers to send a list of data buffers from the network, which now needs to be sent back down by NDIS to the underlying miniport driver(s) (NETwbw02). This is done by NDIS calling the
NdisAllocateCloneNetBufferList function, which creates a clone NBL structure to send duplicate data on a separate data path.
We can see the call to the
NdisFreeCloneNetBufferList function, which free the NET_BUFFER, as well as any associated NBL structures and MDL chains (Memory Descriptor List) previously allocated by the
NdisAllocateCloneNetBufferList function.
To quickly describe MDL chains, VG actually wrote about them on here -
https://www.sysnative.com/forums/bsod-kernel-dump-analysis-debugging-information/269-fun-mdls.html
Anyway, with that said, the MDL chains that were freed were from NETwbw02's IRPs.
We go off the rails freeing a NET_BUFFER structure that was previously allocated from a NET_BUFFER structure pool to what looks like nonpaged pool?
Code:
03 ffffd000`2136fda0 fffff800`8043ac3a nt!KiRaiseSecurityCheckFailure+0xf4
04 ffffd000`2136ff30 fffff800`804359ff ndis!ndisFreeToNPagedPool+0x59 // Here
05 ffffd000`2136ff60 fffff800`804559dd ndis!NdisFreeNetBuffer+0xdf
Let's look at the trap frame for the exception that caused the bugcheck.
Code:
0: kd> .trap ffffd000`2136fda0
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000002 rbx=0000000000000000 rcx=0000000000000003
rdx=ffffe00053b52018 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8008043ac3a rsp=ffffd0002136ff30 rbp=ffffd0002136ffc0
r8=ffffe0001f555018 r9=0000000000000001 r10=ffffe0001c591c70
r11=ffffe0001c4dc5a1 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po cy
ndis!ndisFreeToNPagedPool+0x59:
fffff800`8043ac3a cd29 int 29h
So we see this weird instruction:
What is that?
If you do a livekd, and run !idt 29, you can see:
Code:
kd> !idt 29
Dumping IDT: 809da400
29: 8158795c nt!KiRaiseSecurityCheckFailure
So on Windows 8, an ISR (Interrupt Service Routine) is defined by the kernel - i.e.
nt!KiRaiseSecurityCheckFailure. When 0x29 is triggered, the function
nt!KiFastFailDispatch is called, and then we bug check since this happened in kernel-mode and we can't recover.
Overall, without a kmd and no verifier, I feel pretty safe betting this is a problem in NETwbw02 as far as handling NBLs goes.