| Previous | Next |
| STATUS_THREADPOOL_SET_EVENT_ON_COMPLETION_FAILED | STATUS_THREADPOOL_RELEASE_MUTEX_ON_COMPLETION_FAILED |
STATUS_THREADPOOL_RELEASE_SEMAPHORE_ON_COMPLETION_FAILED
The deferred semaphore release did not complete
ReleaseSemaphoreWhenCallbackReturns schedules a count increment after the callback exits. Failure can mean the semaphore handle became invalid or the requested release would exceed the semaphore maximum. The callback result and the semaphore accounting result are separate outcomes.
A missing release can permanently reduce available capacity in a bounded worker or resource scheme. Conversely, an excessive release reveals double-finalization or inconsistent reservation ownership. Diagnose the count transition rather than simply retrying the release without knowing whether another path already performed it.
What to inspect
- Log the requested release count, configured maximum, prior reservation owner, and callback instance.
- Keep the semaphore handle alive until deferred callback actions finish.
- Ensure exactly one path returns each reserved unit, including cancellation and exception paths.
- Audit callbacks that both call
ReleaseSemaphoredirectly and register a deferred release.
References
- Microsoft Open Specifications: NTSTATUS values
- Microsoft: ReleaseSemaphoreWhenCallbackReturns
- Microsoft: threadpoolapiset.h functions
- Microsoft: pooled threads and callback environments
Looking for a different code? Search another status or error code.