GPU Crashes at Idle or Low Load? P-States, Clock/Voltage Transitions & Driver Power Management Explained

2026-10-21 ｜ GPU Repair ｜ 12 ｜ HK GPU Fix Editorial

Key Takeaways

A GPU that crashes only at idle or light load is usually a power-state problem, not a dying card. Clock and voltage transitions between P-States, PCIe link power saving, AMD ULPS, and Windows TDR timeouts interact at low load. Structured A/B tests — power management modes, PCIe Link State, driver versions — isolate the cause without replacing hardware blindly.

It feels backwards. You buy a powerful graphics card, it survives hours of the heaviest gaming or rendering workloads without a hiccup, and then the screen goes black while you are reading a web page or watching a video. Many owners conclude the card must be broken — because surely a fault that survives stress testing must be serious. In practice, the exact opposite is often true: a card that is stable under full load but crashes at idle is exhibiting one of the most well-documented patterns in GPU diagnostics, and it points at the power-management layer — the driver's P-State transitions, PCIe link power states, or Windows' own timeout recovery — rather than at a dead GPU core.

What P-States Are

Modern GPUs do not run at one fixed clock speed. NVIDIA's driver manages a ladder of performance states, or P-States, defined in its NVML API: P0 is maximum performance, descending down through P12 (with P13–P15 reserved on some parts) as minimum performance. Each state corresponds to a specific combination of clock speed and voltage, and the driver continuously promotes and demotes the GPU between them according to instantaneous load.

AMD graphics have an equivalent concept under different names — older PowerMizer profiles, modern Adrenalin power profiles — and the CrossFire era added ULPS (Ultra Low Power State), which we will cover separately below.

The critical mechanical point: every P-State transition is a voltage transient. The card's VRM (voltage regulator module) must change its output voltage along a ramp, and the GPU's output capacitors filter the transition. Under full load, the GPU simply sits at P0 in a steady high-voltage state and hardly transitions at all. At light load — desktop work, browsing, hardware-accelerated video playback — the GPU bounces up and down between high and low states constantly. Paradoxically, the idle system performs far more clock/voltage transitions than the fully loaded one, and each transition is an opportunity for the driver to desynchronise clock and voltage pairing. If one transition misses, Windows' TDR mechanism may reset the display driver — the classic one-second black screen.

Why Low-Load Switching Crashes More Than Full Load

Three overlapping mechanisms make light-load transitions the danger zone:

Transition frequency asymmetry. Full load is a steady state; idle is a rapid-fire sequence of ramps. The failure mode lives in the transition itself, not in the sustained state.

Aging power delivery. As output capacitors age, their ESR (equivalent series resistance) rises and filtering degrades. At light load, VRM controllers often enter discontinuous-conduction or pulse-frequency-modulation modes to save power, whose output ripple characteristics differ from heavy-load operation. Meanwhile, the GPU core's noise margin at low-voltage P-States is already narrower. These three factors stack — which is why the familiar pattern of an older card that "only started black-screening at idle after a few years" is so common in repair practice, even though it passes a full-load stress test.

The low-load PSU blind spot. A technician in a Tom's Hardware discussion noted that while power supplies usually fail under heavy load, they can also misbehave at low voltage levels — so an idle crash cannot automatically rule out the PSU either.

A documented real-world case illustrates the pattern precisely: an RTX 5060 system on Microsoft Q&A suffered intermittent black screens with `nvlddmkm` Event ID 153 (a TDR reset) that occurred only at low load, at idle, or while browsing — while the Unigine Heaven stress test ran for hours without a fault. Safe Mode was completely stable, and swapping cables, ports and refresh rates changed nothing. The reporter's three suspected directions — a WDDM power-state problem, an NVIDIA driver low-power-state bug, or a failing card — are exactly the three branches this article's diagnostic section separates.

NVIDIA Power Management Mode: Three Options, No Silver Bullet

In NVIDIA Control Panel under "Manage 3D Settings", the Power Management Mode setting offers three choices: Optimal Power (the default), Adaptive, and Prefer Maximum Performance. This is one of the highest-leverage A/B tests available.

