| Previous | Next |
| INPUT_E_REENTRANCY | INPUT_E_PACKET |
INPUT_E_MULTIMODAL
INPUT_E_MULTIMODAL belongs to pointer sequencing and interaction state. The requested input cannot be processed while an interaction using another pointer type is still active. The diagnostic goal for INPUT_E_MULTIMODAL is to identify the first rejecting object and transition, not merely the final high-level symptom.
What the status establishes
For INPUT_E_MULTIMODAL, pointer delivery is a state machine, not a stream of interchangeable coordinates. When INPUT_E_MULTIMODAL is returned, Windows associates samples with a pointer identity, frame, device, modality, timestamp domain, and callback phase. 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 in the INPUT_E_MULTIMODAL path.
For INPUT_E_MULTIMODAL, inspect the following boundary: Windows tracks modality because touch, pen, mouse, and other pointer types can have different capture and gesture semantics. A second modality cannot simply be spliced into an unfinished interaction without an explicit transition.
Build a useful incident record
| Record | Why it matters here |
|---|---|
| Active pointer IDs and their pointer types | Comparing active pointer IDs and their pointer types shows whether INPUT_E_MULTIMODAL follows input, object state, or environment. |
| Capture owner, interaction state, and contact begin/end events | Preserving capture owner, interaction state, and contact begin/end events provides the evidence needed to test this distinction: iNPUT_E_FRAME can report mixed or inconsistent frame contents; INPUT_E_MULTIMODAL indicates that another modality is already engaged even if the new packet is individually well formed. |
| The new packet that introduced the other modality | For INPUT_E_MULTIMODAL, recording the new packet that introduced the other modality separates the pointer sequencing and interaction state boundary from a later wrapper symptom. |
| Device arrival, promotion, or synthetic-input policy in effect | In INPUT_E_MULTIMODAL diagnostics, recording device arrival, promotion, or synthetic-input policy in effect ties the HRESULT to the pointer sequencing and interaction state boundary rather than to the final visible failure. |
Reduce the scenario safely
Use one live pointer and one monotonic time source, then add replay, modality changes, or callback-triggered work separately in the INPUT_E_MULTIMODAL path. For INPUT_E_MULTIMODAL, a test that changes timestamp generation and callback dispatch at the same time cannot identify which contract was violated.
- For INPUT_E_MULTIMODAL, complete or cancel the active interaction before starting a second pointer type.
- When INPUT_E_MULTIMODAL is returned, test touch-only and pen-only traces separately.
- Introduce the modality transition at a clean frame boundary in the INPUT_E_MULTIMODAL path.
- For INPUT_E_MULTIMODAL, verify that pointer promotion is not duplicating one physical action as two logical modalities.
Interpret the controls
| Test | Interpretation | Hold constant |
|---|---|---|
| Same environment, reduced input | If INPUT_E_MULTIMODAL disappears with a smaller faithful case, complexity within pointer sequencing and interaction state is implicated. | For INPUT_E_MULTIMODAL, keep active pointer IDs and their pointer types fixed while simplifying the new packet that introduced the other modality. |
| Same input, fresh object generation | If INPUT_E_MULTIMODAL changes after rebuilding state, examine ownership across the packet producer, frame collector, and interaction consumer. | For INPUT_E_MULTIMODAL, place capture owner, interaction state, and contact begin/end events on the timeline of the last successful transition. |
| Same operation on a controlled second path | If INPUT_E_MULTIMODAL follows one environment, the failure is not explained by source data alone. | For INPUT_E_MULTIMODAL, compare pointer type, device identity, window, DPI context, and callback phase while preserving device arrival, promotion, or synthetic-input policy in effect. |
Keep neighboring failures separate
INPUT_E_FRAME can report mixed or inconsistent frame contents; INPUT_E_MULTIMODAL indicates that another modality is already engaged even if the new packet is individually well formed. For INPUT_E_MULTIMODAL, do not relabel a pen packet as touch or suppress pointer type merely to pass validation; downstream gesture behavior and security assumptions depend on the real modality.
Prove the correction
A correction for INPUT_E_MULTIMODAL 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 “Complete or cancel the active interaction before starting a second pointer type” and confirm that the following lifecycle step also succeeds. For INPUT_E_MULTIMODAL, keep the original failing sample and one deliberate negative case so fallback cannot be mistaken for repair.
Technical references
When INPUT_E_MULTIMODAL 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.