Code:
4: kd> .bugcheck
Bugcheck code 0000000A
Arguments 00000000`00000000 00000000`00000002 00000000`00000001 fffff800`030dee31
Code:
4: kd> kv
Child-SP RetAddr : Args to Child : Call Site
fffff880`0c96bde8 fffff800`030d8469 : 00000000`0000000a 00000000`00000000 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff880`0c96bdf0 fffff800`030d70e0 : 00000000`00000001 fffff880`009cfa60 fffffa80`0e668110 fffff880`0c96c320 : nt!KiBugCheckDispatch+0x69
fffff880`0c96bf30 fffff800`030dee31 : fffffa80`00000000 fffffa80`0d6fff00 fffff880`0c96c620 fffff880`0c96c6c0 : nt!KiPageFault+0x260 (TrapFrame @ fffff880`0c96bf30)
fffff880`0c96c0c0 fffff880`01ebb8f1 : fffffa80`0d6ccad8 fffff880`0c96c6c0 00000000`00000000 00000000`00000000 : nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0x41
fffff880`0c96c0f0 fffff880`01e3c6b5 : fffff880`0c96c620 fffffa80`11281870 fffffa80`0e088f00 fffff800`033d2436 : tcpip! ?? ::FNODOBFM::`string'+0x32560
fffff880`0c96c4e0 fffff800`030e57b8 : fffffa80`0d111840 fffffa80`10e4b170 00000000`00000000 00000000`00000000 : tcpip!UdpTlProviderSendMessagesCalloutRoutine+0x15
fffff880`0c96c510 fffff880`01e3c748 : fffff880`01e3c6a0 00000000`00000020 00000000`00000000 00000000`00000701 : nt!KeExpandKernelStackAndCalloutEx+0xd8
fffff880`0c96c5f0 fffff880`0338a6f5 : fffffa80`0d6c7dc0 fffffa80`0e668110 fffffa80`11281870 fffffa80`10b2bbb6 : tcpip!UdpTlProviderSendMessages+0x78
fffff880`0c96c670 fffff880`0338a942 : fffff880`009cf100 fffffa80`10f6bdb4 fffffa80`10e4b170 fffff800`030eaae1 : tdx!TdxSendDatagramTransportAddress+0x2f5
fffff880`0c96c750 fffff880`033bdde6 : fffffa80`0f8a57f0 fffffa80`10b2bb30 00000000`00000000 fffff880`009cf180 : tdx!TdxTdiDispatchInternalDeviceControl+0x52
fffff880`0c96c7d0 fffffa80`0f8a57f0 : fffffa80`10b2bb30 00000000`00000000 fffff880`009cf180 00000000`00000001 : networx+0x7de6
fffff880`0c96c7d8 fffffa80`10b2bb30 : 00000000`00000000 fffff880`009cf180 00000000`00000001 00000000`00000059 : 0xfffffa80`0f8a57f0
fffff880`0c96c7e0 00000000`00000000 : fffff880`009cf180 00000000`00000001 00000000`00000059 fffff880`04c00000 : 0xfffffa80`10b2bb30
What a surprise...
networx is calling the TDI translation driver's function to dispatch internal device control, and send datagram transport address(es). We then call into the TCPIP drivetr, specifically sending user datagram protocol messages, etc. Mostly network stuff. You can see it ends with networx inevitably calling the
KeReleaseInStackQueuedSpinLockFromDpcLevel function to release its previously queued spinlock, which we can't see on the current stack, so we assume it was done before this exception was handled.
Code:
4: kd> !irql
Debugger saved IRQL for processor 0x4 -- 2 (DISPATCH_LEVEL)
We were at the proper IRQL for this action to occur, so what was the real problem?
Code:
4: kd> .trap fffff880`0c96bf30
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff8800c96c320 rbx=0000000000000000 rcx=0000000000000000
rdx=fffffa800d0abda0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800030dee31 rsp=fffff8800c96c0c0 rbp=0000000000000000
r8=fffff8800c96c320 r9=0000000000000001 r10=fffff880009cfa60
r11=fffffa800e668110 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0x41:
fffff800`030dee31 f0480fb129 lock cmpxchg qword ptr [rcx],rbp ds:00000000`00000000=????????????????
Regarding the function we went off the rails on, looking at the trapframe for its exception, we can see it was a LOCK prefix for SMP with the cmpxchg (compare/exchange) instruction, specifically comparing and exchanging the destination > source operand (i.e rbp to the value stored at address rcx). Since we're only on a small dump, I can't tell you specifically what went wrong here regarding the instrucion. All I know is, networx is the issue.
networx is a
pretty awful driver that I've seen cause blogs posts worth of issues in the past, so it's no surprise this is probably just really bad coding.
Remove networx.
