How to Fix VIDEO_TDR_FAILURE (0x116) on Windows 11: GPU Driver and Hardware Troubleshooting

Most of that order holds up when checked against Microsoft's own documentation. One step needs a stronger warning than the guide gives it, and we cover that below.

What 0x116 actually means​

Microsoft's bug check reference puts it plainly: the VIDEO_TDR_FAILURE bug check has a value of 0x00000116, and it indicates that an attempt to reset the display driver and recover from a timeout has failed.

TDR stands for Timeout Detection and Recovery, a feature of the Windows Display Driver Model:

• Windows notices that the GPU has taken too long to finish a job. Microsoft's documentation sets the default timeout at two seconds.
• It tries to preempt the job, then resets the driver and the GPU.
• If the reset works, you see a screen flicker and the message "Display driver stopped responding and has recovered." Windows logs the event.
• If it fails, the operating system tells the driver not to access the hardware or memory and gives it a short time for currently running threads to complete. If the threads don't complete within the timeout, the system bug checks with 0x116 VIDEO_TDR_FAILURE.

There is a second way to reach the same blue screen. The system can also bug check with VIDEO_TDR_FAILURE if multiple TDR events occur in a short period of time. According to Microsoft's TDR documentation, the default limit is more than five GPU hangs and recoveries within one minute.

This has a practical consequence. A recovered timeout that you shrugged off last week is a warning sign that deserves attention.

Microsoft's list of possible causes is broad:

• display drivers that need updating so they handle TDR properly
• overclocked components
• incorrect component compatibility or memory timings
• insufficient cooling
• insufficient power
• defective parts such as memory modules or motherboards
• too much background load

The stop code by itself does not prove that the GPU is dead or that the driver is at fault.

Summary: 0x116 means Windows tried to reset a hung GPU and the reset failed. The causes include drivers, settings and hardware.

Before you start: prerequisites​

Shattered estimates about an hour for a typical gaming PC. Have these ready:

• An administrator account. Microsoft Support notes that you must be signed in with administrator permissions to roll back drivers.
• Your BitLocker recovery key, if the drive is encrypted. Changing boot settings for Safe Mode can trigger a recovery prompt.
• A USB stick or a second device, so you can stage driver installers and tools before you go offline.
• A repeatable trigger for the crash, such as a particular game, benchmark or render job. Without one, you can't tell whether a fix worked.
• For laptops, the manufacturer's support page. Shattered reports that AMD recommends the OEM driver for laptops and all-in-ones because those packages include system-specific validation.

Phase 1: Collect evidence before changing anything​

Step 1: Write down the symptoms and record the current driver​

Note what you were doing when the crash happened, how long the PC had been on, and whether it crashed after a recent driver, game or hardware change. These notes give your testing a structure. They don't diagnose anything on their own.

Next, record the driver you're running now. In an elevated Terminal, run:

Get-CimInstance Win32_VideoController | Select-Object Name, DriverVersion, DriverDate, Status | Format-List

NVIDIA cards report a Windows-style version string rather than the familiar driver number. Shattered's conversion rule: remove the dots, keep the last five digits, and put a decimal point before the final two. AMD likewise reports a Windows Driver Store version (32.0.x) that doesn't match the Adrenalin release number. That mismatch is normal.

Step 2: Read the event logs​

Two kinds of entries matter:

Microsoft's own advice for people who aren't using a debugger starts here too: check the System Log in Event Viewer for other error messages that might help identify the device or driver that is causing this bug check, and if a driver is identified in the bug check message, disable the driver or check with the manufacturer for driver updates.

Run perfmon /rel to open Reliability Monitor. It lines up crashes against software and driver installs on a timeline, which often answers the question "what changed?" in seconds.

Step 3: Read the minidump, but don't over-read it​

Small dumps are stored in %SystemRoot%\Minidump when small memory dumps are enabled. You can check that setting under System Properties → Advanced → Startup and Recovery → Settings. Shattered also suggests looking in %SystemRoot%\LiveKernelReports\WATCHDOG, where Windows keeps reports for GPU hangs it survived.

