Skip to content

Instantly share code, notes, and snippets.

@VooDisss

VooDisss/README.md

Last active March 21, 2026 20:33
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save VooDisss/216bfea61bd7d75fdae43bb1b25d3487 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save VooDisss/216bfea61bd7d75fdae43bb1b25d3487 to your computer and use it in GitHub Desktop.
Download ZIP
Fix: Windows 10/11 PC Shuts Down Instead of Sleeping with Dual NVIDIA GPUs — Event ID 41 Kernel-Power (TDR Timeout Fix)
Raw
README.md

Fix: Windows 10/11 PC Shuts Down Instead of Sleeping with Dual NVIDIA GPUs — Event ID 41 Kernel-Power (TDR Timeout Fix)

Problem

After installing a second NVIDIA GPU (dual GPU setup), the PC shuts down or crashes instead of going to sleep. The monitor goes black for about a minute during the sleep transition, then the system powers off completely. On the next boot, Event Viewer shows:

  • Event ID 41 (Kernel-Power) — Critical
    • BugcheckCode: 0
    • SleepInProgress: 4
    • PowerButtonTimestamp: 0
    • Checkpoint: 0
  • Event ID 6008 — Unexpected shutdown

Sleep worked perfectly with a single GPU and breaks only when both GPUs are installed.

Typical System Profile

  • Motherboard with PCIe lane bifurcation (e.g., x8/x8 or x8/x4 split when two GPUs are installed)
  • The second GPU runs on fewer PCIe lanes (commonly x4) due to platform limitations
  • NVIDIA RTX 30-series, 40-series, or similar
  • Windows 10 or Windows 11

Root Cause

The NVIDIA display driver (nvlddmkm.sys) fails to complete the power state transition IRP (I/O Request Packet) for the second GPU within Windows' default TDR (Timeout Detection and Recovery) timeout of 2 seconds.

When the system enters S3 sleep:

  1. Windows sends power-down IRPs to all GPU devices
  2. The primary GPU on full-width PCIe lanes completes the transition quickly
  3. The second GPU on a bandwidth-constrained PCIe link (x4 or x8) takes longer to complete the power state transition
  4. Windows' TDR mechanism detects the timeout after 2 seconds
  5. The driver fails to respond, and the system crashes with a hard power loss

This results in BugcheckCode: 0 (no BSOD — the system dies before it can write a crash dump) and SleepInProgress: 4 (crash during sleep/hibernate transition). No minidump files are generated.

Key Evidence

  • Event ID 41 with SleepInProgress=4 and BugcheckCode=0 = power loss during sleep transition
  • Event ID 109 with "Kernel API" shutdown reason = kernel initiating shutdown instead of sleep
  • Event ID 42 (system entering sleep) stops appearing after the second GPU is installed
  • Sleep works immediately when the second GPU is disabled in Device Manager

The Fix — Increase TDR Timeout

The fix is to increase the TDR delay from the default 2 seconds to 20 seconds, giving the second GPU's driver enough time to complete the power state transition on the constrained PCIe link.

Registry Changes (Run as Administrator)

# Increase TDR timeout to 20 seconds (default is 2)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" -Name "TdrDelay" -Value 20 -Type DWord

# Increase TDR DDI timeout to 20 seconds (default is 5)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" -Name "TdrDdiDelay" -Value 20 -Type DWord

Or via .reg file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers]
"TdrDelay"=dword:00000014
"TdrDdiDelay"=dword:00000014

Reboot required for changes to take effect.

Registry Reference

Key Path Default Fix Value Purpose
TdrDelay HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers 2 20 GPU preempt request timeout (seconds)
TdrDdiDelay HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers 5 20 Driver thread response timeout (seconds)

Source: Microsoft Learn — TDR Registry Keys

Supporting Configuration (Recommended)

These settings are not strictly required but provide additional stability for dual-GPU sleep:

