| Previous | Next |
| VFW_E_VMR_NOT_IN_MIXER_MODE | VFW_E_VMR_NO_DEINTERLACE_HW |
VFW_E_VMR_NO_AP_SUPPLIED
Exact result and bit fields
VFW_E_VMR_NO_AP_SUPPLIED has the unsigned HRESULT value 2147746455 (0x80040297) and the signed 32-bit representation -2147220841. AllStat describes it as “The application has not yet provided the VMR filter with a valid allocator-presenter object”. In the operation that produces this result, the VMR is used in renderless mode before the application supplies a valid allocator-presenter object.
The high bit is set, so this value is a failure HRESULT. Its facility field is 4 (FACILITY_ITF) and its low code is 663 (0x0297). These fields classify this result, but they do not identify which filter, thread, device, file or graph generation returned it.
Evidence worth preserving
Log the interface and method, filter CLSID and friendly name, process and thread, graph state, connected pin names, media-type summary, renderer or device identity where relevant, and the first preceding HRESULT. Record lengths and hashes instead of raw content when the incident includes display identifiers, protected-content state, driver details and media paths.
- Evidence 1 for this HRESULT: VMR mode and renderer version.
- Evidence 2 for this HRESULT: allocator-presenter object identity and lifetime.
- Evidence 3 for this HRESULT: AdviseSurfaceAllocator or notification-interface result.
Contract boundary
This result is tied to a legacy rendering or graphics-capability boundary. The result should be diagnosed from the selected renderer, adapter, driver, surface contract and graph topology rather than from the file extension alone.
The practical owner to locate for this HRESULT is the renderer, graphics driver, display connection and negotiated surfaces. When handling this result, capture the native result before a wrapper replaces it with a generic exception, and keep the graph generation or object identity with the record.
Conditions that can produce it
- Cause 1 for this HRESULT: renderless mode was selected without AdviseSurfaceAllocator.
- Cause 2 for this HRESULT: the allocator-presenter object was released too early.
- Cause 3 for this HRESULT: the presenter implements the wrong VMR interface generation.
Step-by-step diagnosis
- Capture it at the first native return, not only at the top-level playback failure.
- identify the exact graph stage described here: the VMR is used in renderless mode before the application supplies a valid allocator-presenter object.
- compare the live object state, topology and input with the documented interface preconditions.
- Before changing filters, drivers, registry data or media for this HRESULT, collect the code-specific evidence below.
- Test one evidence-backed the correction on the smallest reproducible graph.
- Verify that the corrected run no longer returns it and does not merely replace it with a nearby HRESULT.
Correction strategy
- Action 1 for this HRESULT: create and register the correct allocator-presenter before connection.
- Action 2 for this HRESULT: hold it for the renderer lifetime.
- Action 3 for this HRESULT: match VMR-7 and VMR-9 interface families exactly.
Example incident
A VMR-9 is switched to renderless mode but the application passes a VMR-7 allocator interface; using the matching VMR-9 presenter resolves it. This example keeps the diagnosis at the specific the boundary instead of treating every DirectShow failure as a codec reinstall problem.
Implementation notes
Code that handles it should preserve the original HRESULT, the failed stage and an opaque correlation identifier. After it, do not infer success from partial graph construction, and do not continue using interfaces retained from a graph or device generation that has already changed.
Operational remediation for this HRESULT should favor supported component installation, device configuration and documented DirectShow calls. Manual registry or driver changes are appropriate only when the collected evidence for this HRESULT points to that layer and a rollback is available.
Retry and recovery
Retry rule for this HRESULT: Retry after a valid allocator-presenter is registered and the renderless graph is rebuilt if connection already failed. A safe it retry must use a changed capability, state, object generation or input. While recovering from it, preserve cancellation and avoid replaying side effects when the original operation may have partially completed.
How it differs from nearby results
VFW_E_VMR_NOT_IN_MIXER_MODE concerns multi-stream composition; it concerns the application-owned presentation path required by renderless mode. Keep those cases separate in telemetry, UI messages and retry policy because their next actions are different.
Official Microsoft references
- Microsoft: DirectShow error and success codes
- Microsoft: Video Mixing Renderer 9
- Microsoft: DirectShow interface reference
Looking for a different code? Search another status or error code.