How it fails: under Optimal Power, the driver aggressively drops to low P-States, and when load spikes suddenly, the GPU must ramp from a low state back up — during which the display signal may renegotiate and the screen goes black for a second or two. ASUS lists switching to Prefer Maximum Performance among its official fixes for in-game black screens, and a widely used troubleshooting guide pairs this with the PCIe Link State change as a single "Fix 4".

But the reverse also holds, and honest coverage must say so: other guides warn that Prefer Maximum Performance keeps clocks and voltages high even on loading screens, which can create transient power spikes that trip PSU protection or cause DXGI timeouts — and recommend going back to Normal or Optimal Power. Both directions have genuine user reports behind them, so the correct procedure is a controlled comparison, not a blanket recommendation. Set it, test for a few days of normal idle use, and record whether the crashes stop — then you have evidence rather than a superstition.

PCIe Link State Power Management and ASPM

Windows exposes a separate, independent control under Power Options → Change plan settings → Change advanced power settings → PCI Express → Link State Power Management (Off / Moderate / Maximum power savings). This governs the PCIe link between the motherboard and the GPU: the link alternates between L0 (active) and L0s/L1 (low-power) states, and waking from the low-power states requires the link to retrain. A failed retrain drops the display signal.

This single setting is one of the most effective isolation tests in existence: multiple users report that changing only this setting permanently resolved blackouts that occurred specifically at idle or low GPU load. A Tom's Hardware thread on TDR crashes lists setting PCIe link state power management to Off among its three recommended fixes.

There is also a BIOS-side trap worth knowing: there are documented cases where the BIOS shows ASPM as enabled while it is not actually active in the firmware's internal state, requiring it to be fully disabled, the system booted once, and then re-enabled before it truly takes effect. And as a datapoint on how much ASPM governs idle behaviour: a correctly configured Intel Arc A770 dropped idle power from around 40 W to 16–20 W at 1440p 120 Hz (about 15 W at 60 Hz) purely from ASPM settings — proof that PCIe power management dominates idle operation.

Diagnostic takeaway: disabling Link State Power Management is the cheapest controlled test you can run. If the crashes improve, you have pointed the finger at PCIe power-state transitions.

AMD ULPS

ULPS (Ultra Low Power State) is an AMD feature from the multi-GPU/CrossFire era: at idle it nearly powers down the secondary card to save energy. If the wake-up of the secondary card fails, the result is a black screen or crash — and Tom's Hardware users have reported that disabling ULPS resolved exactly this.

Disabling is done in the registry, under `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{GUID}\0000` (and 0001…000N, one key per card), setting the `EnableUlps` DWORD to 0 (1 is the enabled default) and rebooting. On modern single-card AMD systems CrossFire is gone, but RDNA still has deep-sleep-class mechanisms, and Adrenalin's power profiles similarly affect idle stability — an AMD TDR guide specifically notes that AMD GPUs are sensitive to aggressive power management.

Windows Power Plans and Fast Startup

Balanced or power-saver plans actively push the GPU and PCIe link toward low states, which increases the chance of a driver stall when load arrives suddenly. An AMD TDR troubleshooting guide recommends switching to High Performance (or Ultimate Performance) while diagnosing. The Ultimate Performance plan — revealed with `powercfg -duplicatescheme e9a42b02-d5df-448d-aa00-03f14749eb61` — disables Link State Power Management and USB selective suspend among other things, making it a useful one-click baseline.

Fast Startup deserves its own mention: it carries the previous session's driver state into the next boot, so a corrupted GPU driver state survives restarts. This explains the otherwise baffling phenomenon of "reboot didn't help, but a full shutdown and power-on did". A full cold boot is the clean state; treat it as part of the test protocol.

TDR: The Mechanism Behind the Black Blink

TDR (Timeout Detection and Recovery) is a Windows feature, documented on Microsoft Learn: if the GPU does not respond to the scheduler's preemption request within the time limit, the system resets the display driver to restore responsiveness. What you see — the screen going black for a moment and then recovering, not necessarily a blue screen — is the hallmark of a TDR event.

