What does HRESULT 0x88900001 (WINML_ERR_INVALID_DEVICE) mean?

 
Previous Next
D3D12_ERROR_DRIVER_VERSION_MISMATCH WINML_ERR_INVALID_BINDING

WINML_ERR_INVALID_DEVICE

Investigate invalid Windows ML execution device at the first returning call, before a wrapper substitutes a generic message. The LearningModelSession could not use the requested device because the device object is invalid for the model or lacks required execution support.

Read the status in context

Windows ML separates model loading, session creation, feature binding, and evaluation. The phase returning the HRESULT decides whether metadata, tensors, device selection, or execution is the useful boundary.

Device selection failure occurs before feature binding; changing tensor names cannot repair it. Keep the numeric value, declared return type, and first returning operation together with WINML_ERR_INVALID_DEVICE; the same integer can belong to a different status namespace in another API.

Diagnostic facts

CaptureDiagnostic value
Device kind/adapter, session creation API, model operators, execution provider, and Windows build.Identifies the concrete object and operation associated with invalid Windows ML execution device.
DirectX adapter feature level, driver version, memory budget, and whether CPU fallback is allowed.Separates argument or lifecycle state from a lower-layer provider failure.
First WinML/DirectML diagnostic event and the operation phase: load, session, bind, or evaluate.Creates a stable before-and-after comparison.
Known-good model and input produced by the same export toolchain.Shows whether this condition is the first result or a translated summary.

Preserve device kind/adapter, session creation API, model operators, execution provider, and Windows build before reinstalling, rebooting, clearing state, or substituting another device or provider. A success observed only after such a change is useful comparison data, but it does not identify the original cause.

Verification path

  1. Create a CPU session with the identical model. Keep unrelated inputs fixed so the changed result remains attributable to the tested variable.
  2. Enumerate adapters and create a fresh LearningModelDevice instead of reusing a stale object. Record the first returned status and any state transition observed.
  3. Run one evaluation with deterministic input and capture the descriptor-to-buffer mapping. Treat a changed result as a new boundary rather than automatic resolution.

What the result does not prove

Observed comparisonNext conclusion to test
The first control changes the resultConcentrate on the variable isolated by this check: Create a CPU session with the identical model.
The second comparison reproduces the same first statusPreserve lower-layer provider, driver, service, or runtime evidence before editing application data. The second controlled check was: Enumerate adapters and create a fresh LearningModelDevice instead of reusing a stale object.
A different status appears after the bounded changeThe operation moved to another boundary after the third controlled check. That check was: Run one evaluation with deterministic input and capture the descriptor-to-buffer mapping. Retain both results and interpret the replacement through its own API contract.

Closing the incident

Targeted correction. Select a supported device or CPU fallback and recreate the session after device loss or driver reset. Modify only the object, argument, policy, provider, or lifecycle state identified by the collected evidence.

Acceptance criterion. The same model creates a session repeatedly on the chosen device and fallback behavior is explicit. Re-run the original operation that produced this condition under its original identity and supported configuration, then keep one negative control that still produces the expected neighboring outcome.

Technical references

References for WINML_ERR_INVALID_DEVICE on the deployed platform version.


Looking for a different code? Search another status or error code.