| Previous | Next |
| STATUS_DRIVER_ENTRYPOINT_NOT_FOUND | STATUS_TOO_MANY_LINKS |
STATUS_RESOURCE_NOT_OWNED
Match every ownership acquisition with release on the same ownership path
STATUS_RESOURCE_NOT_OWNED is an ownership error. A concrete Windows example is a mutex: ReleaseMutex fails when the calling thread does not own the mutex. Windows mutexes also allow recursive acquisition by the owning thread, but ownership is not fully released until the thread calls ReleaseMutex once for each successful ownership acquisition.
This makes simple “locked/unlocked” logging insufficient. Record thread identity and acquisition depth for ownership-based primitives. A timeout path that never acquired the mutex must not execute unconditional release cleanup, and a handoff to another worker thread cannot transfer Windows mutex ownership merely by passing the handle. Compare that behavior with other primitives such as semaphores, which do not enforce the same thread ownership rule.
The NTSTATUS name is broader than the Win32 mutex API, so first identify the resource type that reported it. Then inspect every acquire, recursive acquire, wait failure, cancellation, exception, and cleanup branch. Do not add a catch-all ignore for release errors; ownership mismatches often indicate that protected state can also be accessed under the wrong synchronization assumptions.
What to inspect
- The synchronization/resource type, object identity, acquiring thread, releasing thread, and recursive acquisition count.
- Timeout, cancellation, and exception paths that run release cleanup even when acquisition did not succeed.
- Cross-thread handoff code and RAII/finally logic that may release from a thread different from the owner.
References
- Microsoft: ReleaseMutex
- Microsoft: Using Mutex Objects
- The Open Group: pthread_mutex_lock and pthread_mutex_unlock
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.