Setting How to Set Why
PCIe ASPM = Off powercfg /setacvalueindex SCHEME_CURRENT SUB_PCIEXPRESS ASPM 0 then powercfg /setactive SCHEME_CURRENT Prevents aggressive PCIe link power gating during sleep transitions
Hybrid Sleep = Off powercfg /setacvalueindex SCHEME_CURRENT SUB_SLEEP HYBRIDSLEEP 0 then powercfg /setactive SCHEME_CURRENT Avoids confused sleep states, especially with Hyper-V active
PhysX = CPU NVIDIA Control Panel → Set PhysX Configuration → CPU Prevents second GPU from being accessed by PhysX subsystem during sleep
Power Management = Normal NVIDIA Control Panel → Manage 3D Settings → Power management mode → Normal "Prefer Maximum Performance" can actually block sleep transitions (source)
PnpPowerEnabled = 0 on GPU devices Device Manager → GPU → Power Management → Uncheck "Allow the computer to turn off this device to save power" Prevents Windows from power-gating GPU PCIe devices independently

What Did NOT Fix It (Don't Waste Time On These)

The following were tested and did not resolve the issue. They are documented here to save others from unnecessary troubleshooting:

Attempted Fix Result Notes
DDU + clean NVIDIA driver reinstall ❌ Did not fix Clean drivers still have the same TDR timeout
Disabling Hyper-V (bcdedit /set hypervisorlaunchtype off) ❌ Did not fix The vpcivsp driver (Hyper-V virtual NIC) was blocking sleep transitions in the logs, but was a symptom not the cause
Disabling HW GPU Scheduling (HwSchMode=1) ❌ Did not fix Unrelated to power state transitions
Disabling Multiplane Overlay (MPO) (OverlayTestMode=5) ❌ Did not fix Display compositor issue, not power management
BIOS update ❌ Did not fix Even with updated AGESA/BIOS, the driver timeout is the issue
Switching power plan (Power Saver → Ultimate Performance) ❌ Did not fix alone Helps when combined with ASPM=Off, but not sufficient
NVIDIA PowerMizer registry tweaks (PowerMizerEnable, PerfLevelSrc, PowerMizerLevel) ❌ Did not fix Redundant — TDR delay is the actual fix
DisableDynamicPstate=1 (forcing GPU to P0 state permanently) ⚠️ Fixed sleep BUT caused ~150-175W idle power per GPU This forces GPUs to max clocks 24/7. It works but wastes enormous power. Use TDR delay instead
FanControl / GPU monitoring software ❌ Not the cause Tested with monitoring software running — sleep still worked once TDR was fixed

Diagnostic Commands

If you're diagnosing this issue, these commands will help confirm the root cause:

Check for Event 41 with SleepInProgress

# PowerShell — get last 5 Event 41 entries with full detail
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Kernel-Power'; Id=41} -MaxEvents 5 | ForEach-Object {
    $xml = [xml]$_.ToXml()
    $data = $xml.Event.EventData.Data
    Write-Host "---"
    Write-Host "Time: $($_.TimeCreated)"
    foreach ($d in $data) {
        Write-Host "$($d.Name): $($d.'#text')"
    }
}

Key indicators:

  • BugcheckCode: 0 = power loss, not a BSOD
  • SleepInProgress: 4 = crash during sleep/hibernate transition
  • PowerButtonTimestamp: 0 = user did not press the power button
  • Checkpoint: 0 = system didn't even reach the first checkpoint of sleep

Isolation Test — Confirm Second GPU is the Cause

# Disable the second GPU
$gpu = Get-PnpDevice | Where-Object { $_.FriendlyName -like "*NVIDIA*" -and $_.Status -eq "OK" } | Select-Object -Last 1
Disable-PnpDevice -InstanceId $gpu.InstanceId -Confirm:$false

# Test sleep, then re-enable
Enable-PnpDevice -InstanceId $gpu.InstanceId -Confirm:$false

If sleep works with one GPU and fails with two, the TDR timeout fix above will resolve it.

Check Current TDR Values

