GPU TDR and Display Driver Crash Troubleshooting Guide (VIDEO_TDR_FAILURE 0x116)

A GPU Timeout Detection and Recovery (TDR) crash occurs when Windows detects that the graphics hardware has stopped responding within a set time limit (defaulting to 2 seconds for processing and 5 seconds for driver interface calls), resulting in a brief black screen, Event ID 4101, or a VIDEO_TDR_FAILURE (0x116) blue screen. Resolving TDR crashes requires isolating automated Windows Update driver overwrites, performing an offline Display Driver Uninstaller (DDU) clean installation, configuring registry execution timeouts for intensive compute workloads, and eliminating hardware-level PCIe or transient power delivery instability.

Understanding the Windows TDR Engine and Error 0x116

Timeout Detection and Recovery (TDR) is a core subsystem introduced into the Windows Display Driver Model (WDDM) to prevent anomalous graphics operations from locking up the entire operating system. Prior to TDR implementation, an unresponsive graphics execution pipeline resulted in a complete system freeze, requiring a hard power cycle. Under modern Windows kernel architectures, the OS monitors the GPU scheduler and initiates a controlled driver reset whenever hardware fails to complete a task within a predefined time window.

The operational mechanism functions through two distinct phases: detection and recovery. If a graphics processing unit (GPU) scheduler preempt request is delayed longer than the threshold defined by the operating system, Windows terminates the active graphics context and resets the display driver binary (such as nvlddmkm.sys for NVIDIA, amdkmdag.sys for AMD, or igdkmd64.sys / igfx for Intel). If the driver re-initializes successfully, the desktop interface restores, the user sees a temporary black screen, and Windows logs Event ID 4101 in the System Event Log stating that the display driver stopped responding and has recovered.

When the recovery routine fails—or when execution threads are unable to exit the driver stack within the secondary interface timeout window—the kernel executes a bug check. This generates a Blue Screen of Death (BSOD) with the stop code VIDEO_TDR_FAILURE (0x116). In severe cases involving abrupt hardware power loss or bus desynchronization, secondary crashes such as 0x1000007E or storage dump write failures (volmgr Event ID 162) occur because the kernel loses low-level communication before the crash dump file can be completely serialized.

Metric / Component Default Windows Value Kernel Manifestation Primary Failure Trigger
TdrLevel 3 (Recover on timeout) Desktop reset or BSOD Driver hang or hardware freeze
TdrDelay 2 Seconds Event ID 4101 / Black screen Long-running shader or compute kernel
TdrDdiDelay 5 Seconds BugCheck 0x116 (VIDEO_TDR_FAILURE) Thread stuck inside driver DDI stack
TdrDebugMode 2 (Recover without debugger) Automated OS recovery Preemption failure in scheduler

Root Cause Analysis: Why Display Drivers Crash

Display driver crashes and TDR events are frequently misdiagnosed as purely software-related bugs. In practice, the TDR mechanism is an agnostic watchdog; it triggers whenever any factor prevents the GPU hardware or driver stack from returning execution control to the OS scheduler in time. The causal chain behind these failures generally breaks down into four operational domains: driver package corruption, OS repository overwrites, heavy computational stalls, and electrical or signal instability across the PCIe bus.

Software conflicts often originate from background installation collisions. Windows Update frequently downloads generic or legacy OEM driver packages in the background while users maintain vendor-specific Game Ready, Studio, or Intel Arc drivers. When Windows Update silently replaces driver binaries or overwrites core dynamic-link libraries and registry pointers, the active driver enters an inconsistent state, producing immediate TDR cycles upon entering 3D or accelerated 2D contexts.

Hardware-level triggers stem from electrical delivery, clock stability, and interface handshakes. High-power modern graphics cards (such as the GeForce RTX 4090 or overclocked partner variants) draw significant transient power spikes. If the power supply unit (PSU) suffers from poor dynamic transient response, or if the 12V rail drops below acceptable operational tolerances (e.g., dropping below 11.4V under sudden load), the GPU core voltage sags, leading to an immediate calculation stall that trips the TDR watchdog.

