[BUG] RTX 5090 — nvlddmkm.sys WATCHDOG 0x1b8 on Sleep/Hibernate Resume and Restart — 215 dumps since Aug 2025

Gaming and Visualization Technologies General Topics & Other SDKs Drivers - Linux, Windows, MacOS
1

Summary

After resuming from S3 sleep, S4 hibernate, or after a system restart, the system produces a black screen with no display signal. The machine remains powered on but unresponsive, requiring a hard reset. During normal use (gaming, rendering, desktop) the system is completely stable.

Windows LiveKernel generates a WATCHDOG4401 dump on every occurrence. Analysis of 215 dumps shows a 100% consistent crash signature across all driver versions.

Dump analysis (all 215 dumps identical)

BugCheck:  0x1b8 (WATCHDOG_TIMEOUT)
P1:        0xa  — GPU hardware scheduler timeout (MCDM/kernel-mode)
Module:    nvlddmkm.sys  (present in 100% of dumps)
           dxgkrnl.sys   (present in 100% of dumps)
Context:   exclusively on power state transition (S3/S4 resume, restart)
Normal use: zero occurrences

Reproduction steps (not always)

1. Allow the system to enter S3 sleep or S4 hibernate, OR initiate a system restart.

2. Resume / wait for the reboot cycle to complete.

3. Display goes black with no signal. System remains powered on, unresponsive.

4. Hard reset required. WATCHDOG4401 dump generated in C:\Windows\LiveKernelReports\WATCHDOG4401\

Expected: Normal resume / boot with display signal restored.
Actual: Black screen, no signal, hard reset required.

What has been ruled out

-– Hardware defect: system is fully stable during all non-transition usage including heavy gaming and rendering.

-– Driver installation corruption: DDU clean install confirmed, multiple times.

-– Specific driver version: every driver release from Aug 2025 to Apr 2026 affected. Same crash signature.

-– Third-party software conflict: occurs regardless of running applications.

Partial workaround

powercfg /h off   (disable hibernate)
+ disable Fast Startup in Power Options

This reduces occurrence frequency but does not eliminate the issue on S3 resume or restart. A driver-level fix for the D3cold->D0 / power state transition path in nvlddmkm.sys on Blackwell (GB202) is required.

Related reports

