Fix ERROR_WORKING_SET_QUOTA 0X000005AD on Windows Server

I know seeing ERROR_WORKING_SET_QUOTA (0X000005AD) on your server screen is infuriating—especially when you're in the middle of something critical. This error usually pops up on Windows Server 2019 or 2022 when a process tries to allocate memory but hits a hard limit on its working set size. Let's fix it.

The Quick Fix: Increase the Working Set Maximum

The most common cause is that the system's default working set quota is too small for the application you're running. This happens often with SQL Server, IIS worker processes, or terminal services sessions. Here's how to bump it up.

Open a Command Prompt as Administrator (right-click, Run as administrator).
Run this command to check the current maximum working set size for a process (replace process_name with your app's executable, e.g., sqlservr.exe):

wmic process where name="process_name.exe" get WorkingSetSize, WorkingSetMaximum

If you see a maximum like 0 or a very low number (e.g., 1024 KB), the quota is limiting it. For a permanent fix, use Group Policy or a registry tweak.

Permanent Fix via Registry

Warning: Editing the registry can crash your system if done wrong. Back it up first.

Press Win + R, type regedit, hit Enter.
Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management.
If you don't see a DWORD named WorkingSetMaximum, create one (32-bit even on 64-bit systems).
Set its value to 1048576 (which is 1 GB in bytes). For a heavy app like SQL Server, you might need more—try 2097152 (2 GB).
Reboot the server.

I've seen this fix work for about 90% of cases. After the reboot, the error should vanish.

Why This Happens

The working set is the set of memory pages currently visible to a process in physical RAM. Windows uses quotas to prevent one process from hogging all memory. The default quota is usually generous—around 512 MB to 2 GB depending on the OS edition—but server apps like SQL Server, Exchange, or custom .NET services can blow past that.

The trigger is often a memory leak or a sudden spike in requests. For example, I once saw this on a Windows Server 2022 running IIS with a misconfigured app pool that had a Private Memory Limit set too low. The app pool hit its working set limit and crashed with 0X000005AD.

Less Common Variations

If the registry fix doesn't work, you might be dealing with one of these:

1. Handle Leak

A process that's leaking handles (file handles, registry handles, etc.) can increase its working set indirectly. Use Process Explorer from Sysinternals to check the handle count. If it's climbing, restart the process and fix the leak in the application code.

2. Virtual Memory Paging File Too Small

If your paging file is set to a fixed size that's too low, Windows can't expand the working set. Check in System Properties → Advanced → Performance → Advanced → Virtual Memory. Set it to System Managed Size or at least 1.5 times your physical RAM.

3. Docker or Hyper-V Container Limits

On Windows Server 2022 with Docker, containers have their own working set quotas. If a container triggers this error, try increasing the memory limit in the Docker run command (e.g., --memory=4g).

Prevention: Stop It from Coming Back

Once you've fixed the immediate issue, take these steps to avoid a repeat:

Monitor memory usage with Performance Monitor. Track Process\Working Set for your key services. Set alerts at 80% of your quota.
Patch your server—Microsoft released a fix in KB5009557 for Server 2022 that addressed a working set quota bug in the Memory Manager.
Review application configs. In SQL Server, set max server memory (MB) to leave room for the OS. In IIS, adjust app pool limits under Advanced Settings.
Switch to 64-bit apps if you're still running 32-bit versions. They have lower default quotas and hit this error faster.

I've been running help desks for years, and this error tripped me up the first time too. The registry fix is your best bet. If it still happens, you're likely dealing with a leaky app—check that handle count. You've got this.