How to Fix ERROR_TOO_MANY_OPEN_FILES (0X00000004) on Windows

What Actually Causes 0X00000004

I've seen this error pop up on file servers running Windows Server 2016 or 2019 mostly, but also on Windows 10 Pro boxes acting as network shares. The short version: Windows has a hard limit on how many file handles (open files, pipes, sockets) any single process or the whole system can have. When you hit that limit, the OS spits out ERROR_TOO_MANY_OPEN_FILES (0X00000004) and refuses to open another file.

Had a client last month whose entire print queue died because of this — their print spooler service crashed after a backup job left hundreds of file handles open. The error showed up in the Application event log as Event ID 32 with the 0x4 code. The fix was different each time, so let's go through the three most common culprits in order of likelihood.

1. Handle Leak from a Specific Application

This is the most common cause I see. Some app — usually a backup tool, antivirus, or a custom business app — opens files and forgets to close them. Over hours or days, the handle count climbs until Windows says “enough.”

Quick Fix: Kill the Leaking Process

1. Open Task Manager (Ctrl+Shift+Esc) and go to the Details tab.
2. Click the Handles column to sort by handle count. If you don't see that column, right-click any column header and pick Select Columns, then check Handles.
3. Look for processes with handle counts in the thousands — anything over 5,000 is suspicious. Common offenders: svchost.exe hosting the print spooler, explorer.exe, or a third-party backup agent.
4. Right-click the suspect process and choose End task. If it's a critical system process, you'll get a warning — but if that process is the leak, killing it might be the only way to free handles fast.

Permanent Fix: Update or Replace the Leaky App

If you identify the app, check for updates. Had a client running an old version of Cobian Backup 11 that leaked handles like a sieve — upgrading to the latest version fixed it. If no update exists, you might need to restart the associated service daily via Task Scheduler. Ugly but works.

To check handle counts per process from the command line (faster for remote servers):

tasklist /fi "PID eq 1234" /fo list | findstr /i "handles"

Replace 1234 with the actual PID. Or use the free Process Explorer from Microsoft Sysinternals — sort by handle count, double-click a process to see what handles it's holding open.

2. System-Wide File Handle Limit Hit

Even if no single process leaks, the whole system can run out. Windows has a default limit of 16,777,216 handles system-wide (per machine) and 16,384 handles per process by default. That sounds huge, but on a busy file server with hundreds of concurrent users, you can hit it.

I had a client running a legacy ERP on Windows Server 2012 R2 — every user connected to a shared database file, and after about 120 users, the error started. The fix was to increase the per-process handle limit, because the ERP process alone was chewing through handles.

How to Check Current Handle Usage

Open PowerShell as admin and run:

Get-Process | Measure-Object -Property HandleCount -Sum

That gives you total handles. If it's above 14 million, you're close to the system limit. If a single process has over 10,000 handles, you're hitting the per-process limit.

Fix: Increase the Per-Process Handle Limit via Registry

Warning: Only do this if you're certain the app needs it. Increasing the limit won't fix a leak — it just delays the crash.

1. Open Regedit as admin.
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows.
3. Find the USERProcessHandleQuota value. If it's not there, create a new DWORD (32-bit) with that name.
4. Double-click it and set the value to the max handles per process. Default is 10,000 (0x2710). Set it to 18,000 (0x4650) for most cases — don't go above 32,768 unless you really know what you're doing.
5. Restart the process (or the server) for the change to take effect.

For the system-wide limit (rarely needed), you'd need to edit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PoolUsageMaximum — but I've never had to touch that in 15 years.

3. File Server Share Limit (SMB)

If you're running a Windows file server with SMB shares, there's a separate limit for open files through SMB. The default on Windows Server is 16,384 open files per share. On a busy file server with large files (like CAD drawings or databases), this gets hit fast.

Check Open SMB Sessions

Open PowerShell as admin:

Get-SmbOpenFile | Measure-Object | Select Count

If that count is near 16,384, you're hitting the SMB limit. The error won't show as 0x00000004 directly in the event log — it'll show as STATUS_TOO_MANY_OPEN_FILES (0xC000011F) in the SMB audit logs. But the application sees 0x4.

Fix: Increase SMB Open File Limit

On the file server:

1. Open Server Manager, go to File and Storage Services > Shares.
2. Right-click the share and choose Properties.
3. Under the Settings tab, increase the Number of open files per user limit. Default is 16,384 — bump it to 32,768 or 65,536 if needed.
4. Click OK and test.

If you prefer command line:

Set-SmbShare -Name "YourShareName" -MaxConcurrentOperations 65536

Also check the SMB server's MaxMpxCount setting — that controls how many outstanding requests a client can have. Default is 50, but I've seen it need to be 100 for heavy-load environments. Add a DWORD at HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\MaxMpxCount and set it to 100 or 200.

Quick-Reference Summary Table

If you've tried all three and still see 0x00000004, check for a hardware issue — failing RAM can cause weird handle allocation failures. Run memtest86 for a full pass. That's rare but I've seen it once on a Dell PowerEdge R740.