STATUS_WORKING_SET_QUOTA (0xC00000A1) Fix – Memory Lock Crashing Apps

1. The default working set limit is too low for your app

What's actually happening here is that Windows imposes a hard limit on how much virtual memory a process can lock into its working set — the physical RAM pages it holds exclusively. When a program (often a game, video editor, or database server) tries to lock more pages than that limit allows, Windows returns STATUS_WORKING_SET_QUOTA (0xC00000A1). The app then crashes or spits out a generic "insufficient memory" message.

The most common trigger: you're running a memory-intensive application — say, a modern game like Cyberpunk 2077 or Flight Simulator 2024 — that uses large-frame pages or tries to pin memory for DMA transfers. On a default Windows install, the working set maximum per process is set to a conservative value (often around 1.5 GB on 64-bit systems). That's not enough.

The fix: raise the per-process working set limit via registry

1. Press Win+R, type regedit, and hit Enter.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management.
3. Look for a DWORD named MaxWorkingSet. If it doesn't exist, create it (32-bit DWORD).
4. Set its value to 65535 (decimal) — that's approximately 2 GB per process. If you need more, push it to 131072 (4 GB). Don't go crazy; setting it above 4 GB can cause instability on some systems.
5. Reboot.

The reason step 4 works: MaxWorkingSet overrides the default working set maximum that Windows calculates at boot. By raising it, you tell the memory manager to allow larger locked pages per process. This is the single most effective fix — I've seen it resolve 0xC00000A1 on AutoCAD, Blender, and several Unreal Engine 4 builds.

Note: If you're running a server application (SQL Server, Exchange), you also need the "Lock pages in memory" user right. But for desktop apps, the registry tweak alone usually suffices.

2. A kernel-mode driver is leaking memory or corrupting the working set

The second most common cause is a buggy driver — especially GPU drivers — that calls MmLockPagableDataSection or MmProbeAndLockPages incorrectly. When that happens, the kernel's own working set quota for locked pages gets exhausted, and any process that tries to lock memory fails with 0xC00000A1. You'll see it across multiple applications, not just one.

This is tricky because the error isn't in your app — it's in the driver. The real giveaway: you reboot and the error disappears for a while, then comes back after a few hours of use. That's the driver leaking locked pages.

The fix: clean up drivers and reset the kernel's working set

1. Download RAMMap from Sysinternals.
2. Run it as administrator.
3. Click the Empty menu and choose Empty Working Set. This flushes all unlocked pages from the kernel's working set, which can temporarily release locked pages that the driver forgot to unlock.
4. If that doesn't help, run poolmon (part of the Windows SDK) to identify which driver tag is consuming the most locked memory. Look for tags with high "Paged" or "Nonpaged" bytes — that's your culprit.
5. Update your GPU driver to the latest stable version (not beta). For NVIDIA, use the Game Ready driver; for AMD, the Adrenalin driver. A common offender is the Intel Graphics driver on Surface devices — roll it back to the OEM version if updating doesn't fix it.
6. If the problem persists, run verifier.exe (Driver Verifier) in test mode to stress-test drivers. Be warned — this can crash the system and require a safe-mode recovery. Only do this if you're comfortable debugging bugchecks.

# Quick check: list processes with locked pages using PowerShell
Get-Process | Where-Object { $_.WorkingSet -gt 1GB } | Select-Object Name, WorkingSet, Id

The reason step 3 works: Empty Working Set forces the memory manager to re-evaluate which pages are truly locked. Some drivers call MmLockPagableDataSection on data segments that are actually pageable — the kernel marks them as locked, but they aren't really. Emptying the working set clears that misclassification.

3. Virtual memory commit limit is hit — not just working set

A less common but real scenario: the system-wide commit limit (physical RAM + page file) is maxed out. Windows can't create new page table entries for locking because there's no virtual address space left. The error code is still 0xC00000A1, but the root cause isn't the working set quota — it's the commit charge.

You'll see this when you have 32 GB of RAM, a tiny page file, and you're running multiple VMs or a memory-heavy editor like DaVinci Resolve. The commit limit is, say, 40 GB (32 + 8 page file), but you're trying to commit 45 GB across all processes. Windows blocks any new locked pages.

The fix: increase page file size or add physical RAM

1. Open System Properties → Advanced → Performance → Advanced → Virtual memory.
2. Uncheck "Automatically manage paging file size for all drives".
3. Select your system drive and choose Custom size.
4. Set initial and maximum size to 1.5× your physical RAM. For 32 GB, that's 49152 MB. Set both values equal to prevent fragmentation.
5. Click Set, then OK, and reboot.

# Check commit limit and current charge in PowerShell
Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object TotalVisibleMemorySize, FreePhysicalMemory, SizeStoredInPagingFiles, FreeSpaceInPagingFiles

The reason step 4 works: by increasing the page file, you raise the system commit limit. Even though locked pages must reside in physical RAM, the commit limit is based on RAM + page file size. A larger page file gives Windows breathing room to manage page table allocations for locked pages.

Don't believe the myth that "more page file slows things down." For locked pages, the page file is never touched — it's only used as a reservation. The performance hit is zero. What hurts is running out of commit space, which causes exactly this error.

Quick-reference summary table