| Previous | Next |
| SL_REMAPPING_MDOLLAR_OSR_DEVICE_BLOCKED | INPUT_E_REENTRANCY |
INPUT_E_OUT_OF_ORDER
INPUT_E_OUT_OF_ORDER identifies a failure in pointer sequencing and interaction state. The input pipeline received samples whose timestamps or frame sequence move backward instead of forward. Investigation of INPUT_E_OUT_OF_ORDER should preserve the original object generation before cleanup, retry, or fallback creates a secondary result.
Read the HRESULT in context
Pointer delivery is a state machine, not a stream of interchangeable coordinates in the INPUT_E_OUT_OF_ORDER path. For INPUT_E_OUT_OF_ORDER, Windows associates samples with a pointer identity, frame, device, modality, timestamp domain, and callback phase. When INPUT_E_OUT_OF_ORDER is returned, sequence failures are therefore diagnosed by reconstructing when the interaction began, which modality owns it, and whether the caller re-entered the same state machine before the previous notification completed.
For INPUT_E_OUT_OF_ORDER, inspect the following boundary: chronology must be evaluated after the application has chosen one time base; mixing device timestamps, QPC-derived values, and replay-relative time can create an apparent reversal even when each source is internally ordered.
Capture before changing state
| Record | Why it matters here |
|---|---|
| Pointer and frame identifiers around the first reversal | In INPUT_E_OUT_OF_ORDER diagnostics, recording pointer and frame identifiers around the first reversal ties the HRESULT to the pointer sequencing and interaction state boundary rather than to the final visible failure. |
| Raw and converted timestamps with their units and clock origin | Comparing raw and converted timestamps with their units and clock origin shows whether INPUT_E_OUT_OF_ORDER follows input, object state, or environment. |
| Source device, pointer type, and replay or injection batch number | Preserving source device, pointer type, and replay or injection batch number provides the evidence needed to test this distinction: iNPUT_E_FRAME and INPUT_E_HISTORY concern inconsistent membership or identity inside frames or history; this result is specifically about chronology. |
| The API that accepted the previous sample and rejected the next one | For INPUT_E_OUT_OF_ORDER, recording the API that accepted the previous sample and rejected the next one separates the pointer sequencing and interaction state boundary from a later wrapper symptom. |
Three diagnostic branches
| Test | Interpretation | Hold constant |
|---|---|---|
| Same environment, reduced input | If INPUT_E_OUT_OF_ORDER disappears with a smaller faithful case, complexity within pointer sequencing and interaction state is implicated. | For INPUT_E_OUT_OF_ORDER, keep pointer and frame identifiers around the first reversal fixed while simplifying source device, pointer type, and replay or injection batch number. |
| Same input, fresh object generation | If INPUT_E_OUT_OF_ORDER changes after rebuilding state, examine ownership across the packet producer, frame collector, and interaction consumer. | For INPUT_E_OUT_OF_ORDER, place raw and converted timestamps with their units and clock origin on the timeline of the last successful transition. |
| Same operation on a controlled second path | If INPUT_E_OUT_OF_ORDER follows one environment, the failure is not explained by source data alone. | For INPUT_E_OUT_OF_ORDER, compare pointer type, device identity, window, DPI context, and callback phase while preserving the API that accepted the previous sample and rejected the next one. |
A minimal test sequence
When INPUT_E_OUT_OF_ORDER is returned, use one live pointer and one monotonic time source, then add replay, modality changes, or callback-triggered work separately. A test that changes timestamp generation and callback dispatch at the same time cannot identify which contract was violated in the INPUT_E_OUT_OF_ORDER path.
- Feed a minimal sequence from one pointer and one device with strictly increasing timestamps in the INPUT_E_OUT_OF_ORDER path.
- For INPUT_E_OUT_OF_ORDER, apply the production timestamp conversion without merging other devices.
- When INPUT_E_OUT_OF_ORDER is returned, add coalesced history in the order returned by the API, then add cross-device merging last.
- Verify wraparound and integer-width handling with values near the observed boundary in the INPUT_E_OUT_OF_ORDER path.
Common wrong turns
INPUT_E_FRAME and INPUT_E_HISTORY concern inconsistent membership or identity inside frames or history; this result is specifically about chronology. For INPUT_E_OUT_OF_ORDER, do not repair the trace by sorting samples after the fact because sorting can place an UP event before its preceding UPDATE or move a sample into the wrong frame.
Regression verification
A correction for INPUT_E_OUT_OF_ORDER should let the operation at the pointer sequencing and interaction state boundary complete repeatedly under the original supported conditions. Repeat the control that begins with “Feed a minimal sequence from one pointer and one device with strictly increasing timestamps” and confirm that the following lifecycle step also succeeds. For INPUT_E_OUT_OF_ORDER, keep the original failing sample and one deliberate negative case so fallback cannot be mistaken for repair.
Technical references
When INPUT_E_OUT_OF_ORDER is returned, these references define the public API family, object model, or error list used to interpret this status.
- Microsoft: COM error codes for Input and graphics.
- Microsoft: Pointer Input Messages and Notifications.
- Microsoft: POINTER_INFO structure and pointer lifetime.
- Microsoft: GetPointerFrameInfoHistory.
- Microsoft: Interaction Context API.
Looking for a different code? Search another status or error code.