| 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 INPUT_E_DEVICE_PROPERTY 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 in the INPUT_E_DEVICE_PROPERTY path. For INPUT_E_DEVICE_PROPERTY, a stale device record after removal or session change is different from a live device that reports one malformed property.
For INPUT_E_DEVICE_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. For INPUT_E_DEVICE_PROPERTY, 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 INPUT_E_DEVICE_PROPERTY 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 INPUT_E_DEVICE_PROPERTY 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 | For INPUT_E_DEVICE_PROPERTY, 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
For INPUT_E_DEVICE_PROPERTY, compare the same property query on the same physical device before and after reenumbering, resume, or reconnect. When INPUT_E_DEVICE_PROPERTY is returned, then compare a second device without changing the application build; this separates device-specific metadata from caller structure and version errors.
- When INPUT_E_DEVICE_PROPERTY is returned, query only the property that the operation actually needs.
- Validate range, units, and structure size before using the value in the INPUT_E_DEVICE_PROPERTY path.
- For INPUT_E_DEVICE_PROPERTY, use documented capability checks before requesting optional data.
- When INPUT_E_DEVICE_PROPERTY 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 INPUT_E_DEVICE_PROPERTY disappears with a smaller faithful case, complexity within pointer-device metadata and capabilities is implicated. | For INPUT_E_DEVICE_PROPERTY, 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 INPUT_E_DEVICE_PROPERTY changes after rebuilding state, examine ownership across the packet producer, frame collector, and interaction consumer. | For INPUT_E_DEVICE_PROPERTY, 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 INPUT_E_DEVICE_PROPERTY follows one environment, the failure is not explained by source data alone. | For INPUT_E_DEVICE_PROPERTY, 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 INPUT_E_DEVICE_PROPERTY 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. For INPUT_E_DEVICE_PROPERTY, keep the original failing sample and one deliberate negative case so fallback cannot be mistaken for repair.
Technical references
When INPUT_E_DEVICE_PROPERTY 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.