What does Windows error code 102 (ERROR_SEM_IS_SET) mean?

 
Could be also:
ConstantTypeOS
HTTP_STATUS_PROCESSINGHTTP CodeAny
ENETRESETerrnoLinux
EOPNOTSUPPerrnoMac
EAFNOSUPPORTerrnoWindows
CACHE_INITIALIZATION_FAILEDBugCheck CodeWindows
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

  1. Log the semaphore state immediately before close, reset, and release operations
  2. Track which thread signaled the object and which thread attempted cleanup
  3. Verify that producers have stopped before the owner begins destruction
  4. 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.