Multi-monitor environments utilizing mixed refresh rates or running concurrent mixed workloads—such as streaming hardware-accelerated video on one panel while rendering compute assets in Blender, Affinity, or 3D viewports on another—place complex asynchronous preemption demands on the GPU scheduler, substantially increasing the likelihood of hitting default timeout thresholds.

Step 1: Halting Automated Windows Update Driver Overwrites

A widespread source of persistent 0x116 and nvlddmkm.sys crashes is Windows Update overwriting installed display drivers with incompatible repository builds. Standard reinstallation routines fail because the operating system immediately reinstalls its cached driver binary upon reconnecting to a network. Halting this behavior requires enforcing system-wide device installation restrictions prior to deploying clean driver packages.

  1. Disable Automatic Device Installations via System Settings: Open the Run dialog (Windows + R), input sysdm.cpl, and press Enter. Navigate to the Hardware tab, select Device Installation Settings, choose No (your device might not work as expected), and save changes.
  2. Configure Group Policy Driver Exclusions (Windows Pro/Enterprise): Open the Run dialog, type gpedit.msc, and navigate to Computer Configuration > Administrative Templates > Windows Components > Windows Update. Double-click Do not include drivers with Windows Updates, set the policy to Enabled, and click Apply.
  3. Set Registry Exclusions for Driver Searching: Open regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching. Locate or create the DWORD (32-bit) value ChangeOrderConfig and set its value data to 0.
  4. Block Quality Update Driver Ingestion: In the Registry Editor, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings. Create a new DWORD (32-bit) value named ExcludeWUDriversInQualityUpdate and set its value to 1.
  5. Restrict Hardware ID Installation (Optional Advanced Step): In Device Manager, open the properties of your graphics card, navigate to the Details tab, and copy the lines under Hardware IDs. In gpedit.msc, navigate to Computer Configuration > Administrative Templates > System > Device Installation > Device Installation Restrictions, enable Prevent installation of devices that match any of these device IDs, click Show…, paste the IDs, and apply. Note that this policy must be temporarily set to Not Configured when you manually update graphics drivers in the future.

Step 2: Performing an Offline DDU Clean Driver Installation

Standard driver installers—even those featuring built-in “Clean Install” checkboxes—often leave residual registry entries, cached shader files, and orphaned system runtime binaries in System32\drivers. Display Driver Uninstaller (DDU) eliminates all driver traces in Windows Safe Mode, preventing conflicts between legacy driver remnants and fresh installations.

  1. Download Required Packages While Online: Download the latest stable standalone graphics driver package directly from your GPU vendor (NVIDIA, AMD, or Intel Download Center) and the latest version of Display Driver Uninstaller (DDU). Save both to a local drive.
  2. Disconnect Network Interfaces: Unplug your physical Ethernet cable or disable your Wi-Fi adapter. Maintaining complete offline isolation is critical to prevent Windows from pulling generic display adapters before the vendor installer executes.
  3. Boot into Windows Safe Mode: Hold the Shift key while clicking Restart from the Windows Start menu. Navigate to Troubleshoot > Advanced options > Startup Settings > Restart, then select Option 4 or press F4 to enter Safe Mode.
  4. Execute Driver Purge: Launch DDU with administrator privileges. Select your device type (GPU) and the active vendor (NVIDIA, AMD, or Intel). Click Clean and restart. If switching between hardware vendors (e.g., migrating from an NVIDIA GTX/RTX card to an Intel Arc B-Series or AMD Radeon), run a clean removal for the previous vendor first, then repeat for the current GPU before rebooting.
  5. Install the Clean Driver Package: Once Windows restarts normally to the desktop (still disconnected from the internet), launch the downloaded driver installer executable. For custom installations, install the core graphics driver and PhysX/OpenCL runtimes, while unchecking unnecessary bundled audio controllers or telemetry components if you suspect driver conflicts.
  6. Verify Core Driver File Deployment: Ensure the primary driver binary (e.g., nvlddmkm.sys or igdkmd64.sys) is properly registered in C:\Windows\System32\drivers before reconnecting network adapters.

Step 3: Adjusting TDR Registry Delays for Long-Running Workloads