The registry keys under `HKLM\System\CurrentControlSet\Control\GraphicsDrivers` define the behaviour:

In Event Viewer, the matching signatures are `nvlddmkm` Event ID 153 (a TDR reset) and LiveKernelEvent 141, both commonly seen with this class of black screen.

One hard rule from AMD's TDR guide: do not disable TDR entirely (`TdrLevel=0`). A hung GPU that cannot be reset becomes a hard lock requiring a power cycle. Raising `TdrDelay` merely gives the GPU more time — it does not cure unstable hardware or a bad driver.

Diagnostic significance: an idle black screen plus Event 153/141 plus automatic driver recovery equals a TDR-class event. That locks the investigation to power states and drivers rather than declaring the card dead.

Display Sleep Wake-Up and the DisplayPort Link

When the monitor sleeps, the DisplayPort link must retrain on wake; if the display driver cannot complete the monitor-on request within the deadline, `pdc.sys` fires a `PDC_WATCHDOG_TIMEOUT` (parameter 0x100) bug check — which the user experiences as a black screen on wake. Wake-from-sleep black screens have their own mechanism distinct from general idle crashes.

A fast controlled test for application triggers: disable hardware acceleration in Chrome, Discord and Edge one at a time and watch whether the blackouts stop. If they do, you have found the trigger source — an application's hardware decoding is what keeps knocking the GPU between P-States.

Boundary Case: Multi-Monitor Idle Behaviour

With multiple monitors — especially at mismatched refresh rates, such as 144 Hz plus 60 Hz — the GPU's memory clock locks at maximum and refuses to downclock. The mechanism: the pixel clock demanded by several panels exceeds what the idle frequency (roughly 139–253 MHz) can provide, so the driver is forced to maintain high clocks to keep the panels synchronised. NVIDIA's own developer forum still carried such reports in 2025.

Two things to record carefully. First, this is normal designed behaviour — high power draw but stable — and must not be presented as a fault. Second, it is an important diagnostic distinction: a dual-monitor user's idle P-State behaviour is fundamentally different from a single-monitor user's, so screen configuration is one of the first things to ask about. Background programs — monitoring software, ShadowPlay, CUDA plugins from Adobe or Autodesk — can likewise pin the clock and prevent downclocking.

Diagnostic Logic: Three Root-Cause Classes

The golden rule for this whole category: stable under full load but crashing at idle points hardest at power-state transitions; crashing under full load too points hardest at hardware, cooling or the power supply.

Common Myths

• "Just replace the PSU and it will be fixed." Idle black screens are often driver P-State, PCIe ASPM or ULPS problems where a PSU swap achieves nothing. The PSU is most suspect when crashes happen under full load (with low-load regulation issues as the documented exception).
• "It must be the driver." If a DDU clean reinstall plus two or three driver versions all fail identically, shift the investigation to aging hardware, the PSU and the motherboard PCIe path — do not reinstall drivers forever.
• "Normal temperatures mean the hardware is fine." The GPU core temperature sensor does not reflect VRAM or VRM temperatures; overheating in either of those will also black-screen.
• "Prefer Maximum Performance is always more stable." Counter-cases exist (transient spike argument). Treat it as a controlled test, not a cure.

FAQ

Why does my GPU crash at idle but pass every stress test?

Because idle operation performs far more clock/voltage transitions between P-States than full load, which sits in a steady state. The failure lives in the transitions — VRM voltage ramps, PCIe link retrains, driver clock-voltage pairing — not in sustained performance. This is a recognised pattern, and the first branch of diagnosis is the power-management layer, not hardware replacement.

Is a black screen at idle the same as a TDR event?

Often, yes. Check Event Viewer for `nvlddmkm` Event ID 153 or LiveKernelEvent 141. If present alongside automatic driver recovery, you are looking at a TDR-class event, which narrows the field to power states and drivers.

Should I set Prefer Maximum Performance and leave it there?

Only as a test first. Evidence cuts both ways: it can stop ramp-up blackouts, but it can also cause transient power spikes that trip PSU protection. Run it for a few days of normal idle use and compare against the baseline before deciding it helps your specific system.

