A Windows 10 kernel-only crash dump (build 19041) shows a 0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL caused by tunnel.sys (Teredo) dereferencing a NULL previous pointer while unlinking a flow list entry, triggered during concurrent TCP/IP cleanup and a user thread closing a UDP endpoint. The analyst concludes the root cause is a race condition between tcpip!LruCleanupDpcRoutine and tcpip!UdpCloseEndpoint leading to a NULL+0x8 read in tunnel!TeredoWfpRemoveHashEntry. #tunnel.sys #TeredoWfpRemoveHashEntry
Keypoints
- Crash type: 0xD1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) at IRQL 2 caused by a NULL+0x8 read in tunnel.sys (TeredoWfpRemoveHashEntry+0x2c).
- Faulting instruction: cmp qword ptr [rdx+8], rbx with RDX=0, meaning a prev pointer was NULL and Blink (offset +0x8) dereference caused the fault.
- Call stack path: tcpip!LruCleanupDpcRoutine → NETIO/WFP notify flows → tunnel!TeredoWfpRemoveHashEntry (fault), showing the crash occurred during flow teardown from background cleanup.
- Concurrent activity: an svchost.exe thread performing tcpip!UdpCloseEndpoint held NDIS write lock and was also freeing the same flow state, indicating concurrent teardown paths.
- Root cause analysis: a race condition where the LRU cleanup DPC unlinked the Teredo list entry first while a close path still assumed the node was linked, causing a list-integrity check to dereference NULL.
- Evidence: disassembly and trap frame show RDX=0 at the list check; stack and thread dumps show timing and locking (spinlocks, IRQL changes) consistent with concurrent operations.
- Conclusion: Windows attempted to verify/unlink an already-unlinked node under spinlock at DISPATCH_LEVEL, leading to the crash and implying a synchronization bug between cleanup and close paths.
MITRE Techniques
- [T1486] Data Encrypted for Impact – Not applicable; article describes crash dump analysis and does not mention encryption or ransomware. “The nice thing about crash dump analysis is that it’s not a courtroom.”
- [T1218] System Binary Proxy Execution – Not applicable; no mention of adversary use of system binaries. “This is a kernel-only dump from Windows 10 build 19041…”
- [T1609] System Service Discovery – Not applicable; article focuses on kernel debugging and driver/list unlink race, not discovery techniques. “The next step was to learn more about the specific function…”
Indicators of Compromise
- [File Name] faulting module – tunnel.sys (TeredoWfpRemoveHashEntry), referenced as the crashing image name and symbol.
- [OS Version] affected system context – Windows 10 build 19041.1 (example: Win10 19041 kernel base fffff806`31600000).
Read more: https://medium.com/@Debugger/bugcheck-598f6a73412a