In compute-heavy production software such as Substance 3D Painter (texture baking/PBR layering), Blender (Cycles kernel compilation and complex viewports), or oneAPI computational workloads, individual shader execution routines often exceed the default 2-second preemption limit. The Windows OS assumes the hardware has permanently hung and terminates the driver, crashing the software. Extending the timeout threshold allows complex compute passes to finish without triggering a recovery reset.

Modifying Windows Registry parameters incorrectly can lead to system instability. Always export a backup of the GraphicsDrivers key prior to modifying values, and ensure all DWORD entries match exact naming and case conventions.

  1. Open Registry Editor: Press Windows + R, type regedit, and press Enter to launch the Registry Editor.
  2. Navigate to the GraphicsDrivers Key: In the left directory tree, expand the folders to reach: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers.
  3. Create or Edit the TdrDelay Value: Right-click an empty space in the right pane, select New > DWORD (32-bit) Value, and name it TdrDelay (case-sensitive). Double-click the entry, select Decimal as the base, and set the value data to a validated starting point between 10 and 60 seconds (Adobe Substance workflows commonly recommend 60 seconds).
  4. Create or Edit the TdrDdiDelay Value: Right-click in the right pane, select New > DWORD (32-bit) Value, and name it TdrDdiDelay. Double-click, set the base to Decimal, and assign the matching timeout threshold (such as 60 seconds).
  5. Reboot to Initialize Parameters: Close the Registry Editor and restart your computer. Windows only reads these TDR thresholds during kernel initialization at boot time.

If an application still encounters driver crashes during long computations after increasing the delay, test incrementing the decimal value from 60 to 120 seconds. To revert your system back to factory defaults at any time, delete the created TdrDelay and TdrDdiDelay values or set them to 2 and 5 seconds respectively.

Step 4: Hardware-Level Isolation (Power, Clocks, and PCIe Link)

If clean driver installations and registry delay adjustments fail to stop 0x116 bug checks, the failure mechanism is almost certainly rooted in physical hardware, board firmware, or electrical power delivery. A TDR timeout occurs whenever a GPU core drops calculations due to momentary power starvation, signal degradation across PCIe lanes, or unsustainable factory overclocks.

Power Supply Regulation and 12V Rail Stability

Modern graphics cards exhibit massive microsecond-level power excursions (transient spikes) that trip internal voltage regulators. Even on power supplies with sufficient total wattage ratings, an aging unit or poor transient response can allow the +12V rail to sag. Using hardware monitoring software such as HWiNFO64, monitor your 12V input rail under combined CPU/GPU loads; drops approaching or falling below 11.4V indicate inadequate voltage regulation.

On high-draw modern architectures utilizing 12V-2×6 or 12VHPWR 16-pin power connections (e.g., RTX 4090 / 4080), inspect the connector thoroughly for uneven seating, pin terminal back-out, or thermal scorching. Ensure dedicated, separate PCIe power cables are routed from the PSU rather than daisy-chained splitters.

Clock Frequency and Core Voltage Degradation

Factory-overclocked (OC) graphics cards operate near the edge of voltage-frequency stability curves. Over extended operational lifespans, silicon degradation or thermal cycling can cause factory boost frequencies to become unstable at standard stock voltages, leading to sudden calculation drops during low-to-high power transitions.

To diagnose clock-related instability, open a GPU utility (such as MSI Afterburner) and lower the Core Clock by -20 MHz to -100 MHz, or reduce the overall Power Limit to 80%. If reducing clock speeds or power limits eliminates the TDR crashes completely, the graphics card was suffering from voltage-frequency instability under load.

PCIe Link State and BIOS Compatibility