Can a power supply cause crashes only when the computer is idle?

Yes. While PSUs most commonly fail under heavy load, poor low-load regulation is a documented possibility. Inspect the cabling too: use two independent PCIe power cables rather than a daisy-chain, and make sure a 12V-2×6 connector is seated fully with no gap.

Is it safe to disable TDR to stop the black screens?

No. Disabling TDR (TdrLevel=0) removes the mechanism that recovers a hung GPU, turning recoverable black blinks into hard locks that need a power cycle. It also masks the underlying instability rather than fixing it.

When should I bring the card in for professional diagnosis?

If DDU reinstalls across two or three driver versions, the PCIe Link State test, and the power management mode comparison all fail to change the pattern — or if the crashes also happen under full load with artifacting — the suspect list shifts to aging power delivery or other hardware faults, which need bench-level inspection. HK GPU Fix (Room 1209, Dali Plaza, Shek Mun; phone 2186 8010; WhatsApp 6558 6806) diagnoses idle-crash cases on the bench with published three-tier pricing (HK$400–2,800).

Sources

• NVIDIA NVML API — P-State definitions: https://docs.nvidia.com/deploy/archive/R535/nvml-api/group__nvmlDeviceEnumvs.html
• NVIDIA nvidia-smi — performance states: https://docs.nvidia.com/deploy/nvidia-smi/index.html
• Microsoft Q&A — RTX 5060 low-load TDR case: https://learn.microsoft.com/en-us/answers/questions/5688279/nvidia-gpu-causing-nvlddmkm-tdr-resets-and-intermi
• Tom's Hardware — PSU low-load discussion: https://forums.tomshardware.com/threads/black-screen-crashes-think-its-psu.3246569/
• The Droid Guy — idle blackout fix guide (PCIe Link State, power mode, Fast Startup): https://thedroidguy.com/monitor-keeps-going-black-for-a-second-then-comes-back-the-definitive-fix-guide-2026-1272378
• Izoate — Prefer Maximum Performance counter-argument: https://www.izoate.com/blog/how-to-fix-dxgi_error_device_removed-device-hung-2026-ultimate-troubleshooting-guide/
• Tom's Hardware — AMD ULPS reports: https://forums.tomshardware.com/threads/amd-ulps-ultra-low-power-state.1958708/
• SevenForums — ULPS registry disable method: https://www.sevenforums.com/tutorials/316913-ulps-ultra-low-power-state-disable-amd-crossfirex-post2645497.html
• Position Is Everything — AMD TDR and power plans: https://www.positioniseverything.net/how-to-fix-the-amd-driver-timeout-tdr-error-on-windows/
• PC Hardware Pro — ASPM guide and idle power data: https://www.pchardwarepro.com/en/PCIe-settings-ASPM-complete-energy-saving-guide/
• Microsoft Learn — TDR registry keys: https://learn.microsoft.com/en-us/windows-hardware/drivers/display/tdr-registry-keys
• Intel — TDR adjustment guide: https://www.intel.com/content/www/us/en/docs/oneapi/installation-guide-windows/2025-1/gpu-adjust-timeout-detection-and-recovery-setting.html
• Windows Digitals — LiveKernelEvent 141 and power cabling: https://www.windowsdigitals.com/livekernelevent-141-video-tdr-failure-nvidia/
• UGetFix — PDC_WATCHDOG_TIMEOUT on wake: https://ugetfix.com/fix/how-to-fix-pdc-sys-bsod-error-in-windows/
• Tom's Hardware — multi-monitor memory clock locked high: https://forums.tomshardware.com/threads/gpu-memory-clock-stuck-at-max-while-at-idle.3791762/
• NVIDIA Developer Forums — multi-monitor P-State issue: https://forums.developer.nvidia.com/t/gpu-is-stuck-to-maximun-power-state-at-idle-when-using-multiple-monitors/310924.rss
• Tom's Hardware — TDR triple fix: https://forums.tomshardware.com/threads/black-screen-then-either-shutdown-or-nvlddmkm-stopped-responding-error.2053227/