0xC000001A fix: virtual memory can’t be freed

This error pops up when Windows can't release virtual memory during driver or app shutdown. It usually means a driver or system process is holding a memory lock too long.

When this error shows up

You're running a Windows 10 or Windows Server 2019 machine – maybe a Hyper-V host with a few VMs. Suddenly a program crashes, or you get a blue screen with 0xC000001A. The error message reads: STATUS_UNABLE_TO_FREE_VM – The virtual memory cannot be freed. It often happens right after you close a demanding app (like a virtual machine, a database server, or a backup tool) or when you try to shut down a Hyper-V guest. The system isn't releasing its page file memory, and Windows finally throws the error when it tries to reclaim the pages.

Root cause – plain English

Windows uses a virtual memory manager to assign chunks of memory to processes. When a process is done, the manager expects to get those pages back. But sometimes a driver or a system component – usually a buggy storage driver, network driver, or Hyper-V integration service – holds onto a memory reference longer than it should. It's like borrowing a book from the library and not returning it. The virtual memory manager waits, waits some more, then gives up and says “I can't free this block.” That's 0xC000001A.

The most common culprits on real hardware: old Hyper-V integration services, Broadcom network drivers, or third-party backup drivers that hook into the memory manager. On a VM guest, it's often the guest itself that won't release pages because of a misbehaving driver inside the VM.

Fix it step by step

Skip the usual “run SFC” nonsense. That won't help here. The real fix is to find the rogue driver or service.

Check which process caused the error. Open Event Viewer (eventvwr.msc). Go to Windows Logs > System. Look for a warning or error with source BugCheck or Application Popup near the time of the crash. The Details tab will often list the driver that was in play. Write down the driver name.
Run Driver Verifier for suspected drivers. Press Win + R, type verifier, hit Enter. Select “Create custom settings (for code developers).” Then select only “Special pool” and “Force IRQL checking.” On the next screen, pick “Select driver names from a list.” Add the driver you found in step 1. Warning: Verifier will slow that driver down. If you don’t know the driver yet, select “Automatically select unsigned drivers” instead. Then reboot. If the system BSODs with a different code, you've found the problem driver.
Update or roll back the driver. Once you have the driver name (say bxvbda.sys for Broadcom or vmswitch.sys for Hyper-V), go to Device Manager, find the device, right-click, Properties > Driver tab. If you recently updated it, click “Roll Back Driver.” If the driver is old, go to the hardware manufacturer’s site and download the latest version. Reboot.
Disable Hyper-V integration services inside the guest (if this is a VM). Shut down the VM. In Hyper-V Manager, right-click the VM > Settings > Integration Services. Uncheck everything except “Time synchronization” and “Heartbeat.” Reboot the VM. If the error stops, re-enable one service at a time (allow a day between each) to find the culprit. Usually Guest services or Data Exchange cause this.
Clear the page file and reboot. This is a safe step that forces Windows to rebuild its memory map. Go to System Properties (sysdm.cpl), Advanced tab, Performance > Settings > Advanced > Virtual memory > Change. Uncheck “Automatically manage paging file size for all drives.” Select your system drive, choose “No paging file,” click Set. Then select the same drive, choose “System managed size,” click Set. Click OK and reboot. This flushes stale memory mappings.

If it still fails

You’re probably dealing with a memory leak or a corrupted page file. Try these advanced checks:

Run poolmon to find a memory leak. Download the Windows Driver Kit (just the tools, not the full SDK) and run poolmon from an admin command prompt. Look for a tag that grows nonstop – that’s your leaky driver. Tag MmSt often means a buggy memory manager extension.
Check for a corrupted pagefile.sys – disable the page file as described in step 5, reboot, then delete the file manually (it will be hidden in the root of C:). Then re-enable the page file and reboot.
Test with a clean boot – disable all non-Microsoft services with msconfig, then enable them in batches of 5. This isolates which third-party driver or service is holding memory.

If none of that works, you’re likely looking at a hardware memory issue. Run mdsched.exe and let it test your RAM overnight. Bad RAM can mimic a virtual memory release failure by corrupting the page table itself.