| Previous | Next |
| INPUT_E_TRANSFORM | E_MBN_CONTEXT_NOT_ACTIVATED |
INPUT_E_DEVICE_PROPERTY
The scope of INPUT_E_DEVICE_PROPERTY is pointer-device metadata and capabilities. A required input-device property is unsupported or reported in an invalid form. Keep 0x80400008 beside the returning method because a wrapper can replace this distinction with a generic subsystem message.
Start with the returning API
When it is returned, a pointer identifier is interpreted through device metadata supplied by the input stack. Capabilities such as contact dimensions, pressure, orientation, physical scale, and HID usage can be optional, but values that are advertised must still satisfy their units and ranges. A stale device record after removal or session change is different from a live device that reports one malformed property.
Inspect the following boundary: the failing property can describe HID usage, physical dimensions, resolution, orientation, contact capability, pressure, or another device-specific characteristic. Separate “not supported” from “reported with an impossible value.”.
Limits of this code
INPUT_E_DEVICE_INFO is a failure to retrieve the device record; this code is narrower and concerns one property of a resolved device. Do not replace an invalid physical dimension or resolution with an arbitrary default when accuracy, palm rejection, or security depends on it.
Diagnostic evidence matrix
| Record | Why it matters here |
|---|---|
| Property identifier, type, size, and raw returned value | In this result diagnostics, recording property identifier, type, size, and raw returned value ties the HRESULT to the pointer-device metadata and capabilities boundary rather than to the final visible failure. |
| Device instance ID, driver version, HID usage page and usage | Comparing device instance ID, driver version, HID usage page and usage shows whether this result follows input, object state, or environment. |
| Whether the property is mandatory for the requested operation | Preserving whether the property is mandatory for the requested operation provides the evidence needed to test this distinction: iNPUT_E_DEVICE_INFO is a failure to retrieve the device record; this code is narrower and concerns one property of a resolved device. |
| Results from a known-good device and from the same device after re-enumeration | Recording results from a known-good device and from the same device after re-enumeration separates the pointer-device metadata and capabilities boundary from a later wrapper symptom. |
Reproduce without destructive cleanup
Compare the same property query on the same physical device before and after reenumbering, resume, or reconnect., then compare a second device without changing the application build; this separates device-specific metadata from caller structure and version errors.
- When it is returned, query only the property that the operation actually needs.
- Validate range, units, and structure size before using the value.
- use documented capability checks before requesting optional data.
- When it is returned, compare with another driver version or the Microsoft sample path without changing the application input trace.
Useful comparison axes
| Test | Interpretation | Hold constant |
|---|---|---|
| Same environment, reduced input | If this result disappears with a smaller faithful case, complexity within pointer-device metadata and capabilities is implicated. | Keep property identifier, type, size, and raw returned value fixed while simplifying whether the property is mandatory for the requested operation. |
| Same input, fresh object generation | If this result changes after rebuilding state, examine ownership across the packet producer, frame collector, and interaction consumer. | Place device instance ID, driver version, HID usage page and usage on the timeline of the last successful transition. |
| Same operation on a controlled second path | If this result follows one environment, the failure is not explained by source data alone. | Compare pointer type, device identity, window, DPI context, and callback phase while preserving results from a known-good device and from the same device after re-enumeration. |
What success must demonstrate
A correction for it should let the operation at the pointer-device metadata and capabilities boundary complete repeatedly under the original supported conditions. Repeat the control that begins with “Query only the property that the operation actually needs” and confirm that the following lifecycle step also succeeds. Keep the original failing sample and one deliberate negative case so fallback cannot be mistaken for repair.
Technical references
When it 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.