| Previous | Next |
| STATUS_THREADPOOL_RELEASE_SEMAPHORE_ON_COMPLETION_FAILED | STATUS_THREADPOOL_FREE_LIBRARY_ON_COMPLETION_FAILED |
STATUS_THREADPOOL_RELEASE_MUTEX_ON_COMPLETION_FAILED
The callback could not release its mutex on return
ReleaseMutexWhenCallbackReturns defers releasing a mutex until the callback is leaving the worker thread. A failure usually points to invalid handle lifetime or ownership mismatch. A mutex can only be released by its owning thread, so moving ownership or attempting an additional release breaks the contract.
This status should trigger an audit of the entire lock path. The shared state may still be protected by a mutex that was never released, or another cleanup path may have released it prematurely. Continuing as though finalization succeeded can turn the original bug into a later deadlock.
What to inspect
- Record the mutex handle, owning worker thread, acquisition stack, callback instance, and nested status.
- Do not transfer mutex ownership to a different thread while a deferred release is registered.
- Avoid combining direct
ReleaseMutexcalls with callback-return release for the same acquisition. - Keep the mutex object valid until all callback finalization work has completed.
References
- Microsoft Open Specifications: NTSTATUS values
- Microsoft: ReleaseMutexWhenCallbackReturns
- Microsoft: threadpoolapiset.h functions
- Microsoft: pooled threads and callback environments
Looking for a different code? Search another status or error code.