Install WinDbg (Shattered suggests winget install Microsoft.WinDbg), open the newest .dmp file, and run !analyze -v. Then look at MODULE_NAME and IMAGE_NAME. Microsoft's own sample output shows MODULE_NAME: nvlddmkm and IMAGE_NAME: nvlddmkm.sys, and you can use the lm (List Loaded Modules) command to display information about the faulting driver, including the timestamp. For example, lmvm nvlddmkm confirms which driver build actually crashed.

Shattered matches the common module names to vendors:

• nvlddmkm.sys: NVIDIA
• amdkmdag.sys or atikmpag.sys: AMD
• igdkmd64.sys: Intel

Treat the module name as a lead, not a verdict. Microsoft's article on reading small dumps warns that because they hold limited information, faults not directly caused by the thread running at the time of the crash may not show up. Wondershare's Recoverit guide makes a similar point: the filename helps narrow the next check, but it does not prove your graphics card is physically damaged. If the dump names a non-graphics module, such as a storage, network or anti-cheat driver, a GPU driver reinstall may be the wrong fix.

Summary: Event 4101 entries mean the system is struggling but recovering. Event 1001 with 0x116 means recovery failed. The dump tells you which module was running at the time, not necessarily which one caused the fault.

Phase 2: Rule out hardware, power and overclocks​

Step 4: Check temperatures, cables and seating​

Power down, unplug, and check that every GPU power connector is fully seated. A half-inserted high-current connector is an obvious suspect for intermittent crashes. Reseat the card, clean dust off the heatsink, confirm all the fans spin, and watch temperatures while you run your trigger. If you can borrow another PC, test the card there. If it works fine in the other machine, your own power supply, slot or motherboard moves up the suspect list.

Step 5: Go back to stock settings​

For the duration of testing, Shattered recommends resetting:

• GPU core and memory offsets, custom fan curves and power limits
• XMP or EXPO memory profiles (drop to JEDEC defaults)
• CPU undervolts such as Curve Optimizer offsets
• the power plan (use Balanced or a standard plan)

Then run Windows' built-in checks:

mdsched.exe
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

Memory testing appears in Microsoft's own 0x116 guidance. After the reboot, look for the MemoryDiagnostics-Results entry in the System log. If the crashes stop at stock settings, reapply your tweaks one at a time until the crash comes back.

Step 6: Create a safety net​

Checkpoint-Computer -Description 'pre-TDR-fix' -RestorePointType MODIFY_SETTINGS
pnputil /enum-drivers > "$env:USERPROFILE\Desktop\drivers-before.txt"

System Protection must be turned on for the restore point command to work. By default Windows allows only one restore point per 24 hours, so an error here may simply mean a recent point already exists.

Phase 3: Test driver versions in both directions​

Step 7: Roll back​

If the trouble started after an update, Microsoft Support's procedure is: right-click Start → Device Manager → expand Display adapters → right-click the GPU → Properties → Driver tab → Roll Back Driver → choose a reason → Yes → restart if prompted.

If the button is greyed out, Windows has no earlier package in its Driver Store. That's common after a clean install. In that case, download the previous version from the GPU vendor's official site. Microsoft Support also advises against downloading drivers from anywhere other than the manufacturer.

Step 8: Install the newest vendor package over the top​

If the rollback didn't help, test the newest driver instead. Shattered names the builds it considers current as of mid-November 2026:

• NVIDIA: Game Ready 621.24 WHQL
• AMD: Adrenalin 26.11.1 Optional, with 26.10.1 WHQL listed as the recommended branch
• Intel: Graphics Driver 32.0.101.9175

We could not independently confirm these version numbers or dates, so check the vendor's page before relying on them. Shattered itself says it found nothing showing that the newest NVIDIA build fixes any TDR bug. You're testing a hypothesis, not applying a known cure.

Shattered also reports that AMD's current release notes still list intermittent driver timeouts in specific games. If your crash only happens in one title, look in that game's frame generation and upscaling settings before reinstalling anything.

Phase 4: Clean reinstall with DDU in Safe Mode​

Step 9: Stage the files and boot to Safe Mode​

