Fix VIDEO_TDR_FAILURE (nvlddmkm.sys) Windows 11
If your Windows 11 blue screen names VIDEO_TDR_FAILURE and points at nvlddmkm.sys, do a clean driver reinstall with Display Driver Uninstaller before anything else. Not a driver update over the top of the old one — a full clean removal in Safe Mode, then a fresh install of the current driver from nvidia.com. That single step resolves this more often than every other fix combined, because a huge share of TDR timeouts trace back to a botched or leftover driver install rather than a truly failing GPU.
Here's why that's the right first move, and what to do with the cases it doesn't fix.
What a TDR timeout actually is
TDR stands for Timeout Detection and Recovery, and it's not a bug — it's a Windows feature that's supposed to save you from a hard crash. Microsoft's bug check reference for 0x116 lays out the mechanism: when the GPU appears hung processing a demanding operation, Windows' GPU scheduler calls the display driver's reset function and gives it a short window — two seconds by default — to reinitialize and recover. Most of the time this works invisibly, and you'll see a small notification that the display driver stopped responding and recovered. VIDEO_TDR_FAILURE, bug check 0x116, is what happens when that recovery attempt itself fails, or when more than five TDR events pile up within one minute. At that point Windows can't safely continue and bugchecks instead.
nvlddmkm.sys is NVIDIA's kernel-mode display driver, and it's usually the module named directly in the crash because it's the code Windows called to do the reset. That doesn't automatically mean the driver package is broken — it means the driver was the thing on the hook when the GPU didn't respond in time, and the actual root cause behind that ranges from a genuinely corrupt driver install to a struggling power supply to a GPU that's simply being asked to do more than it can at its current settings.
Confirm which one you actually have before you start swapping hardware
| Pattern | Confirming check | Fix |
|---|---|---|
| Started right after a driver update or Windows Update | Settings → Windows Update → Update history, or Device Manager → Display adapter → Driver → Driver Date | Clean reinstall with DDU, or roll back to the last known-good version |
| Only happens during gaming or rendering, never at idle | Monitor GPU temp and clock behavior in HWiNFO or the NVIDIA app during the workload | Check for thermal throttling or an unstable overclock; back off both |
| Happens randomly, including at idle or light browser use | Check Event Viewer for repeated Display or nvlddmkm entries with no load pattern | Suspect PSU, PCIe power connectors, or a failing card rather than settings |
| Started after a GPU overclock or undervolt (yours or a factory OC utility) | Reset clocks/voltage to reference in MSI Afterburner or the NVIDIA app, retest | Revert to stock; reintroduce a lighter overclock later if you want to chase it |
| Happens specifically with certain games or one demanding application | Check whether that title has a known TDR-related issue in its own community/support channels | Update the game/app first; it may be pushing shader compilation or memory patterns that expose the driver bug |
Why the clean reinstall works so often
NVIDIA driver packages install a lot of moving parts beyond the core .sys file — telemetry services, the NVIDIA app or old GeForce Experience overlay, HDCP components, and leftover registry entries from every previous version you've ever installed. An in-place update over that pile doesn't always clear out a corrupted piece from three versions ago, and I've seen systems where the crash disappeared the moment DDU removed a stray, mismatched component the standard installer's uninstaller had missed. Boot into Safe Mode, run Display Driver Uninstaller, select your GPU brand, and let it do a full clean. Reboot to normal mode, and install the current driver directly from nvidia.com rather than letting Windows Update reinstall its own generic version afterward — Windows Update's version lags behind and doesn't always include the same fixes.
Do this before you touch a single BIOS setting or start reseating hardware. It costs fifteen minutes and it's non-destructive.
What I would not do
- Immediately increase TdrDelay in the registry. You can raise the two-second timeout that governs when Windows decides the GPU is unresponsive, and forum posts love this fix because it makes the symptom go away — the blue screen stops because Windows waits longer before declaring a failure. That doesn't fix whatever is actually making the GPU take too long to respond. It just hides it, and it can mask a genuinely dying card until it fails outright.
- Jump straight to an RMA. NVIDIA and most vendors expect you to have ruled out drivers, power delivery, and overclocking first, and a clean DDU reinstall plus a PSU check takes far less time than a warranty claim.
- Reinstall Windows because "it's probably corrupted." This is a GPU-driver-and-hardware bug check, not a Windows system file problem. A reinstall very rarely fixes it and costs you a day.
- Assume it's always the GPU dying. A marginal PSU, a loose 12VHPWR or 8-pin connector, or an aggressive factory overclock on the card produce the exact same 0x116 signature as a genuinely failing GPU.
If the clean reinstall doesn't fix it
Move to the power delivery path next, since it's the second most common cause I run into after driver corruption. Check the physical connector at the GPU for discoloration or looseness, and if you're on a 12VHPWR/12V-2x6 connector, make sure it's fully seated — these have a well-documented history of partial-seating issues that cause exactly this kind of intermittent failure under load. Use HWiNFO to watch the 12V rail during the workload that triggers the crash; a voltage sag right before the timeout points at the PSU rather than the card. If you've overclocked or undervolted the GPU with MSI Afterburner or the NVIDIA app, reset to reference clocks and retest — an unstable curve is a common self-inflicted cause, especially undervolts pushed too aggressively for the silicon lottery you got.
Only after drivers, power, and clocks are all ruled out should you start suspecting the GPU itself. If a second, known-good graphics card in the same system doesn't crash under the same workload, that's a fairly conclusive result — either an RMA on the original card or a case to open with the reseller.
My take
Nine times out of ten this is a driver problem that a proper clean install fixes, and I'd rather spend fifteen minutes on that than an hour theorizing about failing silicon. Where I stop trusting a driver explanation is when the crash survives a genuinely clean DDU reinstall of the current driver and shows up even at idle — that pattern points at power delivery or the card itself, and no amount of driver reinstalling will touch it. If you're at that point, check the PSU and connector before you spend money on a new GPU; it's the cheaper thing to be wrong about.