Fix ERROR_NO_PROC_SLOTS (0x00000059) on Windows

You're in the middle of running a batch script or a server app, and suddenly Windows throws ERROR_NO_PROC_SLOTS (0x00000059). The exact trigger is usually a process-heavy workload — maybe you're spawning hundreds of child processes from a Python script, or a build system like make is forking too aggressively. You might also see this after a cascading failure where one hung process keeps trying to restart.

What's actually happening here is that Windows has a hard limit on how many processes one user session can start. This isn't about memory or CPU — it's about the internal process table hitting its maximum slot count. The default on most Windows editions is 40,960 process slots per session. Once you cross that, every new process call fails with this error. It's a legacy from the NT design where process handles are mapped to session-scoped slots.

Root Cause

Windows uses a per-session process slot table. Each process consumes one slot until it exits. If you've got a leak — a program that spawns processes without properly closing handles, or a runaway script doing CreateProcess() in a tight loop — those slots fill up fast. The system doesn't automatically recycle dead slots until the process handle is closed. So you end up with a bunch of zombie processes consuming slots.

The limit itself is defined in the registry under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager. The value is MaxProcesses, and on most consumer Windows it's set to 0, meaning the system uses the default (40,960). On Windows Server, the default can be higher — up to 16 million — but consumer editions are stingier.

The Fix

First, check if you're actually hitting the limit. Open a command prompt as admin and run:

wmic process get processid,parentprocessid,executablepath | find /c /v ""

Count the lines. If you're near 40,000, that's your problem. If not, you might have a different issue — but the error code is specific, so it's likely the slot count.

Step 1: Kill Zombie Processes

The quick fix is to terminate processes that are stuck or orphaned. Use Task Manager or run:

taskkill /f /im badprocess.exe

If you don't know which one, open Resource Monitor (resmon.exe), go to the CPU tab, and sort by process count. Look for anything that's spawned hundreds of child processes. Kill the parent.

Step 2: Increase the Process Slot Limit

If you're consistently hitting the limit, raise the cap. Open Regedit as admin and navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Executive

(Note: the key path can vary. On some systems it's directly under Session Manager without Executive. If you don't see Executive, just use Session Manager.)

Create a DWORD named MaxProcesses (if it doesn't exist). Set it to a decimal value like 65535 or 131072. Reboot.

Step 3: Adjust the Session View Size

For 64-bit systems, another hidden limit is the session-wide handle table. You can increase it by adding:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Kernel\PagedPoolSize

Set it to 0xFFFFFFFF (max). This gives the kernel more room for process handles. Reboot again.

Step 4: Tune Your Application

The real fix is often in the code. If you're writing a script or app that spawns processes, make sure you're closing handles explicitly. In PowerShell, use Stop-Process or pipe to Wait-Process. In C/C++, call CloseHandle() on the process handle after CreateProcess(). Don't rely on garbage collection.

What If It Still Fails?

If you've increased the limit and it still throws 0x00000059, check for a driver or antivirus hooking process creation. Some security software intercepts NtCreateProcess and can slow it down, but not cause this error directly. More likely, you've got a process that's spinning up threads instead of processes — that's a different error (0x00000113). Also verify you're not running out of PID numbers. On 32-bit systems, PIDs wrap at 32,768, but that doesn't cause this error.

Last resort: boot into Safe Mode and test. If it works there, a third-party driver is the culprit. Use msconfig to disable non-Microsoft services iteratively until you find the one.

The reason step 2 works is that MaxProcesses raises the ceiling on the per-session process slot table. But if you've got a leak, you'll just hit the new limit faster. Fix the leak first, then raise the cap for headroom.