On the blue screen, this will always equal 1. If a debugger is attached, this error is not always fatal - see DESCRIPTION below. thread then kb on it to find the hung location.Īrg2: 00000000, Pointer to a DEFERRED_WATCHDOG object.Īrg3: 00000000, Pointer to offending driver name.Īrg4: 00000000, Number of times this error occurred.
#Thread stuck in device driver blue screen code
using dds) to determine spinning code which caused the timeout to occur.Īrg1: 870246b8, Pointer to a stuck thread object. If this is the case you will have to look deeper at the offending thread's stack (e.g. On MP machines (OS builds <= 3790) it is possible to hit a timeout when the spinning thread is interrupted by hardware interrupt and ISR or DPC routine is running at the time of the bugcheck (this is because the timeout's work item can be delivered and handled on the second CPU and the same time). "dd watchdog!g_WdBugCheckData l5" (use dq on NT64). You can also retrieve them from a global variable via The arguments are already printed out to the kernel debugger. bugcheck directive will not return bugcheck Because KeBugCheckEx() is not called the. This way we can identify an offending thread, set breakpoints in it, and hit go to return to the spinning code to debug it further.
If the kernel debugger is connected and running when watchdog detects a timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()and detailed message including bugcheck arguments will be printed to theĭebugger. This usually indicates problem with the hardware itself or with the device driver programming the hardware incorrectly.
The device driver is spinning in an infinite loop, most likely waiting for hardware to become idle. Analysis of the dump yielded the following: Recently, after resuming my Vista laptop from hibernation, I was greeted with a rather strange wait, followed by a blue screen of death.
0 kommentar(er)
