STATUS_GRAPHICS_NO_VIDEO_MEMORY (0xC01E0100): Real Fixes

You're gaming, or rendering, or just watching a 4K video, and the screen goes black. Event Viewer says STATUS_GRAPHICS_NO_VIDEO_MEMORY with a bugcheck code of 0xC01E0100. Nine times out of ten this isn't a dying GPU. It's your GPU telling you it ran out of video memory and something had to give. The kernel didn't like how the graphics stack handled that, so it bugchecked.

The code itself is a Windows NTSTATUS value. It means a graphics operation needed more VRAM than was available. That's it. The hard part is figuring out why your VRAM was full, because there are three common culprits and they need different fixes.

Cause 1: You actually ran out of VRAM (most common)

This is the boring answer and it's the right one far more often than people want to admit. Modern games at 1440p or 4K, with ray tracing on, with high-res texture packs, chew through 8GB like it's nothing. A 4GB card doing 1440p Ultra is going to hit the wall. The crash usually happens at the worst moment — loading a new area, tabbing out and back, or when the game streams in new assets.

Common triggers I've seen in the wild:

• Cyberpunk 2077 with RT Ultra on a 6GB RTX 2060
• Chrome with 40 tabs plus Premiere Pro open on an 8GB laptop dGPU
• OBS running NVENC while the game also wants the encoder
• Two 4K monitors plus a 1440p panel on a card with 6GB

Here's how to confirm it before you go changing anything.

1. Open Task Manager, go to the Performance tab, click your GPU.
2. Look at the "Dedicated GPU memory" graph, not "Shared GPU memory." Shared is system RAM the GPU borrows — it's slow and doesn't count for most 3D workloads.
3. Reproduce the crash. If dedicated memory pegs at 100% right before it dies, you've found your cause.

The fix is to reduce VRAM pressure. Don't bother with "VRAM cleaners" — they're snake oil and some of them cause more instability than they solve. Instead:

• Drop texture quality one notch. This is the single biggest VRAM consumer.
• Turn off ray tracing or set it to low. RT shadows are cheap; RT reflections are not.
• Set render resolution to 90% or use DLSS/FSR Quality mode.
• Close background apps that touch the GPU. Discord overlay, Wallpaper Engine, browser hardware acceleration all eat VRAM.
• If you're on a laptop with hybrid graphics, force the game to the dGPU explicitly through Windows Graphics Settings, not just the NVIDIA/AMD control panel.

If none of that gets you under the ceiling, you need a card with more VRAM. No software trick changes that.

Cause 2: A leaked or buggy GPU driver is holding onto memory

The second most common cause is a driver that thinks it still owns VRAM that it actually freed. This shows up as a slow leak — the card works fine for 20 minutes, then crashes. Or it crashes every time the app switches between exclusive fullscreen and borderless windowed mode.

Specific offenders I've run into:

• NVIDIA 5xx.xx branch drivers on RTX 30-series with the DWM compositor
• AMD Adrenalin builds before 23.9.x on RX 6000 with multi-monitor
• Intel Arc drivers under 31.0.101.4502 with certain DX11 titles

Fix path, in order:

1. Boot into Safe Mode. Run DDU (Display Driver Uninstaller) and remove the current driver completely.
2. Download the Studio driver from NVIDIA if you're on GeForce, or the WHQL Recommended from AMD. Skip the Game Ready/Adrenalin Optional branches — they ship with bugs.
3. Install clean. Reboot. Don't let Windows Update sneak a driver in behind you:

   reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v ExcludeWUDriversInQualityUpdate /t REG_DWORD /d 1 /f

If it still leaks, check with GPU-Z's Sensors tab. Watch "Memory Used" over an hour of idle desktop use. If it climbs without you doing anything, the driver is the problem and you should roll back to a version known-good for your card.

Cause 3: TDR is too aggressive, or the GPU is misreporting VRAM

Windows has a watchdog called TDR (Timeout Detection and Recovery). If a GPU operation takes longer than 2 seconds by default, Windows resets the driver. Under heavy VRAM load, an operation can stall just long enough to trip TDR, and the recovery path is where 0xC01E0100 sometimes gets thrown.

You can raise the TDR delay. This is a real fix when the underlying cause is VRAM pressure spikes, not a hardware fault. It's a band-aid if the hardware is genuinely bad, so don't skip the hardware check.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" /v TdrDelay /t REG_DWORD /d 10 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" /v TdrDdiDelay /t REG_DWORD /d 10 /f

Reboot after. A value of 10 seconds is safe. Anything over 60 is asking for a frozen desktop instead of a clean recovery.

The other thing to check here: some older cards and a few laptop iGPUs misreport their dedicated VRAM size to Windows. DirectX sees a number that doesn't match reality. You can verify with dxdiag under the Display tab. If it reports 128MB for a card that has 4GB, that's a driver/BIOS bug — usually fixed by a motherboard BIOS update on laptops.

On desktops with a discrete card, also check the BIOS for "Above 4G Decoding" and "Resizable BAR." Enabling Resizable BAR on a supported board lets the CPU see the whole VRAM aperture instead of a 256MB window, and it removes a class of these errors entirely on cards that support it (RTX 30-series and up, RX 6000 and up).

What it isn't

It's almost never the PSU. People love to blame the PSU. Unless you're seeing random WHEA_UNCORRECTABLE_ERROR or hard shutdowns with no bugcheck, the PSU is fine.

It's also very rarely actual GPU hardware failure. Hardware VRAM failure shows up as artifacts, colored squares, or the card not posting at all — not with a clean 0xC01E0100.

Quick reference

Start at the top of that table. 80% of the time it's line one. Stop looking for exotic causes before you've ruled out the obvious one.