Fix 0X000005AC: Paged Pool Memory Exhaustion on Windows Server

Quick answer: Reboot the server to restore paged pool, then run PoolMon.exe to find the driver tag using the most NonPaged or Paged memory. Use Driver Verifier or a memory dump to identify the leaky driver. Disable or update that driver.

What’s going on with this error?

You’re getting 0X000005AC — ERROR_PAGED_SYSTEM_RESOURCES. This isn’t RAM starvation. This is specifically about paged pool, a small chunk of kernel memory Windows sets aside for drivers and the OS kernel itself. Once that pool is full, any operation that needs it — like creating a new process, opening a file, or starting a service — fails with this error.

I’ve seen this most often on file servers running backup software that uses shady filter drivers, or on Hyper-V hosts after months of uptime. The paged pool size is limited by the system’s physical RAM and boot settings. On a typical server with 32 GB RAM, paged pool maxes out around 512 MB. That’s not much. A single leaky driver can eat it in days.

Let’s fix this now. Don’t skip step 1 — it buys you breathing room.

Step-by-step fix

Reboot the server. I know you hate downtime. But reboot now. This clears the paged pool and the error goes away temporarily. After rebooting, check Event Viewer for any warnings about pool allocation failures. They’ll show up under System with source “Kernel-General” or “Tcpip”.
Open Performance Monitor. Hit Win + R, type perfmon, press Enter. Under “Performance Monitor” in the left tree, click the green plus sign. Add these counters:
- Memory \ Pool Paged Bytes
- Memory \ Pool Nonpaged Bytes
- Memory \ Free System Page Table Entries
Watch them for 10-15 minutes. If Pool Paged Bytes climbs steadily even when the server is idle, you’ve got a leak.
Run PoolMon from Windows SDK. On a server with internet, install Windows Performance Toolkit (part of Windows ADK). Without internet, copy PoolMon.exe and PoolMon.sys from another machine. Run this command as Admin:
```
poolmon /p /n /b
```
This shows paged pool allocations sorted by bytes. Look for a tag that’s using 100+ MB. Common leaky tags:
- MmSt – memory manager, could be a buggy driver
- NtFs – file system filter driver
- Scan – antivirus filter driver
- TcpA – TCP/IP stack, usually not a leak but can be
Write down the tag name. That’s your target.
Identify the driver owning that tag. Run this PowerShell command as Admin:
```
Get-WmiObject Win32_PoolTag | Where-Object {$_.Tag -eq 'MmSt'} | Format-List
```
Replace MmSt with your tag. This shows which driver uses it. Example output: DriverName = "fileinfo.sys". That’s your leaky driver or at least the one holding the pool.
Disable or update the driver. If it’s a third-party driver (like from backup software, antivirus, or a storage filter), open Device Manager, find the device, right-click, Properties, Driver tab, “Disable device”. Or update it from the vendor’s site. Reboot and check pool usage again. If it’s a Microsoft driver (like ntfs.sys, fltmgr.sys), run sfc /scannow and check Windows Update. I’ve seen fltmgr.sys leak on Server 2016 after a bad update — uninstalling that KB fixed it.

Alternative fixes if the main one doesn’t work

Increase paged pool size (temporary band-aid)

If you’re stuck and can’t find the leak, you can expand paged pool. Run regedit as Admin, go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

Create a DWORD (32-bit) value named PagedPoolSize, set it to 0xFFFFFFFF (decimal: 4294967295). That makes paged pool as large as available virtual address space (up to 1-2 GB on 64-bit). Reboot. This hides the problem but doesn’t fix it. Only use this if you’re planning a full driver audit later.

Use Driver Verifier to catch the leak

Driver Verifier slows down the server but catches the bad driver. Run verifier.exe, select “Create custom settings”, next, check “Special pool”, “Pool tracking”, “Force IRQL checking”, “Deadlock detection”. Next, “Select driver names”, add the suspect driver from step 4. Reboot. If the driver leaks, the server will bugcheck with a blue screen that names the driver in the error. That’s your culprit. Remove it using the verifier /reset command after fixing.

Capture a full memory dump for analysis

Set up a memory dump: System Properties → Advanced → Startup and Recovery → Settings, choose “Complete memory dump”. Reproduce the error or let the server crash. Analyze the dump with WinDbg. Run !vm 4 to see pool usage, then !poolused 2 to list tags by usage. This is the nuclear option but works when nothing else does.

Preventing this error from coming back

Monitor paged pool daily. Set up a simple scheduled task that runs powershell -command "(Get-Counter '\Memory\Pool Paged Bytes').CounterSamples.CookedValue" every 4 hours. Log it. Alert on values over 300 MB.
Keep drivers updated. Especially storage filter drivers, antivirus minifilters, and backup agents. Vendors issue fixes for pool leaks.
Avoid stacking filter drivers. If you’re running encryption + backup + antivirus all as file filters, one of them will likely leak. Use a single integrated security suite instead.
Schedule monthly reboots. On critical servers, a monthly reboot clears pool fragmentation. It’s not a fix for a leak, but it stops the error from showing up during business hours.

That’s the whole deal. You’re now equipped to find the leak and kill it. Don’t just reboot and forget — the error will come back faster each time as pool fragmentation builds up. Track it down now.