The THREAD_STUCK_IN_DEVICE_DRIVER bug check has a value of 0x000000EA. This indicates that a thread in a device driver is endlessly spinning.
The following parameters are displayed on the blue screen.
| Parameter | Description |
|---|---|
| 1 | A pointer to the stuck thread object |
| 2 | A pointer to the DEFERRED_WATCHDOG object |
| 3 | A pointer to the offending driver name |
| 4 | In the kernel debugger: The number of times the "intercepted" bug check 0xEA was hit
On the blue screen: 1 |
A device driver is spinning in an infinite loop, most likely waiting for hardware to become idle.
This usually indicates problem with the hardware itself, or with the device driver programming the hardware incorrectly. In many cases this is the result of a bad video card or a bad display driver.
Use the .thread (Set Register Context) debugger command with Parameter 1. Then use KB (Display Stack Backtrace) to find the location where the thread is stuck.
If the kernel debugger is already connected and running when Windows detects a timeout condition, then DbgBreakPoint will be called instead of KeBugCheckEx. A detailed message will be printed to the debugger.
This message will include what would have been the bug check parameters. Since no actual bug check was issued, the .bugcheck debugger command will not be of use. The four parameters can also be retrieved from Watchdog's global variables by using dd watchdog!g_WdBugCheckData L5" on a 32-bit system, or dq watchdog!g_WdBugCheckData L5" on a 64-bit system.
Debugging this error in an interactive manner like this will enable you to identify an offending thread, set breakpoints in it, and then use G (Go) to return to the spinning code to debug it further.
On multiprocessor machines it is possible to hit a timeout if the spinning thread is interrupted by a hardware interrupt and an ISR or DPC routine is running at the time of the bug check. The reason for this is that the timeout's work item can be delivered and handled on the second CPU and the same time. If this occurs, you will have to look deeper at the offending thread's stack to determine the spinning code which caused the timeout to occur. Use the DdS (Display Words and Symbols) command to do this.