0x00000116 VIDEO_TDR_FAILURE
Windows sent work to the graphics card and the card did not respond within the timeout. Rather than hang forever, Windows attempts to reset the driver - a mechanism called Timeout Detection and Recovery. When the reset works you get a brief black screen and a notification. When it fails, you get bugcheck 0x116.
What you are looking at
Your PC ran into a problem and needs to restart.
Stop code: VIDEO_TDR_FAILURE
What failed: nvlddmkm.sys
In Event Viewer the matching entries look like this:
Log Name: System
Source: Display
Event ID: 4101
Level: Warning
Display driver nvlddmkm stopped responding and has successfully recovered.Log Name: System
Source: nvlddmkm
Event ID: 153
Level: Error
Error occurred on GPUID: 100What the error actually means
The graphics driver is not like other drivers. It hands large batches of work to a processor that runs independently of the CPU, and it cannot simply wait forever for an answer - a hung GPU would freeze the entire desktop with no way back.
So Windows applies a deadline, two seconds by default. When it expires, the GPU scheduler calls into the display miniport driver's reset routine to reinitialise the driver and reset the hardware. During that reset the operating system instructs the driver not to touch hardware or memory, and gives any currently running threads a short window to finish.
If those threads complete, recovery succeeds: you see a black screen for a second, the desktop returns, and Event 4101 appears in the log. Most people never look.
Bugcheck 0x116 is what happens when they do not. The reset itself failed to complete, so there is nothing left to do but stop. That distinction matters - this code does not mean the GPU merely timed out, it means the recovery designed to handle a timeout could not finish either.
The consequence for diagnosis: the timeout is a symptom, not a cause. The question is always why the GPU stopped answering, and the answers range from a driver bug to a card that is physically failing.
Reading the parameters
Parameter 2 is the one worth reading. The others need a debugger to mean anything.
| Parameter | What it holds |
|---|---|
| 1 | Pointer to the internal TDR recovery context. Only useful inside a debugger, and often not populated at all. |
| 2 | Pointer to the responsible driver module. This resolves to a name - nvlddmkm.sys for NVIDIA, amdkmdag.sys for AMD, igdkmd64.sys for Intel. It confirms which display stack timed out, which matters on laptops with two GPUs. |
| 3 | The NTSTATUS or vendor error code from the last failed operation. Occasionally distinguishes a hang from a fault on the card itself, though vendor values are largely undocumented. |
| 4 | Internal context-dependent data. Not useful outside vendor engineering. |
What actually triggers it
The order here reflects what resolves cases in practice. Note how much of it is not the driver, despite the driver being what gets named.
| Cause | How often | Detail |
|---|---|---|
| Driver bug or a damaged driver installation | Common | Either a genuine regression in a specific release, or leftovers from upgrading in place over several versions. The second is more common than people believe and is why a clean reinstall is the standard first move. |
| Windows Multi-Plane Overlay (MPO) | Common | A compositing optimisation that has a long history of causing flicker, black screens and TDRs on multi-monitor and mixed-refresh-rate setups. It is under-known because the symptoms look exactly like a hardware fault, and disabling it is a well-established remedy. |
| Thermals - especially memory junction temperature | Common | Core temperature can look perfectly reasonable while VRAM runs far hotter. On cards that expose a memory junction reading, sustained values near the manufacturer's limit produce exactly this failure. Aged thermal pads are a frequent cause on older cards. |
| Power delivery and transient spikes | Occasional | Modern GPUs draw brief spikes well above their rated power. A supply that is adequate on paper can dip on those transients, and the card stops responding. Daisy-chained PCIe cables make it worse. |
| Unstable overclock or undervolt curve | Occasional | Applies to factory overclocks too, not just manual ones. An undervolt that is stable in benchmarks often is not stable at the low-load, high-clock states the desktop actually uses. |
| Failing VRAM or GPU silicon | Occasional | Produces artefacts alongside the timeouts, or timeouts that follow the card into another machine. This is where the diagnosis ends up when everything else has been eliminated. |
| Physical link problems | Occasional | A poorly seated card, a marginal riser or a degrading slot. Look for WHEA-Logger entries in the same window - if both are present, treat them as one fault rather than two. |
Narrowing it down
Before changing anything, establish the shape of the problem. Three questions do most of the work.
Count the recoverable timeouts, not just the crashes
Event 4101 fires every time the driver times out and recovers - which happens far more often than a full bugcheck. It is the early-warning version of the same fault:
Get-WinEvent -FilterHashtable @{LogName='System'; Id=4101} |
Select-Object TimeCreated, Message |
Sort-Object TimeCreated |
Format-Table -AutoSize -WrapA history of 4101 events building up before the first blue screen tells you this has been developing for a while. It also gives you a rate to measure against once you start making changes.
Establish what the card is doing when it happens
Run monitoring software that logs to a file - HWiNFO64 is the usual choice - and capture core temperature, memory junction temperature, board power draw and clock speeds during normal use. Then check the readings at the timestamp of a timeout.
A memory junction reading near its limit, or power draw hitting a hard ceiling at the moment of failure, identifies the cause immediately and saves you from reinstalling drivers for a week.
Test at stock settings and on a single display
Remove every variable at once as a baseline: clear any overclock or undervolt, disconnect all monitors but one, and set that one to a standard refresh rate rather than its maximum.
If the timeouts stop, reintroduce one variable at a time. Multi-monitor setups with mismatched refresh rates are a genuinely common trigger, and this test finds that in an afternoon.
Fixes, cheapest first
In order. The first two resolve a large share of cases and cost nothing.
Clean-install the display driver
Remove rather than upgrade, so nothing is left behind.
- Download the driver from the GPU vendor directly.
- Boot into Safe Mode and run Display Driver Uninstaller, choosing Clean and restart.
- Install the downloaded driver and decline bundled extras.
- If the problem began after an update, install the previous release rather than the newest.
Disable Multi-Plane Overlay
Worth trying early, because it is free, reversible, and fixes a category of case that otherwise looks exactly like failing hardware. Set the following registry value, then reboot:
reg add "HKLM\SOFTWARE\Microsoft\Windows\Dwm" /v OverlayTestMode /t REG_DWORD /d 5 /fTo undo it:
reg delete "HKLM\SOFTWARE\Microsoft\Windows\Dwm" /v OverlayTestMode /fWatch outVideo playback may use slightly more power afterwards. That is the entire downside. If it makes no difference after a few days, remove the value again so you are not carrying an unnecessary change.
Address temperatures
Clean dust from the heatsink and case filters first, and confirm the case has genuine through-flow rather than three intakes and no exhaust.
If memory junction temperature is the problem on an older card, replacing the thermal pads is the real fix. It is a well-documented procedure but it usually voids the warranty - so check warranty status before opening anything, and if the card is still covered, claim instead.
Rule out power delivery
Use a separate PCIe cable for each connector on the card rather than daisy-chaining one cable into two plugs. If you can borrow a known-good supply with adequate headroom, test with it for a week.
As a diagnostic, cap the card's power limit to around 80% in vendor software. If the timeouts stop, the card is failing on power transients rather than on logic - which points at the supply or at the card's own regulation.
Test the card in another machine
The most conclusive test available, and the one people leave until last when it should come earlier. If the timeouts follow the card into a different system, the card is faulty. If the card behaves elsewhere and a different card behaves in your machine, the fault is in the board, the slot or the power supply.
When it is the hardware, not Windows
Signals that the card or the board is genuinely failing rather than misconfigured:
- Visual artefacts - coloured blocks, scattered pixels, corrupted text - before or during the timeout.
- The timeouts follow the card into a different computer.
- The screen goes black and stays black with fans still spinning, requiring a hard power cycle.
WHEA-Loggerentries appear alongside the display events in the same log.- Temperatures are normal, settings are stock, the driver is clean, and it still happens.
- The failure rate is increasing week over week.
Once two or three of those apply, further software troubleshooting is not going to help. Keep the Event Viewer records, note the dates, and get the card or system into a warranty claim while it still misbehaves often enough to be demonstrable.
Frequently asked
Should I increase TdrDelay to stop the crashes?
No - or at least, understand what you are doing if you do. Raising TdrDelay under HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers just gives the GPU longer before Windows declares a timeout. If the card is hanging because it is overheating or losing power, the hang still happens; you have only extended how long the desktop freezes first. It is a legitimate tool for developers debugging long compute kernels, and a way of hiding the evidence for everyone else. Disabling TDR entirely with TdrLevel is worse, because a hung GPU then locks the machine outright.
The log says nvlddmkm. Is it definitely the NVIDIA driver?
It means the NVIDIA kernel-mode driver was the component that stopped responding, which is not the same as it being at fault. The driver is equally the one that reports a hang caused by heat, power or failing memory. Treat the name as identifying which GPU stack timed out - useful on hybrid laptops - not as a verdict.
What is the difference between Event 4101 and bugcheck 0x116?
Same mechanism, different outcome - but the code that pairs with a recovered timeout is 0x117, not 0x116, and this is widely got wrong.
Each recovered hang produces a VIDEO_TDR_TIMEOUT_DETECTED (0x117) live dump while Windows keeps running. Microsoft documents 0x117 as a code that can never be used for a real bugcheck - it exists only to tag live dumps. That is what a Display Event 4101 corresponds to.
0x116 is specifically the failure case: either the reset did not complete within its own timeout, or the rate limit was hit. That limit is documented - six or more GPU hangs within one minute promotes the situation to a real bugcheck. So a machine producing 4101s regularly is indeed heading toward 0x116, and there is a published number for how close it is.
It only happens in one game. Is that still hardware?
It can be. A single title is not proof of a software bug - games load the card in distinctive ways, and one that pushes an unusual power or thermal profile will expose a marginal card first. Check whether that title runs the card hotter or at higher sustained power than anything else you run. If capping the frame rate or the power limit stops it, that points at the hardware margin rather than at the game.