Fix 0XC000011F STATUS_TOO_MANY_OPENED_FILES on remote server

30-Second Fix: Check the server's open file count

Before you start registry surgery, rule out the obvious. This error means the remote server literally can't open another file handle. If you're running an application that opens hundreds of files simultaneously — like a backup agent, a web server with static files, or a log aggregator — it's probably just a resource crunch.

Run this PowerShell command on the remote server to see how many file handles are currently open:

(Get-CimInstance -Class Win32_Process -Property HandleCount | Measure-Object -Property HandleCount -Sum).Sum

If the total handle count is high (north of 80,000 on a default Windows Server), you're hitting the system limit. The quick-and-dirty fix is to restart the offending service — like the SMB server or IIS app pool — to flush handles. But that only buys you time.

If you're seeing this error consistently under normal daily load, skip the quick fix and move to the moderate fix below.

5-Minute Fix: Increase the server-side SMB file handle limit

The real culprit here is almost always the server's default SMB handle limit in older Windows builds (Server 2012 R2 and earlier). Starting with Server 2016, Microsoft bumped these limits significantly, but on Server 2012 R2 you'll hit the wall fast.

Open Registry Editor on the remote server and go to:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters

Create or edit these two DWORD values:

• MaxMpxCt — default is 50. Set it to 4096.
• MaxWorkItems — default is 256. Set it to 4096.

After setting those, reboot the server or restart the LanmanServer service:

net stop lanmanserver && net start lanmanserver

This doubles (or more) the number of simultaneous open file requests the SMB server can handle. If you're still getting the error after this, you need to go deeper.

15+ Minute Fix: Adjust kernel-level handle limits and investigate leaks

If the SMB tweak didn't cut it, the problem is probably a system-wide handle pool exhaustion. Windows has a default per-process handle limit of about 16 million handles — but the system-wide pool is lower and harder to change.

First, check if a single process is leaking handles. Run this on the server:

Get-Process | Sort-Object HandleCount -Descending | Select-Object -First 10 Name, HandleCount

If you see a process with tens of thousands of handles and it isn't a file server or database, that's your leak. Common offenders are custom .NET apps not disposing SMB shares properly, or anti-virus scanners that hold handles open on network shares.

If you can't fix the leak immediately, you can raise the system's maximum handle count via the registry. This isn't documented well, but it works:

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

Create a DWORD called PoolUsageMaximum and set it to 80 (decimal). This tells the kernel to allow the paged pool to use up to 80% of RAM before throttling. Default is 60.

Also check PagedPoolSize in the same key. Set it to 0xFFFFFFFF (the max) if it's not already. This prevents the paged pool from being artificially capped on lower-end hardware.

After both changes, reboot. You should now be able to handle far more open files before hitting this error.

When none of this works

If you've done all three steps and the error still pops up, you're likely dealing with a driver-level issue. Third-party SMB redirectors (like those from NetApp or EMC/Celerra) sometimes have their own handle limits. Check the storage vendor's documentation for SMB tuning knobs.

Also verify you're not hitting a file count limit on the share itself. Right-click the shared folder, go to Properties > Security > Advanced, and check the effective access for the user. If the ACL has explicit deny entries for certain files, that can cause the SMB server to open handles to check permissions and never close them cleanly — leading to this error.

Finally, if this is a virtualized server, check the VM's memory reservation. Handles live in the paged pool, which is carved out of physical RAM. If the VM is memory-constrained, the paged pool starves. Give the VM more RAM — at least 4 GB minimum for a file server with more than 50 concurrent users.