Power-saving features across the PCIe bus can introduce latency when the GPU transitions from idle power-saving states to full 3D rendering contexts. This latency can trip the TDR watchdog before the GPU clock generators ramp up.

  1. Disable PCIe Link State Power Management: Open the Windows Control Panel, navigate to Power Options, click Change plan settings on your active plan, and select Change advanced power settings. Expand PCI Express > Link State Power Management and set both On battery and Plugged in to Off.
  2. Verify Resizable BAR (ReBAR) Support: For modern graphics architectures—especially Intel Arc discrete graphics (such as the Arc B580, B570, or A770/A750 series) where ReBAR is a core architectural requirement—verify that Resizable BAR and Above 4G Decoding are enabled in your motherboard BIOS. Operating without ReBAR causes severe memory subsystem stalls that frequently manifest as TDR crashes.
  3. Update Motherboard Firmware: Flash your motherboard to the latest stable BIOS revision to ensure proper PCIe signal training, memory compatibility, and power management microcode execution.
  4. Isolate Physical Slot Signal Integrity: If crashes persist, power down the system, reseat the GPU firmly into the primary PCIe x16 slot, or temporarily move the card to a secondary physical PCIe slot to rule out a damaged retention slot or PCB trace defect.

Display Driver TDR Troubleshooting Reference Matrix

Use the following diagnostic matrix to match specific error symptoms and event logs to their direct physical or software root causes and verified remedies.

Diagnostic Symptom Event / Log Identifier Root Cause Mechanism Resolution Action
Desktop Black Screen & Fast Recovery System Event ID 4101 (nvlddmkm / igfx) Preemption timeout (>2s) due to background task conflict or compute stall. Adjust TdrDelay to 10–60s in registry; disable hardware acceleration in conflicting 2D apps.
Immediate Blue Screen Under 3D Load BugCheck 0x116 (VIDEO_TDR_FAILURE) Thread stuck inside DDI driver stack (>5s); severe hardware calculation stall. Execute offline DDU driver purge; test core clock downclocking (-50MHz to -100MHz).
Crashes After Windows Updates Event ID 4101 recurring on new build Windows Update silently overwrote clean vendor files with cached OEM driver. Enable “Do not include drivers with Windows Updates” via GPO; reinstall clean vendor driver offline.
TDR During 3D Baking / Compute Application Error / Warning Dialog Heavy compute shader execution times exceeding the default Windows 2-second preemption limit. Add TdrDelay (60s) and TdrDdiDelay (60s) DWORDs to GraphicsDrivers registry key.
Intermittent Hard System Reboot at Idle/Load volmgr Event ID 162 / No dump written Transient power spike causing +12V rail drop (<11.4V) or 16-pin connector resistance drop. Inspect 12V-2×6 power connector seating; reduce GPU power limit to 80%; test high-tier PSU.
Arc GPU Freezing / Code 43 VIDEO_TDR_FAILURE on Intel Arc B/A-Series Missing Resizable BAR support or corrupted driver registry tree from prior GPU. Enable ReBAR / Above 4G Decoding in BIOS; perform DDU purge of all prior GPU vendors.

Frequently Asked Questions

What is the difference between Event ID 4101 and a VIDEO_TDR_FAILURE BSOD?

Event ID 4101 indicates that the Windows TDR subsystem successfully reset the graphics adapter without crashing the entire operating system, allowing your desktop session to continue after a momentary black screen. A VIDEO_TDR_FAILURE (0x116) Blue Screen occurs when the driver fails to recover or when worker threads cannot exit the driver interface within the secondary TdrDdiDelay time limit, forcing the kernel to execute a protective system halt.

Why does downclocking my GPU reduce TDR crashes?

Downclocking the core clock frequency (by 20 MHz to 100 MHz) lowers the voltage demand required by the GPU core silicon to maintain calculation stability. If a factory-overclocked card has suffered slight silicon degradation or has a VRM that cannot sustain transient voltage spikes, downclocking prevents the calculation drops that trigger Windows TDR timeouts.

Why does DDU work better than the standard “Clean Install” option in driver installers?

Standard installer “Clean Install” routines replace active program files but frequently retain registry configurations, cached shader files, device class associations, and driver store repository backups. Display Driver Uninstaller executes in Safe Mode to forcefully purge all registry keys, driver store staging caches, and auxiliary software hooks across all GPU vendors, ensuring no corrupted driver remnants remain to conflict with new binaries.

Will increasing TdrDelay damage my graphics card?

No. Adjusting TdrDelay and TdrDdiDelay in the Windows Registry only instructs the operating system scheduler to wait longer before assuming the GPU is dead and initiating a reset. It does not alter operating voltages, thermal limits, or clock speeds, making it completely safe for physical hardware.

Leave a Comment