What does HRESULT 0x80040271 (VFW_E_OUT_OF_VIDEO_MEMORY) mean?

Status / error code:

Category:

Constant name:

Source:

Facility:

Operating System:

Description:

There is not enough Video Memory at this display resolution and number of colors. Reducing.

Previous	Next
VFW_E_BAD_VIDEOCD	VFW_E_VP_NEGOTIATION_FAILED

VFW_E_OUT_OF_VIDEO_MEMORY

Exact result and bit fields

VFW_E_OUT_OF_VIDEO_MEMORY has the unsigned HRESULT value 2147746417 (0x80040271) and the signed 32-bit representation -2147220879. AllStat describes it as “There is not enough Video Memory at this display resolution and number of colors. Reducing resolution might help”. In the operation that produces this result, a renderer cannot allocate enough video memory for the selected resolution, pixel format, surfaces and display mode.

The high bit is set, so this value is a failure HRESULT. Its facility field is 4 (FACILITY_ITF) and its low code is 625 (0x0271). These fields classify this result, but they do not identify which filter, thread, device, file or graph generation returned it.

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 it 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 it: the graph requests too many or oversized surfaces.
Cause 2 for it: display resolution and color depth consume available VRAM.
Cause 3 for it: another graphics workload holds scarce legacy DirectDraw resources.

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 it: renderer type, surface dimensions and pixel format.
Evidence 2 for it: requested surface count and allocation failure.
Evidence 3 for it: display mode, adapter identity and concurrent graphics load.

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: a renderer cannot allocate enough video memory for the selected resolution, pixel format, surfaces and display mode.
compare the live object state, topology and input with the documented interface preconditions.
Before changing filters, drivers, registry data or media for it, 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 it: reduce surface count, resolution or color depth.
Action 2 for it: release stale renderer and DirectDraw resources before rebuilding.
Action 3 for it: select a renderer with a compatible memory model on modern systems.

Retry and recovery

Retry rule for it: Retry after video-memory demand falls or the renderer is recreated; immediate unchanged allocation loops can worsen resource pressure. 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.

Example incident

A legacy overlay graph succeeds at 1024×768 but fails after switching to a high-resolution desktop with multiple buffers; reducing the surface requirement removes it. This example keeps the diagnosis at the specific the boundary instead of treating every DirectShow failure as a codec reinstall problem.

How it differs from nearby results

E_OUTOFMEMORY can describe system memory generally; it specifically identifies graphics-surface allocation capacity. Keep those cases separate in telemetry, UI messages and retry policy because their next actions are different.

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 it should favor supported component installation, device configuration and documented DirectShow calls. Manual registry or driver changes are appropriate only when the collected evidence for it points to that layer and a rollback is available.

Official Microsoft references

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