| Previous | Next |
| ERROR_NO_PROC_SLOTS | ERROR_EXCL_SEM_ALREADY_OWNED |
ERROR_TOO_MANY_SEMAPHORES
What ERROR_TOO_MANY_SEMAPHORES means
The system cannot create another semaphore because the available semaphore resources or implementation limit has been exhausted. This legacy Win32 result is associated with semaphore creation and with compatibility layers that expose older OS/2-style synchronization semantics. On modern Windows it is uncommon in ordinary desktop code, but it can still surface through old middleware, emulation, database runtimes, or software that creates synchronization objects without bounding their lifetime.
Common causes
- A process repeatedly creates semaphore objects and fails to close their handles
- A compatibility subsystem has reached an internal semaphore-table limit
- A service restart loop leaves another process holding named synchronization objects
- Stress or fault-injection testing creates objects faster than cleanup can reclaim them
How to investigate
- Record the API that returned the code and whether the semaphore was named or unnamed
- Inspect handle growth in the producing process and group handles by object type
- Correlate creation attempts with shutdown, cancellation, and exception paths
- Reproduce with a fixed concurrency level to identify the threshold at which creation begins to fail
Developer guidance
Treat semaphore creation as resource acquisition: check every returned handle, close it on every exit path, and avoid creating one semaphore per transient work item. Prefer a bounded pool or an existing thread-pool primitive when the synchronization topology is repetitive.
Administrator and support guidance
A restart may temporarily reclaim leaked process-local handles, but it does not explain the defect. Capture handle counts and the responsible module before restarting the service.
How this code differs from related results
Do not confuse this code with ERROR_TOO_MANY_POSTS. The latter concerns an excessive semaphore count or release operation, while this result concerns inability to create another semaphore object.
Evidence worth collecting
For ERROR_TOO_MANY_SEMAPHORES, begin the trace at the operation where a process repeatedly creates semaphore objects and fails to close their handles. For ERROR_TOO_MANY_SEMAPHORES, preserve the exact API boundary, numeric result, process and thread identifiers, relevant object state, and the component version. The first verification point should be to record the API that returned the code and whether the semaphore was named or unnamed. This evidence distinguishes the specific ERROR_TOO_MANY_SEMAPHORES contract from a later secondary failure.
Recovery and verification
Recovery for ERROR_TOO_MANY_SEMAPHORES should address the observed condition rather than merely retrying the same call. After the change, reproduce the scenario in which a process repeatedly creates semaphore objects and fails to close their handles, then confirm that the intended operation completes and that cleanup returns all associated resources. For ERROR_TOO_MANY_SEMAPHORES, also verify that the next repeated operation follows the same successful path without increasing the resource class implicated by this result.
When to escalate
Escalate ERROR_TOO_MANY_SEMAPHORES with a minimal reproduction focused on the failing synchronization boundary. Include the operating-system build, binary architecture, runtime or compatibility-layer version, the exact input values, and a timestamped trace showing a process repeatedly creates semaphore objects and fails to close their handles. For the ERROR_TOO_MANY_SEMAPHORES escalation record, note whether changing concurrency, object lifetime, target process, module set, or endpoint location alters the result.
References
Looking for a different code? Search another status or error code.