| Previous | Next |
| ERROR_WAIT_1 | ERROR_WAIT_3 |
ERROR_WAIT_2
Indexed wait completion for object 2
ERROR_WAIT_2 is Windows system result 732 (0x000002DC). Its numeric placement identifies an array position rather than an error severity.
This result selects object index 2, which is the third entry passed to the wait. The value does not mean two waits occurred and it has no built-in time unit.
Where this value belongs
- A service waits on stop, reload, and maintenance events and the maintenance handle is third.
- An event loop translates an indexed completion into a symbolic Win32 result.
- A test harness validates dispatch behavior for a three-or-more-object wait set.
The interpretation of it is coupled to the array snapshot for one invocation. A log that records only code 732 but omits the third object label is incomplete.
Common interpretation mistakes
- It is mishandled when a new handle is inserted before index 2 without updating the dispatch table.
- It is mishandled when developers read the suffix 2 as a count or timeout.
- It is mishandled when the third handle is reused for another kernel object before the waiter exits.
- It is mishandled when wait-all logic is analyzed as though a single index selected one object.
Diagnostic sequence
- Identify the exact wait call that emitted code 732.
- Snapshot the ordered array before entering the wait.
- Confirm the wait used wait-any semantics before treating index 2 as a selector.
- Inspect the third object state and reset behavior at return time.
- Compare the array with the switch or callback table that handles index 2.
- Exercise a test where only the third object is signaled and verify the intended branch.
Evidence worth keeping
- preserve array revision or generation number.
- preserve third handle label and object type.
- preserve wait-any or wait-all flag.
- preserve dispatch-table entry for index 2.
- preserve object signal and reset timestamps.
It investigations benefit from an array generation counter because the same thread can use several differently ordered wait sets during its lifetime.
Correct handling and recovery
Map it to the third object from the captured array generation, execute only that object’s handler, and preserve other signaled conditions for the next loop iteration.
Re-entering the wait is normal after handling the event. Reissuing an external mutation merely because code 732 is nonzero is incorrect.
Difference from nearby values
ERROR_WAIT_1 selects the second entry and ERROR_WAIT_3 selects the fourth. It must never be converted to ERROR_TIMEOUT or ERROR_RETRY.
Practical scenario
A maintenance event is added as the third handle, but an old switch statement still labels case 2 as configuration_reload. The mismatch becomes visible When it is logged with the array generation and actual handle name.
Implementation guidance
Generate wait arrays and dispatch metadata from the same definition. Unit tests should signal each object individually and verify the returned index and handler.
Record wait_2_array_generation, wait_2_index, wait_2_label, wait_2_wait_all, and wait_2_handler.
References
Looking for a different code? Search another status or error code.