[BUG] RTX 5090 Hibernate Resume causes nvlddmkm.sys 0x133 DPC_WATCHDOG

[BUG REPORT] nvlddmkm.sys DPC_WATCHDOG_VIOLATION (0x133) on Hibernate
Resume with RTX 5090 — Reproducible on Multiple Systems, Persists Across
Driver 591.74 and 595.97

Environment

GPU: NVIDIA RTX 5090Dv2 (GB202, Blackwell)
CPU: AMD Ryzen 9 9950X3D
Motherboard: MSI PRO X870E-P WIFI (BIOS version A40)
RAM: 96GB DDR5 6000MHz
Storage: 4TB NVMe SSD (system drive)
PSU: 1300W Platinum ATX 3.0
OS: Windows 11 (Kernel Version 26100, Build 26100)
Drivers Tested: 591.74 (original), 595.97 (DDU clean reinstall)

Summary

After resuming from Hibernate (S4 sleep state), the system consistently
crashes with a 0x133 DPC_WATCHDOG_VIOLATION bluescreen approximately
145–148 seconds after the resume completes. The crash is caused by
nvlddmkm.sys running an ISR at IRQL DISPATCH_LEVEL beyond the watchdog
timeout threshold.

This issue:

  • Reproduces consistently on EVERY hibernate resume attempt
  • Has been confirmed on TWO separate machines with identical hardware
  • Persists across driver versions 591.74 and 595.97
  • Was verified after DDU clean uninstall + fresh install of 595.97
  • Does NOT occur during normal usage (gaming, rendering, desktop work)
  • Does NOT occur with S3 sleep (only S4 Hibernate triggers the crash)

Reproduction Steps

  1. Boot the system normally and allow it to stabilize
  2. Initiate Hibernate via Start Menu → Hibernate, OR allow system to
    auto-hibernate after idle timeout
  3. Wait for system to fully power off (Hibernate file written to disk)
  4. Press power button to resume
  5. Wait approximately 145–148 seconds after the resume animation appears
  6. System crashes with 0x133 DPC_WATCHDOG_VIOLATION

Expected Result: System resumes from Hibernate and restores all
previous application state normally.
Actual Result: System crashes ~145 seconds after resume, forcing
a full cold reboot. All session data is lost.

WinDbg Analysis (!analyze -v) — Driver 595.97

BUGCHECK_CODE: 0x133 (DPC_WATCHDOG_VIOLATION)
BUGCHECK_P1: 0x1 (cumulative timeout at DISPATCH_LEVEL)
BUGCHECK_P2: 0x1e00 (watchdog period in ticks)

FAILURE_BUCKET_ID: 0x133_ISR_nvlddmkm!unknown_function
FAILURE_ID_HASH: {f97493a5-ea2b-23ca-a808-8602773c2a86}
IMAGE_NAME: nvlddmkm.sys
MODULE_NAME: nvlddmkm
SYMBOL_NAME: nvlddmkm+10b2f7
DPC_TIMEOUT_TYPE: DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED
PROCESS_NAME: System

Key Stack Frames:
nt!KeBugCheckEx
nt!KeAccumulateTicks+0x59c
nt!KiUpdateRunTime+0x9b
nt!KeClockInterruptNotify+0x3ee
nt!KiCallInterruptServiceRoutine+0x32c
nt!KiInterruptSubDispatchNoLockNoEtw+0x4e
nt!KiInterruptDispatchNoLockNoEtw+0x3c
[interrupted context: nvlddmkm+0x10b2f7]

Cross-Version Comparison

The FAILURE_ID_HASH is identical across both driver versions, confirming
this is the same underlying bug:

Driver 591.74: SYMBOL_NAME = nvlddmkm+107467
FAILURE_ID_HASH = {f97493a5-ea2b-23ca-a808-8602773c2a86}

Driver 595.97: SYMBOL_NAME = nvlddmkm+10b2f7
FAILURE_ID_HASH = {f97493a5-ea2b-23ca-a808-8602773c2a86}

The offset differs between versions (due to recompilation), but the
crash fingerprint is identical, indicating the same code path is
responsible in both driver releases.

Secondary Effects

After each crash-induced cold reboot, the DeepCool AIO liquid cooler
(connected via USB) fails to reinitialize correctly. The pump and fans
display 0 RPM in the DeepCool control software, and CPU temperatures
rise abnormally. This is a secondary consequence of the abrupt USB
controller reset caused by the crash, not an independent hardware fault.

Confirmed Workaround

Disabling Hibernate entirely via:
powercfg /h off
and using S3 sleep instead completely avoids the crash. This confirms
the bug is specific to the S4 Hibernate resume power state transition
(D3cold → D0) in nvlddmkm.sys.

