| Previous | Next |
| ERROR_NOT_ENOUGH_SERVER_MEMORY | ERROR_MAPPED_ALIGNMENT |
ERROR_POSSIBLE_DEADLOCK
A potential deadlock condition has been detected.
ERROR_POSSIBLE_DEADLOCK is Win32 error 1131 (0x46B). It is the Win32 form of a possible-deadlock condition. One documented source is a critical-section wait that exceeds the system deadlock timeout, where EnterCriticalSection can raise EXCEPTION_POSSIBLE_DEADLOCK or STATUS_POSSIBLE_DEADLOCK. The code is a debugging signal, not an invitation to catch the exception and continue as if synchronization were healthy.
What may be happening
- two or more threads hold locks in conflicting order and form a circular wait
- a thread waits on a critical section owned by a thread that is blocked on I/O, COM, a window message, or another process
- a lock owner exited, corrupted state, or stopped making progress
- loader-lock or
DllMainactivity participates in the wait chain - the wait is extremely long but not truly circular, revealing a hang or starvation problem
The word “possible” matters because a timeout proves lack of progress, not necessarily a perfect two-lock cycle. Either way, production code should preserve the process state for analysis instead of retrying the same lock acquisition blindly.
Evidence to capture immediately
- a full user-mode process dump with all thread stacks
- the waiting thread, lock address, owning thread, and recursion count when available
- wait-chain traversal output and blocked COM or window-message dependencies
- recent lock acquisitions, request IDs, and operations held across the wait
- Application Verifier or debugger output if lock checks are enabled
A log line with only error 1131 is rarely enough. Thread IDs, lock identity, owner stack, and the operation protected by the lock turn the symptom into an actionable lock-order or blocking-call defect.
Debugging sequence
- inspect every thread and identify who owns the object awaited by the failing thread
- follow that owner’s waits until the chain terminates or returns to an earlier thread
- check for locks held across synchronous I/O, callbacks, COM calls,
SendMessage, or process shutdown - enable Application Verifier lock and hang checks on a reproducible test build
- document a global lock order and verify every conflicting path against it
Do not change the critical-section timeout merely to suppress the report. A longer timeout delays detection while leaving the underlying cycle or unbounded blocking call in place.
Corrective design
Acquire multiple locks in one consistent order, minimize work while a lock is held, and avoid calling unknown or reentrant code under synchronization. Separate state protection from slow I/O. Where cancellation is required, design it so the cancelling thread does not wait for a worker while holding a lock that the worker needs to exit.
If the process must recover operationally, terminate and restart it after collecting a dump. Continuing from a caught possible-deadlock exception can leave ownership and protected invariants uncertain.
Related conditions
WAIT_TIMEOUT can be an expected bounded wait chosen by application code. Error 1131 is associated with system deadlock detection and deserves debugging. A high-CPU livelock may show no blocking chain at all even though the application also makes no useful progress.
Example
Thread A holds a configuration lock and sends a synchronous message to the UI thread. The UI thread is handling shutdown and waits for a worker that needs the same configuration lock. The critical-section wait eventually produces 1131. Reordering shutdown and removing synchronous UI calls under the lock fixes the cycle; increasing the timeout only hides it longer.
References
- Microsoft: System Error Codes (1000–1299)
- Microsoft: EnterCriticalSection function
- Microsoft: Wait chain traversal
- Microsoft: Application Verifier hang stop codes
Looking for a different code? Search another status or error code.