0x000000EA THREAD_STUCK_IN_DEVICE_DRIVER
A driver asked a piece of hardware to do something, then sat in a loop waiting for it to finish - and it never did. Windows has a watchdog for exactly this, and when the watchdog runs out of patience it stops the system. Microsoft's own wording is that this frequently means a bad video card or a bad display driver, and that remains true: the great majority of these are graphics. What makes this code more tractable than most is that parameter 3 usually hands you the driver's name outright.
What you are looking at
Your PC ran into a problem and needs to restart.
Stop code: THREAD_STUCK_IN_DEVICE_DRIVER
Where the screen names a failed component, it is commonly a display driver - nvlddmkm.sys on NVIDIA, amdkmdag.sys on AMD, igdkmd64.sys on Intel.
In Event Viewer the matching entries look like this:
Log Name: System
Source: BugCheck
Event ID: 1001
Level: Error
The computer has rebooted from a bugcheck. The bugcheck was: 0x000000ea (0xffffb90d5c8e6080, 0xfffff8021a4c9e30, 0xffffb90d61a24010, 0x0000000000000001).Log Name: System
Source: Display
Event ID: 4101
Level: Warning
Display driver nvlddmkm stopped responding and has successfully recovered.What the error actually means
The name is precise and worth taking literally: a thread inside a device driver is endlessly spinning. Not deadlocked waiting on a lock, not crashed - looping, burning CPU, waiting for hardware to report itself idle. Microsoft's stated cause is a device driver spinning in an infinite loop, most likely waiting for hardware to become idle.
Windows detects this with a watchdog timer rather than by catching a fault, which is why parameter 2 points at a DEFERRED_WATCHDOG object. Nothing illegal happened - no bad pointer, no access violation. The driver simply never came back, and the watchdog decided that waiting forever was worse than stopping.
That leaves two possibilities, and Microsoft names both: the hardware itself is faulty, or the driver is programming the hardware incorrectly. Then it goes further and says which case dominates in practice - frequently, this is the result of a bad video card or a bad display driver. Graphics hardware is the most common source because it is the most complex asynchronous device in a typical machine, and the one most often pushed to its thermal and electrical limits.
Reading the parameters
Parameter 3 is the one to read first - it is unusually generous, pointing straight at the driver name. Parameter 4 means two different things depending on where you are reading it, which is a genuine trap.
| Parameter | What it holds |
|---|---|
| 1 | A pointer to the stuck thread object. This is what you feed to .thread in a debugger to switch context to the thread that hung, and from there kb shows you exactly where it is stuck. |
| 2 | A pointer to the DEFERRED_WATCHDOG object. Confirms this was a watchdog timeout rather than a fault - the mechanism that caught the problem, not the problem itself. |
| 3 | A pointer to the offending driver name. The most immediately useful of the four. Like 0xC000021A, this points at text rather than a structure, and it frequently names the culprit without any further analysis. |
| 4 | Means two different things depending on context. In the kernel debugger it is the number of times the intercepted bugcheck 0xEA was hit. On the blue screen it is always 1. So a 1 here from Event Viewer or a crash screen carries no information at all - do not read it as a count of anything. |
What actually triggers it
Microsoft narrows this to two categories - faulty hardware, or a driver programming it wrongly - and singles out graphics. This list expands that into what it looks like in practice.
| Cause | How often | Detail |
|---|---|---|
| Display driver fault | Common | The single most frequent cause. A bug in the graphics driver, or a driver version mismatched to the card or to the current Windows build. Crashes that started immediately after a driver update point here and are usually the easiest to resolve. |
| Failing or unstable graphics hardware | Common | Named directly by Microsoft. A GPU that is degrading, overheating, or not getting clean power will stop responding under load, and no driver version fixes that. Ageing cards and cards recovering from a previous repair are both prone to it. |
| GPU overheating or thermal throttling | Common | A card that is thermally saturated stops completing work in time. Dust-clogged heatsinks, failed fans and dried-out thermal paste all produce this, and it characteristically appears only after some minutes of load rather than at idle. |
| Insufficient or unstable power delivery | Occasional | An under-specified or ageing power supply, or a GPU power cable not fully seated. Modern cards draw sharp transient spikes, and a supply that cannot follow them causes the card to stall rather than to fail outright. |
| Overclocking - including factory overclocks | Occasional | Applies to memory overclocks and XMP/EXPO profiles as much as to GPU tuning. Worth noting that a card can be unstable at its advertised factory clocks as it ages, so 'I never overclocked it' does not rule this out - underclocking slightly is a valid test. |
| A non-graphics device driver | Occasional | The code is not graphics-specific, despite the pattern. Storage controllers, capture cards, audio interfaces and USB controllers can all spin waiting on hardware. Parameter 3 will say so - trust the name over the assumption. |
| A riser, adapter or marginal PCIe connection | Rare | Anything degrading signal quality on the PCIe link can cause the device to fail to respond in time. Riser cables and adapters are the usual suspects. |
Narrowing it down
Because parameter 3 names the driver, triage here is faster than for most stop codes. Get the name first, then work out whether the driver or the hardware is at fault.
Get the driver name
If the crash screen named a file, you already have it. Otherwise open the newest minidump in WinDbg and run !analyze -v - the offending driver is what parameter 3 points at, and !analyze normally surfaces it without further work.
To dig into where it hung, Microsoft's documented sequence is .thread with parameter 1 to switch context, then kb for the stack:
.thread ffffb90d5c8e6080
kbA display driver - nvlddmkm.sys, amdkmdag.sys, igdkmd64.sys - confirms the common case. Anything else redirects the entire investigation to that device, and is worth trusting over the assumption that this code means graphics.
Establish whether it is load-dependent
This is the highest-value question for separating driver bugs from dying hardware, and it costs nothing but attention. Does it crash while gaming, rendering or running anything GPU-heavy - or at idle, on the desktop, browsing?
Crashes exclusively under load point at heat, power or degrading silicon. Crashes at idle or during light use point more at the driver, or at power-state transitions. Crashes in both directions with no pattern usually means hardware.
Check for Display Event 4101 in the run-up
Look in Event Viewer for Display Event 4101, 'display driver stopped responding and has successfully recovered', in the days or weeks before the crashes started.
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Display'; Id=4101} -MaxEvents 30 |
Select-Object TimeCreated, Message | Format-ListA history of 4101 events that recovered, escalating into 0xEA crashes that did not, is the signature of hardware degrading rather than a driver bug appearing overnight. It is the same failure getting worse until recovery stopped working.
Watch temperatures under load
Run HWiNFO64 or GPU-Z alongside something demanding and watch GPU core and hotspot temperatures, plus fan RPM. Note whether a fan stops, or whether the crash lands at a repeatable temperature.
A crash that reliably arrives at the same temperature, or a fan reading zero under load, settles it without further testing.
Fixes, cheapest first
Ordered by effort. If parameter 3 named something other than a display driver, apply the same logic to that device instead.
Clean-install the graphics driver
Not a reinstall over the top - a clean install. Layered driver installations are a genuine cause of this, and the standard tool for removing every trace is DDU (Display Driver Uninstaller).
- Download the current driver from NVIDIA, AMD or Intel directly - not from Windows Update, and not from the laptop maker unless it is a laptop with switchable graphics.
- Boot into Safe Mode.
- Run DDU and choose Clean and restart.
- Install the driver you downloaded, choosing a clean installation if offered.
Watch outIf the crashes began right after a driver update, install the previous version rather than the newest one. Newest is not the same as most stable, and regressions in display drivers are common.
Clear the heat problem
If temperatures looked high, or the machine is more than a couple of years old and has never been cleaned, this is worth doing before anything more involved.
Power down fully and unplug. Clear dust from the GPU heatsink and case filters with compressed air, holding fans still so they cannot be spun up by the airflow. Confirm every fan spins freely by hand, and that case airflow is not blocked.
Watch outDo not spin fans with compressed air. A fan driven backwards past its rated speed can generate enough voltage to damage what it is connected to.
Underclock slightly to test stability
A diagnostic more than a fix, and a strong one. In MSI Afterburner, drop the GPU core clock by 100 MHz and the memory clock by 200 MHz - below stock, even if you never overclocked.
If the crashes stop, the card is no longer stable at its own rated speeds, which is a hardware finding rather than a driver one.
Watch outAlso remove any factory overclock profile, and disable XMP/EXPO in firmware temporarily if you want to rule memory out at the same time. Undoing these is reversible - note the settings before you change them.
Reseat the card and its power cables
On a desktop, power down, unplug, and hold the power button for ten seconds to discharge. Remove the graphics card, check the PCIe slot and contacts for dust, and reseat it firmly until the retention clip clicks.
Check the PCIe power connectors are fully home at both ends. Use separate cables from the supply rather than a single cable with two daisy-chained connectors where the card has multiple sockets.
Watch outRemove any PCIe riser or adapter from the equation entirely if one is fitted, even temporarily - they are a disproportionate source of this fault.
Test with different hardware
The decisive test, if you can borrow parts. Either put the suspect card in another machine, or put a known-good card in this one.
If the fault follows the card, it is the card. If it stays with the machine, look at the power supply and the board.
Watch outOn a laptop with only integrated graphics, the equivalent is checking whether the fault persists after a clean driver install and a firmware update - there is nothing to swap.
Update firmware and chipset drivers
Worth doing where PCIe link behaviour or power management is implicated, which firmware updates do sometimes address. Install the chipset drivers first, from the board or laptop manufacturer.
- Check BitLocker status first with
manage-bde -statusand retrieve your recovery key fromaccount.microsoft.com/devices/recoverykeyif encryption is on - firmware updates can trigger a recovery prompt. - Install the chipset drivers for your exact model.
- Only then update system firmware, from the manufacturer's support page for your specific model or service tag.
- Run the update on mains power, never on battery, and do not interrupt it.
Watch outA firmware update that is interrupted can leave the machine unbootable. Do this only after the cheaper fixes above, and only from the manufacturer's own file for your exact model.
- Check BitLocker status first with
When it is the hardware, not Windows
Microsoft's own text points at hardware for this code more readily than for most. These signs suggest the card, not the driver:
- Crashes only under sustained GPU load, and reliably at a similar temperature or elapsed time.
- A history of Display Event 4101 warnings escalating in frequency before the crashes began.
- Visual artefacts - flickering, coloured speckles, corrupted textures - before or during the failure.
- The problem persists after a clean driver install with DDU, and across multiple driver versions.
- Underclocking below stock speeds makes it measurably better.
- The fault follows the card into a different machine.
- The card previously had a repair, a reflow, or a period of heavy sustained use.
The last two are conclusive on their own. If the fault travels with the card, no amount of driver work will help - and if underclocking below the card's own rated speeds restores stability, the hardware is no longer able to meet its specification. That is a replacement, not a configuration problem.
Frequently asked
How is this different from 0x116 VIDEO_TDR_FAILURE?
They describe the same underlying situation - the GPU stopped responding - caught by different mechanisms, and on modern Windows you are considerably more likely to see the TDR codes.
0x116 comes from Timeout Detection and Recovery, the graphics-specific system that tries to reset the GPU and carry on; it bugchecks when that reset fails. 0xEA comes from the general kernel watchdog noticing a driver thread that never returned. The practical fixes are largely the same, but the driver name in parameter 3 is more directly available here.
If you are seeing both codes on the same machine, treat that as one hardware problem rather than two software ones.
Parameter 4 is 1. What does that tell me?
Nothing at all, and this is worth being clear about because it looks like data. On the blue screen parameter 4 is always 1 - Microsoft documents it as a fixed value there. It only carries a count when a kernel debugger is attached and intercepting the bugcheck, where it means the number of times the intercepted 0xEA was hit.
So a 1 read from Event Viewer or a crash screen is not a count of anything, and does not mean this was the first occurrence.
It names nvlddmkm.sys. Is my card dying, or is it the driver?
The filename alone cannot distinguish those, because the driver is the thing that reports the stall either way. Use the load pattern instead: failures only under sustained load, at repeatable temperatures, with artefacts, and persisting across driver versions point at the card. Failures that started with a specific driver version and stop when you roll back point at the driver.
The cheapest decisive test is underclocking below stock. If that fixes it, it is the hardware.
Can I just increase the watchdog timeout so it stops crashing?
You would be silencing the alarm rather than fixing the fire, and it does not work in the way people hope. The registry timeout values that circulate for this relate to the TDR mechanism, and raising them means the machine freezes for longer before crashing anyway - or hangs indefinitely instead of restarting.
The driver is stuck waiting for hardware that is not responding. Giving it more time to wait does not change that.
The driver named is not a graphics driver at all.
Then follow the name, not the reputation of the code. 0xEA is about any device driver spinning on unresponsive hardware; graphics simply dominates the statistics. A storage controller, capture card, audio interface or USB controller driver appearing in parameter 3 redirects the whole investigation to that device.
Apply the same structure: update or clean-install that driver first, then check whether the device itself is failing, then remove it entirely as a test.
Related errors
- 0x00000116VIDEO_TDR_FAILUREThe GPU stopped answering and Windows gave up waiting. Driver, heat, power, or a dying card.
- Display 4101Display driver stopped responding and has successfully recoveredThe GPU hung and recovered. Count incidents, not records - NVIDIA logs four per event.
- 0x00000133DPC_WATCHDOG_VIOLATIONA driver hogged the CPU past a hard deadline. Storage firmware and SATA drivers cause most of them.