VIDEO_TDR_FAILURE 0x00000116 – display driver stopped responding

Fix it now

0x00000116 has two documented paths to it: an attempt to reset the display driver and recover from a timeout failed, or more than five TDR events occurred inside one minute. Microsoft’s first listed resolution for both is to install the latest updates for the display driver, so start there even if the crash feels hardware-shaped.

!analyze -v

1. Install the current display driver from AMD, Intel or NVIDIA directly. If the newest release crashes, install the previous long-lived branch instead.
2. Note whether the crash happens under 3D load, during video playback, or at idle. Load-related crashes weight the hardware causes; idle crashes weight the driver.
3. Remove any factory or user overclock on the card and set the power limit back to default. Microsoft lists over-clocked components among the causes for this bug check.
4. Check temperatures under sustained load, clean dust from the heatsink and confirm the fans spin. Insufficient cooling and insufficient power are both on Microsoft’s list.
5. Reseat the card and both PCIe power connectors, and test with a different display cable and a different port.

Do not fix this by raising TdrDelay. Microsoft’s own note on those registry keys is that they are for testing and debugging during driver development only, and that end users and applications should not manipulate them.

If the crashes stop after a clean driver install, stop here. The next section explains the two paths to this bug check and why both keep the driver in scope.

Why it happens

Windows watches how long the GPU takes to complete work it has been given. The default timeout threshold is two seconds. If the adapter has not finished within it, the GPU scheduler calls the display miniport driver’s reset routine to reinitialise the driver and reset the GPU. When that works you get a brief black screen and a message that the display driver stopped responding and has recovered, and no bug check at all – that recovery event is 0x00000117, which Microsoft states can never be used for a real bug check because it identifies live dumps only.

There are two ways that becomes 0x00000116. The first is the reset failing: during recovery the OS gives running threads a short time to leave the driver, five seconds by default, and bug checks if they do not. The second is quantity – Microsoft states that the system can also bug check with VIDEO_TDR_FAILURE if multiple TDR events occur in a short period of time, with the default being more than five TDRs in one minute. In that second case every individual reset succeeded.

That second path is the reason not to conclude “the reset failed, so this must be hardware”. Five recoverable timeouts inside a minute produce the same stop code as one unrecoverable one, and repeated recoverable timeouts are exactly what a bad driver or a shader compilation problem looks like. Microsoft’s own first resolution is to install the latest display driver updates so the driver properly supports the TDR process.

Hardware is genuinely on the list too, and Microsoft names the items: over-clocked components such as the motherboard, incorrect component compatibility and settings especially memory configuration and timings, insufficient system cooling, insufficient system power, and defective parts. There is a software entry as well – visual effects or too many background programs slowing the machine so the video card cannot respond as required.

Full reference

The TDR registry keys, and why you should not change them

They live under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers. Microsoft’s note on the whole set is that they are for testing and debugging during driver development only, and that end users and applications should not manipulate them. The advice circulating elsewhere to raise TdrDelay until the crashes stop is not a supported fix – it widens the window in which a hung GPU is tolerated, and if TdrLevel is set to 1 a detected timeout becomes an immediate bug check with no recovery attempted at all.

How the counters fit together

1. The GPU exceeds TdrDelay, two seconds by default. The scheduler calls the driver’s reset routine.
2. If threads do not leave the driver within TdrDdiDelay, five seconds by default, the OS bug checks with 0x116.
3. If the reset succeeds, the event is logged as 0x00000117 – a live dump identifier, not a bug check – and the user sees the recovery message.
4. If more than TdrLimitCount of those, five by default, occur within TdrLimitTime, sixty seconds by default, the system bug checks with 0x116 anyway.
5. That is why both a single hard hang and a burst of recoverable stutters produce the same stop code.

The neighbouring graphics bug checks

0x000000EA is the one to read carefully if you get it, because Microsoft’s own cause statement is unusually pointed: a device driver spinning in an infinite loop, most likely waiting for hardware to become idle, usually indicating a problem with the hardware itself or with the driver programming the hardware incorrectly – and frequently the result of a bad video card or a bad display driver. Parameter 3 is a pointer to the offending driver name.

Working through it in order

• Replace the driver first. It is quick, free, and it is Microsoft’s first listed resolution.
• Then remove overclocks and return memory settings to defaults, because those are the next items on Microsoft’s own cause list.
• Then check cooling and power delivery under sustained load rather than at idle.
• Then test the card in another machine, or another card in this one, which is the only way to separate the card from everything around it.
• Run the Windows Memory Diagnostic and the manufacturer’s hardware diagnostics, both of which Microsoft names among the resolutions.
• Check Event Viewer for related errors in the same window – also on Microsoft’s list, and frequently more informative than the bug check itself.

Every code this article covers

Confirm the fix worked

1. A sustained 3D or video workload runs without a crash and without the ‘display driver stopped responding and has recovered’ message.
2. No new dump appears in %SystemRoot%\Minidump after the test.
3. GPU temperatures stay within the manufacturer’s stated range under that load.
4. The fix holds with clocks and power limits at their normal settings, not only with the card underclocked.

Questions people ask about this