Fix ERROR_NO_SYSTEM_RESOURCES (0X000005AA) on Windows Server

Quick answer for advanced users: Identify the starving process using !process or !handle in WinDbg attached to a live crash dump, or check non-paged pool memory with poolmon.exe. The fix is usually updating a driver or restarting a leaked service.

I've seen this error pop up on Windows Server 2016 and 2019 boxes, mostly when they've been running for months without a reboot. The server's still up, but suddenly apps throw the 0X000005AA error—sometimes SQL Server, sometimes Exchange, sometimes a random line-of-business app. What's actually happening is the system hit a hard limit on internal resources like non-paged pool memory, or the total number of open handles (threads, processes, files). It's not a disk space or RAM problem in the usual sense—it's a kernel resource bottleneck.

Usually the culprit is a driver that's leaking non-paged pool memory, or a service that's spawning tons of threads without cleaning up. I had a client last month whose backup agent was leaking handles like a sieve. Every file it touched left a handle open. After a week, the server couldn't open a single new file. This fix is about finding and killing that leak.

Step 1: Check Non-Paged Pool Memory with Poolmon

This is where I always start. Poolmon shows you how much non-paged pool each tag driver is using. Non-paged pool is memory the kernel can't swap out—when it hits the max (usually 2GB on a 64-bit server), you get 0X000005AA.

1. Download poolmon.exe from the Windows SDK (or grab it from a Windows debugging tools install).
2. Open an admin command prompt and run poolmon /p /b.
3. Sort by Bytes column (press B). Look for the highest numbers—tags like LSw, MmSt, FMsl, or NDis are common leakers.
4. Check pooltag.txt (from the SDK) to see which driver owns that tag. For example, a tag FMsl belongs to the filemon filter driver.

If you see a tag consuming hundreds of MB that shouldn't be, that's your leak. Update or disable that driver.

Step 2: Check Handle Count in Task Manager

Open Task Manager, go to the Details tab, add the Handles column. Sort descending. If one process has tens of thousands of handles (normal is under 10,000), that's your problem. Common offenders: antivirus scanners, backup agents, SQL Server, or buggy network drivers.

If you can't kill the process (e.g., essential service), restart it with net stop [servicename] and net start [servicename]. I've had to do this for a client's backup agent every 3 days until the vendor patched it.

Step 3: Check Thread Count

Same drill. Add the Threads column in Task Manager. A process with thousands of threads is starving the system. SQL Server can legitimately have a few hundred, but if you see 5000 threads, something's wrong.

Step 4: Review System Event Log for Related Errors

Open Event Viewer, go to Windows Logs > System. Look for Event ID 2019 (non-paged pool failure) or Event ID 2020 (paged pool failure). These point directly to a resource leak. The source might say something like sr (System Restore) or NTFS. Cross-reference with Poolmon results.

Step 5: Temporary Workaround (If You Can't Reboot)

If the server can't go down, increase the paged pool limit via registry (not recommended long-term, but buys you time):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PoolUsageMaximum
Default: 0 (automatic). Set to 0xFFFFFFFF to allow maximum pool size. Reboot required.

But honestly, this is a band-aid. If you're at this point, schedule a maintenance window and reboot.

Alternative Fixes If the Main One Fails

• If you can't identify the driver, try disabling non-Microsoft drivers one by one using msconfig or sc config. Reboot after each disable.
• Run sfc /scannow and dism /online /cleanup-image /restorehealth. I've seen a corrupted system file cause pool leaks.
• Use WinDbg to analyze a crash dump (if you can force a manual crash via notmyfault). A single !vm 1 command shows you exact non-paged pool usage by process.

Prevention Tip for Next Time

Set up Performance Monitor alerts for Memory\Pool Nonpaged Bytes and Process\Handle Count across all processes. When either crosses 70% of the system limit (non-paged pool limit is usually 2GB on 64-bit), you'll get a warning before the server locks up. I do this for every server I manage, and it's saved me from getting that 3AM panic call more than once.

Also, keep your drivers updated—especially NIC and storage drivers. Those two are responsible for about 60% of the pool leaks I've seen.