| Previous | Next |
| D2DERR_BITMAP_BOUND_AS_TARGET | D2DERR_INTERMEDIATE_TOO_LARGE |
D2DERR_INSUFFICIENT_DEVICE_CAPABILITIES
The scope of D2DERR_INSUFFICIENT_DEVICE_CAPABILITIES is Direct2D targets, device capabilities, and intermediates. The Direct3D device backing Direct2D lacks a capability required by the requested operation. Keep 0x88990026 beside the returning method because a wrapper can replace this distinction with a generic subsystem message.
Subsystem boundary
When it is returned, a device context has target identity and is backed by a Direct3D device with format, feature, shader, and maximum-size limits. Temporarily changing targets, requesting unsupported capabilities, or propagating huge effect bounds are different problems. Record target history and capability queries before allocating or drawing.
Inspect the following boundary: feature level, format support, shader model, effects, and device creation flags.
Do not hide the original condition
UNSUPPORTED_VERSION concerns the Direct2D API contract; this code concerns the backing device’s capabilities. Do not respond with a universal render-target recreation loop unless the returned status specifically documents device-loss recovery; graph, property, numeric, lifetime, and print-state errors require correcting their contract.
Facts worth preserving
| Record | Why it matters here |
|---|---|
| Adapter, feature level, WARP or hardware mode | Preserving adapter, feature level, WARP or hardware mode provides the evidence needed to test this distinction: uNSUPPORTED_VERSION concerns the Direct2D API contract; this code concerns the backing device’s capabilities. |
| Required formats and D3D support flags | Recording required formats and D3D support flags separates the Direct2D targets, device capabilities, and intermediates boundary from a later wrapper symptom. |
| Effect or operation requesting the capability | In this result diagnostics, recording effect or operation requesting the capability ties the HRESULT to the Direct2D targets, device capabilities, and intermediates boundary rather than to the final visible failure. |
| Device creation and capability-query results | Comparing device creation and capability-query results shows whether this result follows input, object state, or environment. |
Isolation procedure
Use the original target and a small supported bitmap or effect region first., then change one target, capability, format, or spatial expansion at a time while logging device and context generations.
- When it is returned, query support before constructing resources.
- Test WARP software rendering.
- use a simpler effect or supported format.
- When it is returned, compare another adapter without changing application logic.
What each result would imply
| Test | Interpretation | Hold constant |
|---|---|---|
| Same environment, reduced input | If this result disappears with a smaller faithful case, complexity within Direct2D targets, device capabilities, and intermediates is implicated. | Keep adapter, feature level, WARP or hardware mode fixed while simplifying effect or operation requesting the capability. |
| Same input, fresh object generation | If this result changes after rebuilding state, examine ownership across the caller’s object graph, custom effect or renderer, Direct2D validation layer, backing device, and deferred draw boundary. | Place required formats and D3D support flags on the timeline of the last successful transition. |
| Same operation on a controlled second path | If this result follows one environment, the failure is not explained by source data alone. | Compare adapter and feature level, factory and device generations, target identity, debug-layer output, and thread ownership while preserving device creation and capability-query results. |
Verification after repair
A correction for it should let the operation at the Direct2D targets, device capabilities, and intermediates boundary complete repeatedly under the original supported conditions. Repeat the control that begins with “Query support before constructing resources” and confirm that the following lifecycle step also succeeds. Keep the original failing sample and one deliberate negative case so fallback cannot be mistaken for repair.
Technical references
When it is returned, these references define the public API family, object model, or error list used to interpret this status.
- Microsoft: Direct2D error codes.
- Microsoft: Direct2D devices and device contexts.
- Microsoft: Direct2D custom effects.
- Microsoft: Direct2D API overview.
Looking for a different code? Search another status or error code.