$gfx = "HKLM:\SYSTEM\CurrentControlSet\Control\GraphicsDrivers"
$delay = (Get-ItemProperty -Path $gfx -Name "TdrDelay" -ErrorAction SilentlyContinue).TdrDelay
$ddi = (Get-ItemProperty -Path $gfx -Name "TdrDdiDelay" -ErrorAction SilentlyContinue).TdrDdiDelay
Write-Host "TdrDelay: $delay (default 2, recommended 20)"
Write-Host "TdrDdiDelay: $ddi (default 5, recommended 20)"

Check GPU PCIe Link Width

nvidia-smi --query-gpu=index,name,pci.bus_id,pci.link.width.current,pci.link.width.max --format=csv

If the second GPU shows a current width less than max (e.g., x4 instead of x16), it confirms the bandwidth-constrained link that causes the slow power transition.

Verification

After applying the TDR fix and rebooting:

  1. Manual sleep test — Start → Power → Sleep. PC should sleep and wake normally
  2. Auto-sleep test — Let the PC idle past the sleep timeout. Should enter and exit sleep cleanly
  3. Check Event Viewer — No new Event 41 or Event 6008 entries
  4. Check GPU idle power — Both GPUs should idle at P8 state with normal power consumption: 
    nvidia-smi --query-gpu=index,pstate,power.draw,clocks.gr,clocks.mem --format=csv

Related Links

Important Warning: Sleep Crashes May Indicate a Dying Motherboard

In the case that led to this guide being written, the TDR fix resolved the sleep issue and the system ran normally for about a day. The next day, the motherboard died completely.

In hindsight, the sleep crashes were likely an early symptom of motherboard failure, not purely a driver timeout issue. The TDR fix masked the underlying hardware degradation by working around the failing PCIe power delivery.

Why Sleep Crashes Can Signal a Dying Board

  • BugcheckCode: 0 with Checkpoint: 0 means the system lost power before any software crash handler could run — this is characteristic of hardware-level power delivery failure, not just a driver timeout
  • Repeated hard power losses during sleep crash cycles (uncontrolled power cuts) are stressful on VRM capacitors and can accelerate the death of an already-degraded board
  • The sleep transition is one of the most demanding operations for a motherboard's power delivery — it requires coordinated voltage rail transitions across all components. A weakened power delivery system will fail here first, long before it fails under normal operation

Additional Context From This Case

  • The motherboard was an ASUS ROG STRIX B350-F GAMING (~7-8 years old) running components well beyond its original design spec (a Ryzen 5000-series CPU + dual RTX 3090s on a B350 board originally designed for first-gen Ryzen and a single mid-range GPU)
  • The BIOS had been updated from version 6203 to version 6232 (the latest stable release at the time) during troubleshooting. The board booted and operated normally after the flash for a full day before dying
  • While BIOS updates are generally safe, they rewrite firmware and can change voltage tables — on an already-failing board, this is an additional risk factor
  • The board had been exhibiting a separate VIDEO_SCHEDULER_INTERNAL_ERROR (BugcheckCode 0x119) crash a few days before the sleep issues began, which may have been another early failure symptom

Takeaway

If you encounter this sleep crash pattern — especially on an older motherboard running hardware beyond its original design spec — apply the TDR fix, but also consider that the motherboard may be approaching end of life. The sleep transition is often the first operation to fail on degraded hardware. Monitor for other instability signs (USB dropouts, POST issues, random reboots under load) and have a backup plan.

Keywords

dual GPU sleep crash, PC shuts down instead of sleeping, Event 41 Kernel-Power, SleepInProgress 4, BugcheckCode 0, nvlddmkm sleep failure, TDR timeout fix, dual NVIDIA GPU sleep fix, second GPU causes shutdown, PCIe x4 sleep crash, multi-GPU workstation sleep issue, Windows 10 dual GPU sleep, Windows 11 dual GPU sleep, TdrDelay registry fix, NVIDIA power state transition failure, GPU power IRP timeout, motherboard dying sleep crash symptom, sleep crash before motherboard failure, old motherboard dual GPU failure, VRM degradation sleep crash, motherboard end of life signs, BIOS update before motherboard death, ASUS ROG STRIX B350-F GAMING sleep crash, B350-F GAMING BIOS 6203 6232, B350 dual GPU failure

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment