0X000009A2: Server Cannot Open More Files — Fix

When This Error Shows Up

You're running a Windows Server — maybe 2019 or 2022 — and suddenly clients can't access shared folders, printers stop spooling, or an app like a database or file server throws 0X000009A2 with the message "The server cannot open more files because it has reached its maximum number." It usually hits during peak hours when a bunch of users are hammering the same shares, or right after a backup job or a virus scan opens hundreds of files at once. I saw this last month with a law firm that had 40 paralegals all opening the same document repository — boom, the server just said "no more."

Root Cause: The Server Service Hits Its Ceiling

Windows has a built-in limit on how many files the server service (the one that handles SMB shares, named pipes, and mailslots) can have open at once. This limit is controlled by a registry value called MaxWorkItems, which defaults to a number based on your server's RAM — usually around 8192 or 16384. Once that many file handles are open, any new request gets this error. It's not a disk space issue or a memory problem — it's a hard cap on concurrent open files. Think of it as a bouncer at a club: once the guest list is full, no one else gets in until someone leaves.

The real-world trigger is almost always a leaky app or a misconfigured client that opens files without closing them. But sometimes it's just legitimate usage — your server needs a bigger bouncer.

Fix It: Step by Step

Step 1: Check Current File Usage

Before you change anything, see how many files the server service is holding. Open an admin Command Prompt and run:

net stats srv

Look for the line "Files opened" — that's the total since boot. Not super useful for real-time. Better: use handle.exe from Sysinternals or open Resource Monitor, go to the Disk tab, and look at File handles under the server process. If it's close to 8192 or 16384, you found the cap.

Step 2: Increase the MaxWorkItems Registry Value

This is the direct fix. Open Regedit and go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Create a new DWORD (32-bit) named MaxWorkItems if it doesn't exist. Set it to a higher value. I usually start with 32768 (decimal) and go up from there. This is the number of work items the server can allocate — each open file takes one work item. Don't go above 65535 unless you really know what you're doing, because it can starve other system resources.

Then create another DWORD called MaxMpxCt — this controls how many simultaneous requests a single client can make. Set it to 1028 (decimal) for clients like Windows 10/11 or Server 2022. Older clients might need 4096. Reboot the server after both changes.

Step 3: Find the Leak

If increasing the limit just delays the crash, something's not closing files. Use handle.exe to list open files sorted by handle count:

handle -a -p (process ID of server service) | find /c "File:"

Or better, run handle.exe -a -u (username) to see which user has the most open files. I've caught backup software that left temp files open, and a legacy line-of-business app that never called CloseHandle(). Kill the process that's leaking, then tell the vendor to fix their code. In the short term, schedule a nightly reboot of the server or the specific service if you can't patch it.

Step 4: Adjust the Server Service (Alternative)

If you can't reboot, you can reduce the open file limit per session via net config server /autodisconnect:15 — this forces idle sessions to disconnect after 15 minutes. But that's a band-aid, not a cure. Only use this if your users can handle getting kicked off occasionally.

What If It Still Fails?

If the error returns after you've bumped the limit and killed leaks, check for these:

Antivirus real-time scanning on the server — it can hold files open for scanning. Exclude your share paths from real-time scan.
Indexing service (Windows Search) — disable it on shares that get heavy use.
File Server Resource Manager (FSRM) quotas or file screens — they add overhead and can cause file handle starvation.
SMB version — older clients connecting with SMB1 can use more handles per session. Disable SMB1 on the server if you haven't.
Check the System event log for event ID 2018 or 2019 — those indicate pool memory exhaustion, which is a different beast but can mimic this error.

Worst case, the server hardware is simply undersized for the load. A server with 32GB RAM can typically handle a few thousand concurrent open files. If you're hitting 50,000+ open files legitimately, you need more cores and more RAM, or you need to redistribute shares across multiple servers.

I've also seen a bug in certain Windows Server 2016 builds that caused the server service to not release handles properly — update your server to the latest cumulative update, especially if you're on an old build.