Edit

Bug Check 0xEA: THREAD_STUCK_IN_DEVICE_DRIVER

  • Article

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.

Important

This article is for programmers. If you're a customer who has received a blue screen error code while using your computer, see Troubleshoot blue screen errors.

THREAD_STUCK_IN_DEVICE_DRIVER Parameters

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

Cause

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. Frequently, this is the result of a bad video card or a bad display driver.

Resolution

The !analyze debug extension displays information about the bug check and can be helpful in determining the root cause.

Use the .thread (Set Register Context) command together 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 time-out condition. Then DbgBreakPoint will be called instead of KeBugCheckEx. A detailed message will be printed to the debugger. See Sending Output to the Debuggefor more information.

This message will include what would have been the bug check parameters. Because no actual bug check was issued, the .bugcheck (Display Bug Check Data) command will not be useful. 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 such as this will enable you to find 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 (OS build 3790 or earlier), you can hit a time out 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. This is because the time out's work item can be delivered and handled on the second CPU and the same time. If this occurs, you must look deeper at the offending thread's stack to determine the spinning code which caused the time out to occur. Use the dds (Display Words and Symbols) command to do this.