| Previous | Next |
| SPAPI_E_INF_IN_USE_BY_DEVICES | SPAPI_E_NO_AUTHENTICODE_CATALOG |
SPAPI_E_DI_FUNCTION_OBSOLETE
The important question is not merely what the text says, but which contract was being evaluated. At this boundary, the requested device-installation function is no longer supported as an active operation in the current SetupAPI model.
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. Obsolete is not transient and should not be handled by retrying the same DIF request. Compare lifecycle, identity, caller, and first API.
Evidence worth preserving
| Capture | Why it matters |
|---|---|
| DIF code, caller module, Windows build, and target device class | Creates a stable before/after control. |
| Class-installer documentation showing the current supported request | Tests whether the first boundary moves. |
| Whether the caller is an old co-installer or compatibility shim | Pins evidence to one attempt. |
| SetupAPI. Dev. Log showing dispatch and the component that issued the obsolete request | Separates contract failure from environment. |
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
- Replace the DIF call with the documented SetupDi/CfgMgr32 operation in a test build; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Run the legacy caller on the oldest supported and current Windows versions; keep every other input fixed and record the first event that differs from the failing run.
- Verify that omitting the obsolete callback does not remove required device state; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
Do not use repeated retries as the primary test. In this case, a successful later attempt may reflect a new object, refreshed policy, restarted service, different token, or completed background transition, so record exactly what changed between attempts.
How to read the outcome
The following decision points keep the investigation tied to the returning operation:
| 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 | The failure moved to another boundary; 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: Move the caller to supported device-installation APIs and update the package’s minimum/maximum platform declarations. Preserve the pre-change configuration or trace.
Close the incident only when install, update, property change, and removal paths complete without the obsolete request on every supported Windows build. Repeat under the original identity and state. A different environment is comparison, not proof.
Technical references
The following documentation is most relevant when checking the code against the actual Windows contract for obsolete DIF request:
- 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.