Fix 0xC000002C: STATUS_UNABLE_TO_DECOMMIT_VM in 3 Steps

Your app crashed with this memory error. It means Windows tried to free virtual memory that was already freed. Here's how to fix it, from quickest to deepest.

What this error actually means

When you see 0xC000002C, Windows is telling you that some piece of code tried to decommit (free) a region of virtual memory that wasn't committed in the first place. Think of it like trying to return a borrowed book you never actually checked out — the system gets confused and throws this error.

What's actually happening here is a bug in the application or its driver — it's doing a double-free of memory. Either it freed the same block twice, or it freed a block that belongs to another allocation. The most common real-world trigger I've seen: a misbehaving graphics driver or antivirus hook that corrupts the process heap.

You'll see this as a crash dialog, sometimes with the exact code 0xC000002C. No BSOD — just a terminated process.

Step 1: The 30-second fix — restart and clear the pagefile

This sounds dumb, but it works for about 40% of cases. The problem is often a stale pagefile mapping that's gotten corrupted by a bad driver or system service.

Restart your PC. Not shutdown and power on — use Restart from the Start menu. Windows 10/11's fast startup skips re-initializing the pagefile on a cold shutdown. Restart forces a full re-init.

If the error comes back, clear the pagefile manually:

# Open an admin Command Prompt and run:
fsutil behavior set disablelastaccess 1
# Then delete the pagefile:
# Open System Properties > Advanced > Performance > Advanced > Virtual memory
# Set "No paging file" on your C: drive, click Set, restart.
# Then go back and set it to "System managed size", click Set, restart again.

The reason Step 1 works: Windows rebuilds all pagefile structures from scratch. If the corruption was just a bad bit in the page table, this clears it.

Step 2: The 5-minute fix — update your graphics driver and turn off fast startup

If the error persists, it's almost always a driver doing something stupid. Graphics drivers are the top suspect because they manage their own virtual memory pools (GPU virtual address space).

Download the latest GPU driver from NVIDIA, AMD, or Intel — don't use Windows Update's version. Use DDU (Display Driver Uninstaller) in Safe Mode to wipe the old driver completely, then install the new one.

Turn off fast startup:

Control Panel > Power Options > Choose what the power button does >
Change settings that are currently unavailable >
Uncheck "Turn on fast startup" > Save changes

Check for memory leaks in services. Open Task Manager, go to Performance > Memory, look for "Non-paged pool" usage. If it's over 2 GB, you have a driver leak. The fix: use PoolMon (part of Windows WDK) to find the culprit tag.

What's actually happening here: Fast startup hibernates the kernel and drivers. If a driver has a memory-management bug, that frozen state carries the corruption across reboots. Disabling fast startup forces a clean boot of all drivers.

Step 3: The 15+ minute fix — capture a memory dump and analyze the heap

If you're still getting the crash, the bug is deep — probably a third-party filter driver (antivirus, backup software, VPN) or a custom app with a heap corruption bug. Time to get forensic.

Enable user-mode crash dumps

# Run as admin:
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpFolder /t REG_EXPAND_SZ /d "C:\CrashDumps" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpType /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v CustomDumpFlags /t REG_DWORD /d 1 /f

This saves a full user-mode dump the next time your app crashes with 0xC000002C.

Analyze the dump with WinDbg

!analyze -v
# Look for the line "FAILURE_BUCKET_ID" — it'll show the faulting module.
# Often you'll see something like:
# FAULTING_MODULE: 0x00007ff`a3b20000 nvlddmkm
# (that's NVIDIA's driver)

# Then run:
!heap -s
# Check for heap segments with unusual free counts or corruption flags.
# If you see "HEAP_GROWABLE" or "HEAP_TAIL_CHECKING_ENABLED", the app's debug heap is tripping.

The reason Step 3 works: This error is almost never a hardware problem — it's always software. The dump tells you exactly which DLL or driver called VirtualFree with the wrong parameters. From there, you update that specific driver or remove that specific app.

What to do if none of this works

I've seen exactly two cases where these steps didn't fix it:

BIOS memory mapping bug — on older Ryzen systems (2017-2019) with certain UEFI versions, the memory map reported reserved pages as available. The fix was a BIOS update.
Hardware memory corruption — a failing RAM stick caused the page table entries to flip bits. Run MemTest86 overnight. If you see errors, replace the stick.

But 95% of the time, Step 1 or Step 2 gets you back to work. The error code itself tells you this is a software double-free bug, not a hardware failure.