What Has Been Ruled Out

  • Hardware defect: Issue reproduces on two independent machines
  • Driver installation corruption: DDU clean install confirmed
  • Specific driver version: Both 591.74 and 595.97 affected
  • Third-party software conflict: Secondary machine has minimal software
  • AMD chipset driver issue: Updated to latest version 7.12.04.858
  • Memory issue: System is fully stable during all non-hibernate usage

Attachments

  • Minidumps_RTX5090Dv2_HibernateBluescreen.zip (multiple .dmp files
    from both driver versions)
  • WinDbg_Analysis_RTX5090Dv2.txt (full !analyze -v output
    from driver 595.97)
  • SystemInfo_RTX5090Dv2_BugReport.txt (msinfo32 full system info)
  • DxDiag_RTX5090Dv2_BugReport.txt (DirectX diagnostic report)
  • GPUZ_RTX5090Dv2.png (GPU-Z screenshot showing
    GPU and VBIOS details)
  • EventLog_KernelPower41_6008.evtx (Windows Event Log showing
    Kernel-Power Event ID 41
    and 6008 crash records)

Request

We are requesting that NVIDIA engineering investigate the nvlddmkm.sys
ISR timeout occurring during S4 Hibernate resume on RTX 5090 (GB202 /
Blackwell architecture). Specifically, we believe the D3cold-to-D0
power state transition sequence during Hibernate resume contains a code
path where an interrupt service routine does not complete within the
Windows DPC watchdog timeout window (~7680ms at DISPATCH_LEVEL).

Given that this issue:

  1. Affects multiple independent systems with identical hardware
  2. Persists across multiple driver versions
  3. Is fully reproducible on demand
  4. Renders the Hibernate feature completely non-functional on
    RTX 5090 systems

We believe this warrants a high-priority fix in an upcoming driver
release.

Thank you for your attention to this report.

Reporter Information

Hardware confirmed affected:
Machine 1: Reporter_A
Machine 2:Reporter_B

NVIDIA_BugReport_RTX5090Dv2_Hibernate_BSOD.zip (3.6 MB)

Additional Testing - Hyper-V Isolation Test (2026-03-29)

To determine whether Hyper-V interaction was a contributing factor,
we disabled Hyper-V completely (HypervisorPresent confirmed False via
Get-CimInstance Win32_ComputerSystem) and repeated the sleep/wake test.

Result: BSOD persists with identical FAILURE_ID_HASH
{f97493a5-ea2b-23ca-a808-8602773c2a86}

New minidump: 032926-10406-01.dmp
New nvlddmkm offset: +0xe77a3 (differs from previous due to KASLR,
same root cause confirmed by identical FAILURE_ID_HASH)

Conclusion: The bug in nvlddmkm.sys ISR code path is fully independent
of Hyper-V. It reproduces in clean environment with no external
contributing factors.

Hi there @769722477, welcome to the NVIDIA Developer forums.

This community serves the developer ecosystem.

For consumer issues, we usually point visitors to the GeForce forums.

Also, the NVIDIA app has a built-in feedback option where you can file bug reports like these.

Still, I will pass on your information.

Thanks.

Thanks!!!

Hey Gang - will cross post this in the GeForce forums as you mentioned @MarkusHoHo - just adding the breadcrumbs here if it helps others. Seems a long-lasting driver issue on Blackwell spanning a number of drivers

Confirming the same ISR failure on RTX 5070 Ti Laptop (Blackwell GB205, 12GB GDDR7) on a Lenovo Legion Pro 7i Gen 9 - 12 crashes and one hard hang since May 2026, all drivers from 595.97 through 610.74.

Your finding that the ISR bug is independent of Hyper-V lines up with my situation. On this Lenovo model the bare Hyper-V hypervisor is firmware-enforced - every BIOS option, BCD setting, and policy key exhausted, WMI still returns VirtualizationBasedSecurityStatus: 2 and RootFlags.Value: 1015 is identical across all 12 of my dumps. I can’t test without it. But the 0x133 crashes reproduced regardless, which matches your conclusion.

My dump stack for the 0x133 events looks the same: NVIDIA ISR at high IRQL exceeding the DPC watchdog. Same failure, different card.

Worth noting: I also get 0x9F (DRIVER_POWER_STATE_FAILURE, nvlddmkm failing IRP_MN_SET_POWER) and 0x116 (VIDEO_TDR_FAILURE, Arg3 0xC000009A STATUS_INSUFFICIENT_RESOURCES). Three different codes, same driver. The multi-code
pattern on the laptop may be related to the hypervisor adding a virtualized interrupt layer on top of the same core ISR bug you’ve documented - but the ISR failure is clearly there on both platforms regardless.

Happy to share minidumps. Related thread with 215 dumps on RTX 5090 confirming same D3cold transition bug:

Thanks @crypalfnz for the additional information.

I don’t have news to share, but we have an internal bug tracking this.