| Previous | Next |
| SPAPI_E_NO_COMPAT_DRIVERS | SPAPI_E_INVALID_INF_LOGCONFIG |
SPAPI_E_NO_DEVICE_ICON
SPAPI_E_NO_DEVICE_ICON — 0x800F0229
A productive investigation starts at device-specific icon availability. The status means that SetupAPI found the device context but no icon represents that device or device type through the requested property/resource path.
What the status narrows down
For device installation, SetupAPI. Dev. Log is the chronological backbone. Correlate the HRESULT with the device instance ID, selected INF and section, signature or rank decision, file queue, class/co-installer dispatch, and rollback for that exact attempt instead of reading isolated lines from different installations.
Do not collapse this result into a nearby status. Failure to load a registered class icon is different from a device that simply has no device-specific icon. Compare lifecycle, identity, caller, and first API.
Evidence worth preserving
| Preserve before changing state | Diagnostic value |
|---|---|
| Device instance ID, setup class, device-interface class, and icon-loading API | Tests whether the first boundary moves. |
| Device metadata/icon property and fallback class icon result | Pins evidence to one attempt. |
| Driver package version, metadata package, and install timestamp | Separates contract failure from environment. |
| SetupAPI. Dev. Log and property-query status for the device | Creates a stable before/after control. |
Identifiers, timestamps, versions, counts, state flags, hashes, and redacted paths normally provide enough correlation. Keep credentials, private keys, message bodies, recovery material, and personal data out of routine incident logs.
A controlled diagnostic sequence
- Request the class icon as a fallback while keeping the device fixed; keep every other input fixed and record the first event that differs from the failing run.
- Compare another device using the same driver package and class; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Reinstall only the metadata/driver package in a disposable test system; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
A retry becomes evidence only when one controlled variable changes. In this case, if the same operation later succeeds unchanged, preserve that fact but continue checking timing, object generation, service restart, cache replacement, or policy refresh; transient success does not explain the earlier boundary.
How to read the outcome
Read the comparison results in this order:
| Observed result | Interpretation |
|---|---|
| The minimal or known-good comparison succeeds | The control works; inspect production-specific state. |
| The control fails at the same first operation | The control also fails; inspect host/provider evidence. |
| A new HRESULT marks another boundary | this boundary moved; diagnose the new status separately rather than treating it as confirmation that the entire operation is fixed. |
Correction and proof
A defensible correction is specific to the evidence: Provide or repair valid device metadata where required, but let administrative tools fall back to the class icon instead of treating appearance as device failure. Preserve the pre-change configuration or trace.
Close the incident only when device management remains functional with and without optional metadata, and the UI uses a deterministic fallback. Repeat under the original identity and state. A different environment is comparison, not proof.
Technical references
The diagnostic boundaries above are grounded in the following Microsoft specifications and API documentation:
- Microsoft Open Specifications: HRESULT values.
- Microsoft: using device installation functions.
- Microsoft: device and driver installation overview.
- Microsoft: SetupAPI device installation log entries.
Looking for a different code? Search another status or error code.