Display Driver Uninstaller (DDU) is a free third-party tool. Wagnardsoft's own page says the vendors had nothing to do with it and that Safe Mode is the best place to run it for stability. It also recommends making a backup or restore point first and says you don't need to uninstall the driver beforehand.

Download the driver you want to end up on and the DDU archive. Extract DDU to its own folder rather than running it from inside the zip. Then disconnect from the internet, so Windows Update can't install a generic driver as soon as the old one is removed.

To boot into Safe Mode, you have two options:

• From the command line (elevated): bcdedit /set {current} safeboot minimal, then shutdown /r /t 0
• From the menus: Settings → System → Recovery → Advanced startup → Restart now → Troubleshoot → Advanced options → Startup Settings → Restart, then press 4 (Microsoft's guidance lists options 4, 5 or 6 for the Safe Mode variants)

Step 10: Clean, clear the flag, reinstall​

1. In DDU, set the device type to GPU, choose your vendor, and click Clean and restart.
2. If you used bcdedit, the PC boots back into Safe Mode. Clear the flag with bcdedit /deletevalue {current} safeboot and reboot. Forgetting this step leaves you in a Safe Mode loop.
3. With the network still disconnected, run the vendor installer you staged.
4. Reconnect to the internet only after the first successful boot on the new driver.

On a hybrid laptop, reinstall the manufacturer's driver package. On a desktop with an integrated GPU and a separate graphics card, clean only the vendor you're troubleshooting.

How you know it worked: Re-run the Step 1 query. The Name and DriverVersion should match the package you installed, and Status should read OK. If the name shows Microsoft Basic Display Adapter, the install didn't finish.

Phase 5: Verify, and think twice about the registry​

Step 11: Stress test and compare​

Run your original trigger for at least two full sessions, then query Event ID 4101 again. If there are no new recovered timeouts after several hours, that's a good sign. A few new ones mean you should go back to temperatures and power.

Step 12: TDR registry values — this is where we part ways with the guide​

Shattered treats TdrDelay as a last resort. It argues that a measured increase can be legitimate for long GPU compute jobs such as local AI inference or rendering, and its example sets the value to 10 seconds. It also reports that Microsoft Q&A guidance advises against starting with TDR registry values because they can mask the real fault.

Microsoft's official documentation goes further. Its "Testing and debugging TDR during driver development" page says these keys are meant for testing or debugging during driver development and that end users shouldn't manipulate them. The same page documents the defaults:

• TdrDelay: 2 seconds (the timeout threshold)
• TdrDdiDelay: 5 seconds
• TdrLimitCount: 5 recoveries within TdrLimitTime
• TdrLimitTime: 60 seconds

Our advice: don't use registry edits to fix gaming crashes. If you inherited a machine, or forgot an old tweak, check whether one is already set:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" /v TdrDelay
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" /v TdrDelay /f

If the query returns an error saying the value doesn't exist, Windows is using its built-in default. A leftover TdrDelay value doesn't fix anything. It just makes your GPU hang longer before Windows steps in.

Troubleshooting the troubleshooting​

Two more ideas from Shattered for stubborn cases:

• Hardware-accelerated GPU scheduling. Turn it off or on under Settings → System → Display → Graphics, reboot, and run your trigger again.
• Clean boot. Use msconfig to rule out overlays, RGB software and capture tools that hook into the graphics path.

Shattered also mentions Driver Verifier (verifier.exe) but warns it can cause boot loops. Only use it if you have a restore point and know how to run verifier /reset from Safe Mode.

The bottom line​

The order of steps is what makes this guide useful. Many forum threads jump straight to DDU or a TdrDelay edit. Collecting evidence first, testing driver versions in both directions, and only then doing a clean reinstall means you're less likely to spend an evening fixing the wrong thing.

Where it overreaches:

• It reads dump module names as more conclusive than Microsoft does.
• Its driver version numbers and dates are time-sensitive and should be checked against the vendors' own pages.
• Its registry step needs Microsoft's stronger warning.

If a clean driver, stock clocks, a passing memory test and a healthy system image still end in 0x116, Microsoft's guidance points to the manufacturer's hardware diagnostics and testing components one at a time. At that point, check your warranty before you reinstall the driver yet again.