Display Driver Stopped Responding: Real Fix for TDR Crashes

Your screen goes black for two seconds, then Windows pops a notification that the display driver crashed and recovered. Here's why it happens and how to actually fix it.

You're 40 minutes into a ranked match, the screen freezes, goes black for two seconds, comes back, and Windows dings at you: "Display driver nvlddmkm stopped responding and has recovered." Or it's amdkmdap. Or it's just a hard lock and the GPU fans spin up to max. Either way, the game session is gone and the driver has already restarted itself. What's actually happening here is Windows' Timeout Detection and Recovery system — TDR for short — decided your GPU stopped answering the OS within two seconds, killed the driver process, and reloaded it.

The trigger is almost always one of four things: VRAM pressure in a specific game scene, an unstable overclock, a driver-side regression, or a power delivery problem under transient load spikes. The tricky part is that TDR isn't usually the disease. It's Windows triaging a GPU that got stuck.

What TDR actually does

The reason step 3 (below) works on some setups and not others comes down to how TDR is wired. Windows gives every GPU driver exactly 2 seconds to respond to a command from the graphics kernel. If the driver doesn't answer in that window — because it's stuck decoding a shader, waiting on a stalled VRAM read, or deadlocked on a fence — Windows assumes the GPU is hung, resets it, and reloads the driver. You see a black flash and a recovery toast. The full reset is what makes the toast appear; a partial reset just gives you a stutter you probably never notice.

TDR exists because in the Vista era, a hung GPU meant a hung desktop. Microsoft's fix was to time out the driver instead of the whole system. That means a TDR event is a symptom that the GPU took too long — not proof the GPU is dying.

Real-world trigger: launching Cyberpunk 2077 with ray tracing enabled on a 12 GB card already holding Chrome, Discord, and a second monitor's worth of desktop composition in VRAM. The game slams into a texture streaming cliff, the driver blocks on a VRAM commit, and 2 seconds later TDR fires.

The fix

Rule out a bad driver install first. Use DDU (Display Driver Uninstaller) in safe mode, then install the latest WHQL driver for your GPU. Skip the "game ready" beta branch unless you specifically need its fixes. The reason this matters: driver regressions produce identical TDR signatures to hardware faults, and reinstalling through Device Manager leaves stale files behind. DDU doesn't.
Pull every overclock back to stock. GPU core, GPU memory, and — yes — CPU and RAM. A seemingly stable +150 MHz memory overclock on a 4070 will pass 12 hours of FurMark and still crash a specific UE5 shader compile. Memory errors under load manifest as TDR because the corrupted shader output causes the driver to wait for a response that never comes. If TDR stops after reverting, you've found the cause. Re-apply one overclock at a time over a week.
Raise the TDR timeout if the crash is benign. Sometimes the GPU isn't hung, it's just slow. Heavy shader compilation, big Blender renders, and CUDA workloads can legitimately exceed 2 seconds. Extend the window:
```
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers]
"TdrDelay"=dword:0000000a
"TdrDdiDelay"=dword:0000000a
```
Save as tdr.reg, run it, reboot. Ten seconds is plenty for shader compiles; don't go past 60 or you'll turn recoverable hangs into full system freezes.
Check power delivery. If you're on a 3080/3090/4080/4090 or an RX 7900-class card, transient power spikes can exceed what a marginal PSU delivers. Symptoms: TDR under gaming load but never at idle. The fix is a quality 850 W+ PSU with separate PCIe cables — not daisy-chained. On laptops, the equivalent problem is a failing barrel jack or a worn USB-C PD charger that browns out under load.
Update the other half of the stack. Chipset drivers, motherboard BIOS, and the game's own patches. Ryzen 7000 boards shipped with AGESA versions that caused PCIe link instability under sustained load — that shows up as random TDR on an otherwise healthy GPU. Same story with early Z790 BIOS builds and certain DDR5 kits.
Watch VRAM. Open Task Manager's Performance tab, then GPU, and check "Dedicated GPU memory" during the crash window. If you're pegged at 100% right before TDR, that's your answer. Lower texture quality one notch, drop ray tracing, or turn off the second monitor. A 8 GB card on a 4K display with two browsers open is a TDR factory.

If it still fails

At this point you've ruled out software. Do these in order:

Run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth. Corrupted system files can break the WDDM handshake.
Test the GPU in a different PCIe slot, then in a different machine. TDR that follows the card is a hardware fault.
Check Event Viewer → Windows Logs → System for Event ID 4101 (the TDR toast) alongside any WHEA-Logger events. WHEA errors alongside TDR point at PCIe signal integrity or a dying card, not a driver bug.
If VRAM errors show up in OCCT's VRAM test or the card is under three years old, RMA it. TDR clusters that appear only under sustained load, with no overclock and a clean driver, are usually memory controller degradation.

One more thing: if you see the crash on a laptop with hybrid graphics, disable the iGPU in BIOS or force the discrete GPU for that specific game in Windows Settings → Display → Graphics. Optimus switching is a common TDR source on 11th-gen Intel and Ryzen 5000 mobile parts.