| Previous | Next |
| ERROR_WAKE_SYSTEM | ERROR_WAIT_2 |
ERROR_WAIT_1
Indexed wait completion for object 1
ERROR_WAIT_1 is Windows system result 731 (0x000002DB). The public text is the constant name, so the producing wait contract supplies the useful semantics.
The encoded index is 1: the second object in a zero-based wait set satisfied the wait. This is an indexed completion outcome, not a timeout, retry request, or indication that the operation waited once.
Where this value belongs
- A compatibility wrapper stores an indexed wait result as a Win32-compatible code.
- A dispatcher receives completion for the second handle in its current array.
- Diagnostic code translates a lower-level wait range into symbolic ERROR_WAIT_n values.
This result is meaningful only with the exact handle ordering used for that call. If the array is rebuilt between logging and dispatch, index 1 can be attributed to the wrong event.
Common interpretation mistakes
- It is mishandled when the value is tested with a simple nonzero-equals-failure branch.
- It is mishandled when index 1 is confused with the first object rather than the second.
- It is mishandled when WAIT_OBJECT_0 arithmetic is applied after a second translation already converted the result.
- It is mishandled when the handle at index 1 is closed or replaced while another thread is still waiting.
Diagnostic sequence
- Capture the raw return value before any HRESULT or Win32 conversion.
- Record the handle count and a stable label for each array element.
- Verify that index 1 existed for the specific wait invocation.
- Check the lifetime of the second handle until the wait returned.
- Confirm the second object was signaled and determine whether its state is auto-reset, manual-reset, semaphore, process, or thread.
- Dispatch the index only after validating it against the recorded count.
Evidence worth keeping
- preserve the ordered handle array and object types.
- preserve the second handle value, creation owner, and lifetime.
- preserve wait-all versus wait-any mode.
- preserve thread ID and start/end timestamps.
- preserve the predicate checked after the wait.
A useful it trace names both index 1 and the object, for example queue_ready_event, instead of leaving later investigators to reconstruct the array from source code.
Correct handling and recovery
Treat it as completion for the second object, perform the action assigned to that object, and then re-evaluate the surrounding loop predicate. Do not route it through generic failure recovery.
A new wait may be issued after the index-1 event is consumed according to its object semantics. Repeating the operation that preceded the wait requires a separate idempotency decision.
Difference from nearby values
ERROR_WAIT_2 and ERROR_WAIT_3 encode later positions in the same style. ERROR_TIMEOUT means no object satisfied the wait before the deadline and requires different control flow.
Practical scenario
A worker waits on shutdown at index 0 and queued work at index 1. It therefore selects the queue branch; a one-based label in telemetry would incorrectly report shutdown and can terminate the service.
Implementation guidance
Store the object label beside the handle and return a typed result containing category plus index. Static assertions and bounds checks should prevent dispatch tables from drifting away from wait arrays.
Record wait_1_count, wait_1_object, wait_1_object_type, wait_1_elapsed_ms, and wait_1_raw_result.
References
Looking for a different code? Search another status or error code.