| Previous | Next |
| WINML_ERR_INVALID_DEVICE | WINML_ERR_VALUE_NOTFOUND |
WINML_ERR_INVALID_BINDING
The actionable meaning of Windows ML binding that does not match the model contract comes from the component that returned it. LearningModelBinding is incomplete or contains values whose feature kinds, names, or mutability do not match the model input/output descriptors.
Where the result is produced
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.
A valid feature name with the wrong size is a size mismatch; an unknown name is value-not-found. Invalid binding is the broader contract failure. Keep the numeric value, declared return type, and first returning operation together with This result; the same integer can belong to a different status namespace in another API.
Evidence to preserve
| Capture | Diagnostic value |
|---|---|
| Model input/output descriptors, bound names, feature classes, data types, shapes, and binding order. | Identifies the concrete object and operation associated with Windows ML binding that does not match the model contract. |
| Whether each required input and output is present exactly once and optional dimensions are resolved. | 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. |
For This result preserve known-good model and input produced by the same export toolchain while evaluating this condition before reinstalling, rebooting, clearing state, or substituting another device or provider. A success observed only after such a change is useful comparison data for It but it does not identify the original cause.
A controlled diagnostic sequence
- Enumerate model descriptors and bind a minimal known tensor for each required input. Repeat the original supported operation so the check remains tied to the same API boundary.
- Remove one suspect binding while keeping the device and model session fixed. Keep unrelated inputs fixed so the changed result remains attributable to the tested variable.
- Run one evaluation with deterministic input and capture the descriptor-to-buffer mapping. Record the first returned status and any state transition observed.
How nearby outcomes differ
| Observed comparison | Next conclusion to test |
|---|---|
| The first control changes the result | Concentrate on the variable isolated by this check: Enumerate model descriptors and bind a minimal known tensor for each required input. |
| The second comparison reproduces the same first status | Preserve lower-layer provider, driver, service, or runtime evidence before editing application data. The second controlled check was: Remove one suspect binding while keeping the device and model session fixed. |
| A different status appears after the bounded change | The 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. |
Correction and proof
Targeted correction. Construct bindings from the loaded model descriptors and keep preprocessing/output allocation consistent with those descriptors. For This result modify only the object, argument, policy, provider, or lifecycle state identified by the collected evidence.
Acceptance criterion. Every required feature binds once and evaluation reaches execution without binding-related HRESULTs. Re-run the original operation that produced This result under its original identity and supported configuration, then keep one negative control that still produces the expected neighboring outcome.
Technical references
References for This result on the deployed platform version.
- Microsoft Open Specifications: HRESULT values — defines the status namespace used.
- Microsoft: HRESULT facility extraction — documents the API or lifecycle boundary behind this condition.
- Microsoft: Windows ML desktop workflow — provides ABI, implementation, or protocol context.
- Microsoft: LearningModelBinding — supports the portability and verification limits.
Looking for a different code? Search another status or error code.