| Previous | Next |
| ERROR_EXCL_SEM_ALREADY_OWNED | ERROR_TOO_MANY_SEM_REQUESTS |
ERROR_SEM_IS_SET
What ERROR_SEM_IS_SET means
The semaphore is in a signaled or set state that prevents the requested close or state transition. This status belongs to older semaphore contracts in which an object could not be closed or modified while set. It usually indicates that the caller is performing lifecycle operations in the wrong order.
Common causes
- The application closes the semaphore before clearing or consuming its signaled state
- Two components disagree about which one owns final cleanup
- A shutdown path races with a producer that signals the object
- Compatibility code maps a modern event or semaphore onto stricter legacy rules
How to investigate
- Log the semaphore state immediately before close, reset, and release operations
- Track which thread signaled the object and which thread attempted cleanup
- Verify that producers have stopped before the owner begins destruction
- Repeat under a scheduler-stress tool to expose the ordering race
Developer guidance
Separate stop signaling from object destruction. First prevent new producers, then wait for active users, then normalize the object state, and only then release the final handle.
Administrator and support guidance
Repeated retries are unlikely to help unless the owner changes the semaphore state. Gather a trace of the shutdown sequence instead of continuously reopening the application.
How this code differs from related results
This is not a generic access-denied result. The handle may be valid and accessible; the requested operation is rejected because of the semaphore state.
Evidence worth collecting
For ERROR_SEM_IS_SET, begin the trace at the operation where the application closes the semaphore before clearing or consuming its signaled state. 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 log the semaphore state immediately before close, reset, and release operations. This evidence distinguishes the specific this result contract from a later secondary failure.
Recovery and verification
Recovery for it should address the observed condition rather than merely retrying the same call. After the change, reproduce the scenario in which the application closes the semaphore before clearing or consuming its signaled state, then confirm that the intended operation completes and that cleanup returns all associated resources. 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 this result 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 the application closes the semaphore before clearing or consuming its signaled state. For the result 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.