nvlddmkm.sys and a clean driver reinstall
doesn't help, failing VRAM looks certain and an RMA feels like the
only option. It's usually the wrong move. The common real cause is a
timing race that fires when the GPU wakes from a low-power idle state
while DaVinci Resolve is holding cached CUDA memory on the card. Three
settings in Resolve fix it — no new hardware, no RMA, no Windows
reinstall. Here's how to tell whether that's your situation or whether
the card really is dying.
Search "nvlddmkm crash" and you'll find a decade of forum threads that
all end the same three ways: reinstall your driver, reinstall Windows,
or RMA the card. Sometimes that's right. But nvlddmkm.sys
is NVIDIA's kernel driver — it's the messenger for every GPU
problem, hardware or software — so a crash there tells you almost
nothing on its own. Below is the pattern that fools people into RMAing
a perfectly healthy card, and the free, five-second observation that
gives the real cause away.
The symptom pattern
This is the fingerprint to look for:
-
Repeated BSODs over days or weeks:
WIN32K_CRITICAL_FAILURE(0x164),SYSTEM_SERVICE_EXCEPTION(0x3B), sometimes a 0x50 -
Every dump faults in
nvlddmkm.sys, often in theNVDisplay.Containerprocess - The crashes share the same driver offset and the same Microsoft failure hash — meaning it's the exact same bug firing again and again, not random corruption
- The crashes happen at idle or on wake — never under load. The machine sits there doing nothing and dies.
That last point is the whole case. Hold onto it.
The trap: when "RMA it" is the wrong answer
Here's how a healthy card ends up in a return box.
Round 1 — the by-the-book driver wipe. The correct first move is a clean driver reinstall: not the "update driver" button, but a full DDU (Display Driver Uninstaller) wipe in Safe Mode, then a known-stable driver installed fresh, with Windows Update blocked from silently "upgrading" it back.
Risk callout (this step changes your system): DDU is
safe but disruptive. Do it from Safe Mode, have the replacement driver
downloaded first, and check whether BitLocker is on
(manage-bde -status) before booting to Safe Mode so a
recovery-key prompt doesn't ambush you.
When the crashes continue at the same code offset on a different driver version, that's not wasted effort — it's an isolation step. It rules out "bad driver release" as the cause. A fix that fails still narrows the field; that's how real diagnosis works.
Round 2 — the hardware scare. With the driver ruled out, the evidence starts pointing somewhere scarier: same fault, multiple driver versions, garbage pointer values in the dumps. That pattern usually means hardware feeding the driver corrupted data — failing VRAM. (If a CPU or board swap happened around the same time and the crashes didn't care, that conveniently rules those out too.) This is the moment the RMA paperwork comes out.
The detail that should stop you: the crashes only happen at idle. Dying VRAM fails under load — gaming, rendering, stress tests — when the chips are hot and busy. A card that passes every stress test and then dies while the screen saver is on is not behaving like broken hardware. It's behaving like a software timing bug.
What's actually happening
Modern GPUs aggressively power-manage themselves through P-states — performance levels from P0 (full throttle) down to P8 (near-asleep). Sitting idle at the desktop, the card drops to P8: clocks way down, parts of it effectively napping. When something needs it again, it has to wake up — and that idle/wake transition is a timing-sensitive handoff between the driver, the OS, and any application still holding memory on the card.
Check Event Viewer (Windows Logs → System, filtered to Source =
Kernel-Power) and you'll typically find a cluster of
wake/power-transition events in the minutes before
each BSOD. The card isn't failing. It's being woken up wrong.
So what's waking it wrong? Two usual suspects, found by lining up crash times against what's installed and running:
- DaVinci Resolve — uses NVIDIA's CUDA path and keeps long-lived allocations parked in VRAM even while it sits idle in the background. It never lets go of the card, so every idle/wake cycle happens with Resolve's memory still pinned.
- A remote-access tool that installs a virtual display adapter (RustDesk and similar) — the system thinks there's a second "GPU" attached, which muddies how the driver enumerates and powers devices.
The decisive, free test: go a week without opening the suspect app. If Resolve running-and-idle = crashes, and Resolve closed = stable, you've found the trigger. The underlying bug is a driver-level race — the card changing power states while an app holds cached allocations — but Resolve's grip on VRAM is the finger pulling the trigger.
The fix: three settings, zero dollars
In Resolve, under Preferences → Memory and GPU:
- GPU processing mode: CUDA → OpenCL. The crash lives in the CUDA path's cached allocations. OpenCL manages memory differently and sidesteps the race.
- GPU selection: Auto → Manual, real GPU only. "Auto" lets Resolve see the virtual display adapter from any remote-access tool. Tick only the physical card and a whole category of confusion disappears.
- Fully quit Resolve when stepping away. The bug fires at idle/wake while Resolve holds VRAM. No Resolve running, no pinned memory, no crash.
One gotcha: Resolve sometimes leaves background processes alive after the window closes. Confirm it's actually gone:
Get-Process | Where-Object { $_.Name -match 'resolve|fusion|fuscript|davinci|blackmagic' }(Worth knowing: Resolve Free doesn't expose the GPU memory-limit setting — that's Studio-only — so these three controls are the whole toolkit on the free version.)
After the change: crash-free. If a VRAM underclock was applied as a stopgap, it can come back off as a final stability test — staying stable with the underclock removed is the last confirmation the hardware was never the problem.
How to tell a software trigger from a dying card
Don't sell yourself the happy answer — sometimes it really is the card. The honest checklist:
Points to software/driver (fixable):
- Crashes at idle or wake, never under load
- Same failure hash / same driver offset every time — a repeatable bug, not decay
- Passes stress tests (FurMark, OCCT) clean
- Crashes track a specific app being open, even idle in the background
- A week without that app = no crashes
Points to real hardware failure (RMA it):
- Visible artifacts — flickering textures, colored sparkles, checkerboards
- Crashes under load that get more frequent over weeks
- Fails stress tests or VRAM test patterns
- Different fault addresses every time — randomness is the signature of physical decay
- The problem follows the card into a different machine
If the symptoms read like the second list, stop tweaking settings and start the RMA while the card's still in warranty. An honest "this one isn't fixable in software" is part of the job too.
The takeaway
The internet's reflex for nvlddmkm crashes — reinstall,
then RMA — costs people weeks without their card and often fixes
nothing, because the same bug greets the replacement on arrival. The
detail that cracks these cases is free and sitting in plain sight:
when the crashes happen. Idle-only crashes are a timing
problem, and timing problems live in software, not silicon.
- Repeated
nvlddmkm.sysblue screens look like failing VRAM, but usually aren't. - The real cause is an idle-wake timing race that fires while DaVinci Resolve holds cached CUDA memory on the card.
- Three Resolve settings fix it — no RMA, no new card, no Windows reinstall.