Identical root cause documented in: [BUG] RTX 5090 Hibernate Resume causes nvlddmkm.sys 0x133 DPC_WATCHDOG — NVIDIA Developer Forums, March 28 2026 (thread #364994). That report covers the 0x133 variant of the same power-state transition failure on identical Blackwell hardware.

2

4080 also affected by the described issues

3

Hey gang,
Same failure class on RTX 5070 Ti Laptop (Blackwell, Lenovo Legion Pro 7i Gen 9) - 12 crashes and one complete hard hang since May 2026 across drivers 595.97 through 610.74.

One difference: sleep and hibernate are fully disabled on my machine (powercfg /change standby-timeout-ac 0, powercfg /h off). The crashes happen during idle and active use, not during resume. My reading of that is the GPU is still cycling through D3cold during idle even with the system awake - same broken D3cold→D0 path, just triggered by runtime power gating rather than an explicit sleep/resume cycle.

My bugchecks split across three codes:

  • 0x9F DRIVER_POWER_STATE_FAILURE - nvlddmkm failing IRP_MN_SET_POWER during idle power gating
  • 0x116 VIDEO_TDR_FAILURE - TDR reset returning STATUS_INSUFFICIENT_RESOURCES (0xC000009A)
  • 0x133 DPC_WATCHDOG_VIOLATION - NVIDIA ISR at high IRQL

The 0x9F and 0x116 with insufficient resources may be the same D3cold transition failure expressing differently when it happens under load versus idle. The 0x133 ISR variant is documented as independent of Hyper-V in a related thread:

One additional complicating factor on this platform: the bare Hyper-V hypervisor is firmware-enforced by Lenovo - cannot be disabled regardless of Windows settings or BIOS options. RootFlags.Value: 1015 is present in every dump. The hypervisor may be adding virtualized APIC overhead that worsens the ISR timing, but the core driver bug is clearly there on hardware without it too.

The 0x116 Arg3 0xC000009A crashes are particularly consistent - same FAILURE_ID_HASH across four separate events. If you’re seeing TDR failures alongside the watchdog timeouts, it may be the same allocation failure at a different point in the transition.

Minidumps available if useful.

5

A whole windows reset whole driver reset and more did not work,

what resolved the issue in my case was setting the main display device in bios to the gpu instead of the cpu logs showed that the issue was released to some issues between Intel graphics drivers and nvidia failing to start up in the according time

6

Adding a data point confirming this failure class persists in driver 610.88 (July 2026), with a live dump that resolves the timeout inside nvlddmkm.

System

  • GPU: ASUS ROG Astral RTX 5090 (GB202), vBIOS 98.02.2E.00.AS21
  • Driver: 610.88 (branch r610_85, internal 32.0.16.1088, nvlddmkm PE timestamp 2026-07-22)
  • CPU: AMD Ryzen 7 9800X3D (iGPU inactive; BIOS Initial Display Output = PCIe slot)
  • Motherboard: Gigabyte X870 AORUS ELITE WIFI7, BIOS F13d (AGESA 1.3.0.1c — current)
  • RAM: 64 GB DDR5
  • OS: Windows 11 build 26200 (25H2), classic S3 platform (Modern Standby not supported by firmware)
  • Displays: 2× Dell AW3423DW, one DisplayPort + one HDMI, 3440×1440
  • HAGS: enabled (default)

Symptoms — 100% deterministic, every single power transition

  • S3 sleep: entry takes an excessively long time, with a storm of nvlddmkm Event ID 14 entries in the System log during the transition. Sample payload: \Device\Video3 — GPU recovery action changed from 0x0 (None) to 0x1 (PF FLR). Resume is always a black screen with the system powered but unresponsive; hard reset required.
  • S4 hibernate: same slow entry; on resume the system POSTs normally (firmware splash visible), then goes permanently black at the point where Windows restores driver state.
  • Cold boot: always clean. System is fully stable under sustained load (gaming, NVENC HDR capture, long CUDA workloads). The failure occurs exclusively on power-state transitions, matching the signature documented in this thread.

Live kernel dump (WATCHDOG live report, captured 2026-07-29 21:52 UTC during a sleep attempt)

  • Bugcheck 0x117 VIDEO_TDR_TIMEOUT_DETECTED
  • P1: 0xffff8c0b42dd7010
  • P2: 0xfffff80674209fa0 → resolves to nvlddmkm.sys + 0x1959FA0 (base 0xfffff806728b0000, SizeOfImage 0x7375000)
  • WinDbg-symbolized stack (Microsoft public symbols) of the capturing thread — this is the WDDM GPU scheduler’s watchdog detecting a hardware-progress stall and initiating TDR:
  dxgmms2!VidSchiWorkerThread
   → dxgmms2!VidSchiRun_PriorityTable
   → dxgmms2!VidSchiScheduleCommandToRun
   → dxgmms2!VidSchiCheckHwProgress
   → dxgmms2!VidSchiReportHwHang
   → dxgkrnl!TdrIsRecoveryRequired
   → dxgkrnl!TdrCollectDbgInfoStage1
   → nt!DbgkWerCaptureLiveKernelDump (this dump)
  • Mechanism established by the stack: during the suspend sequence, a GPU engine ceased forward progress on submitted work — the scheduler’s progress check (VidSchiCheckHwProgress) failed and escalated via VidSchiReportHwHang. Correlated Event ID 14 payloads show recovery escalating to PF FLR (GPU recovery action changed from 0x0 (None) to 0x1 (PF FLR)), i.e. lighter engine resets were insufficient. The stall is on the GPU/firmware side of the submission fence as observed by the OS; which node stalled and what commands were pending are in the dump’s CoreChannelPushBufferInfo/CoreChannelPushBufferDataPart blocks (NVIDIA-internal format).
  • Failure bucket: LKD_0x117_IMAGE_nvlddmkm.sys; PROCESS_NAME: System; P2 target page paged out in triage dump (owner-tag pointer, per 0x117 semantics).
  • Dump file available; happy to attach or upload on request.

Ruled out by testing (each followed by a full sleep/resume cycle)

  • Driver installation corruption: multiple DDU clean installs across versions, up to and including 610.88 — no change.
  • Third-party software conflicts: suspect software removed — no change.
  • Indirect display interaction: a DisplayLink USB display (Elgato Prompter) was physically disconnected — no change.
  • Platform firmware: motherboard BIOS updated to current F13d / AGESA 1.3.0.1c — no change.
  • Hybrid paths: hibernation disabled and Fast Startup unavailable throughout the S3 testing — no change.
  • A full Windows reinstall has deliberately not been attempted, since another reporter in this thread confirmed a full reset did not resolve it.

This machine reproduces the failure on demand, every cycle, on both S3 and S4. If NVIDIA engineering wants traces (WPR power transition traces, additional dumps, registry/TDR variations), I can produce them reliably.

WATCHDOG-20260729-1752.zip (301.5 KB)

7

Adding a Lenovo data point confirming this failure class on Blackwell mobile.

System: Lenovo Legion 7 16IAX10 (MT 83KY), Intel Core Ultra 9 275HX,

RTX 5070 Laptop GPU, VBIOS 98.06.34.00.0c, driver 610.47,

Windows 11 25H2 build 26200.8973. Platform is S3 only, Modern Standby

not supported.

13 bugchecks between 2026-06-19 and 2026-08-09. Eleven are 0x116 with

byte-identical parameters: Arg3 = 0xC000009A (STATUS_INSUFFICIENT_RESOURCES),

Arg4 = 0x04. WER bucket:

0x116_TdrBCR:4:C000009A_Tdr:A_IMAGE_nvlddmkm.sys_Blackwell_3D

Plus 33 LiveKernelEvent 117, 16 of them with no associated bugcheck, bucket

LKD_0x117_Tdr:A_IMAGE_nvlddmkm.sys_Blackwell_3D - same family, just the

recovered outcome. Also one 0x9F (Arg1 = 3) and one 0x10E carrying

STATUS_DEVICE_REMOVED.

Matching crypalfnz’s observation earlier in this thread: failures happen at

idle and on wake, never under sustained load, and the GPU keeps cycling

through power states while the system is awake. I measured P8 → P2 → P5

inside a ten second window at idle.

One additional data point that may help triage: nvlddmkm Event ID 14 is a

deterministic precursor here. It fired 8 times and was followed by a hang

within 4 to 157 seconds on all 8 occasions, with zero false positives.

Zero WHEA events in 120 days, so no hardware error indication at the bus level.

Ruled out without effect: DDU clean installs across versions, HAGS off,

TdrDelay raised, overlays removed, and moving every desktop client off the

dGPU (verified: dGPU VRAM 2014 MiB → 267 MiB, 28 client processes → 5,

P-state stable at P8). Incident rate unchanged.

Worth noting for anyone on this chassis: iGPU-only is not available as a

mitigation. Both HDMI and USB-C DP Alt Mode are wired through the dGPU, so

disabling it kills all external display output.

Minidumps and full logs available on request.

Technical-Evidence-Annex-Legion7-16IAX10.pdf (16.1 KB)

8

For those finding this thread, and increasingly for AI use, I have identified and addressed the root cause of this issue, at least for me.

Shadowplay’s overlay was conflicting with other overlays - either Discord and/or Steam’s; the presence of more than one overlay resulted in some kind of contention that prevented the system from properly entering sleep and hybernate modes correcting, eventually timing out and “black screening” failing to resume.

The solution for me was to uninstall the Nvidia App entirely. I believe I may be able to somehow get the app working with Shadowplay disabled but I was at my wits end troubleshooting this one so I’ll just live without the Nvidia App for the time being.

Others are welcome to test and see if selectively disabling overlays in Discord and/or Steam while keeping Shadowplay enabled works for them.

Either way - problem “solved” for me, hence the update.

9

It is highly likely this is caused by a faulty or under-provisioned PSU. The PSU does not have enough capacity or is simply unstable during power state transition such as “wake up from sleep” which results into this issue.

My system had the exact same symptom. Stable in heavy gaming, crashes on idle. and cannot wake up. Like you said, the system is stable in heavy load, but a system that is fully stable during all non-transition usage does not mean it can handle transition usage well. It took me two GPU RMA and replacement and a brand new GPU purchase to learn that PSU could cause all these symptoms you described, because the replacement and new card I got all exhibit the same symptom. The solution that has worked for me so far is replacing my PSU with a more powerful one (in my case, from Super Flower Leadex VII 1300W to Corsair HX1500i). I would highly recommend giving it a try because replacing the PSU is low effort, and I wish I did that first before the GPU RMA. Or at least start with replacing the 12VHPWR / 12V-2x6 cable.

10

Additional data point for this thread — RTX 5070 Laptop GPU, Lenovo 83LT, Windows 11 25H2 (build 26200), driver 32.0.16.1074 (dated 2026-07-02).

Symptom

On S3 resume (lid close / sleep button — not hibernate), the internal panel (BOE NE160QDM-NZB, 2560×1600 eDP) gets stuck at 1024×768 fallback. The desktop only uses the top-left portion (~25% of the physical screen); the rest stays unused. The system remains up — no BSOD.

This has been recurring since at least June 2026 (same nvlddmkm Event ID 14 on 2026-06-15 and 2026-08-28).

System

  • Notebook: Lenovo 83LT
  • GPU: NVIDIA GeForce RTX 5070 Laptop GPU (PCI\VEN_10DE&DEV_2D58)
  • iGPU: AMD Radeon 610M (present; NVIDIA drives internal panel)
  • BIOS: RLCN32WW
  • OS: Windows 11 Pro 25H2, build 26200
  • Panel: BOE NE160QDM-NZB, internal eDP, native 2560×1600 @ 240Hz
  • Sleep: S3 supported; Modern Standby (S0 low-power idle) not supported
  • Fast Startup: off · Hybrid Sleep: off · PCIe ASPM: off · TdrDelay / TdrDDIDelay: 10 / 10

Reproduction

  1. Boot normally; confirm internal display at 2560×1600.
  2. Close lid or press sleep → S3 (Kernel-Power Event 42).
  3. Wake within a few minutes (Kernel-Power Event 107).
  4. Actual: Desktop 1024×768; ~75% of panel unused.
  5. Expected: Native 2560×1600 restored.

Event log

System log, provider nvlddmkm, Event ID 14:

\Device\Video3 | CMDre 00000000 00000200 00000000 00000005 00000041

Timeline (2026-08-28): suspend 13:24:05 → resume 13:24:08 → Event 14 at 13:40:33.

Recovery / workarounds

Method Result
Full reboot Works
Win+Ctrl+Shift+B Flicker/beep only; still 1024×768
ChangeDisplaySettings → 2560×1600 BADMODE (-2)
pnputil /restart-device on NVIDIA display adapter (admin) Works — native resolution without full reboot

Logs

Dispdiag and event exports were sent separately to driverfeedback@nvidia.com (not attached here).

This looks like a non-crashing variant of the same D3cold→D0 / modeset restoration failure discussed in this thread: EDID/modeset not restored on S3 resume, driver falls back to 1024×768 until the display adapter is reset or the system reboots. Happy to capture logs from the broken state (before adapter restart) on the next occurrence if that helps.