| Previous | Next |
| NS_E_VIDEODEVICE_BUSY | NS_E_INVALIDCALL_WHILE_ENCODER_RUNNING |
NS_E_VIDEODEVICE_UNEXPECTED
The failing boundary in the Encoder object model
The useful reading of NS_E_VIDEODEVICE_UNEXPECTED (0xC00D1B65) is not merely the standard message shown above. It locates video device initialization after enumeration where the driver returns an unclassified failure inside video capture and compressor negotiation.
A live video source passes through device opening, capture-format negotiation, optional clipping and preview-window setup before an encoder codec accepts the frames in a session that returns this result. Width, height, pixel format and driver state belong to this boundary.
Evidence that separates this code from a wrapper error
Seeing a device in enumeration or obtaining a preview frame does not establish that the requested capture format can be delivered continuously to the encoder in a session that returns this result. For example, a capture driver crashes its filter initialization without reporting a format-specific error. Preserve the result distinction before a UI layer converts the result into a broad start, capture or profile failure.
| Field | What to preserve |
|---|---|
| Decisive values | device instance, driver version, requested media type, graph-build log and first driver HRESULT |
| Producing object | device moniker, driver version, requested and native width/height, frame rate, BITMAPINFOHEADER compression and bit depth, preview state, source-plug-in result and first driver error |
| Session correlation | the same source-group generation, audience index, object identity and callback sequence that produced this result |
| Lower-level evidence | the first COM, driver, file-system or codec HRESULT observed before the Encoder mapped the condition to this result |
| Controlled comparison | a known-good session that changes only the setting named in the videodevice unexpected boundary |
Interpret the next measurement
| Observation | How to interpret it |
|---|---|
| Observation that supports it | The decisive evidence is device instance, driver version, requested media type, graph-build log and first driver HRESULT. It confirms video device initialization after enumeration where the driver returns an unclassified failure in the same object generation. |
| Observation that points to an earlier failure | The recorded values satisfy the videodevice unexpected rule, but a source, driver, COM activation or file operation returns a different HRESULT first. |
| Observation that points to a later failure | The Encoder passes this boundary (video device initialization after enumeration where the driver returns an unclassified failure), but a codec, archive or broadcast sink then fails in a subsequent stage. |
| Verification after correction | Apply this isolated change: test a native format in a fresh process and repair or replace the driver only if the same lower-level fault repeats. The original videodevice unexpected call should then advance past the same checkpoint. |
The operational impact of it is limited to the video capture and compressor negotiation transition that owns video device initialization after enumeration where the driver returns an unclassified failure. In the representative case where a capture driver crashes its filter initialization without reporting a format-specific error, keep the first failing call and its object identity so a later wrapper cannot replace the videodevice unexpected evidence.
Test the condition without rewriting the session
- Record
0xC00D1B65, it, the Encoder version and the exact API call or property access that returned it. - Export the current
.wmeor.prxconfiguration, then capture device instance, driver version, requested media type, graph-build log and first driver HRESULT. - verify the video capture and compressor negotiation precondition without changing the source, profile and output sink at the same time.
- Run one controlled comparison in which only this condition changes: test a native format in a fresh process and repair or replace the driver only if the same lower-level fault repeats.
- After the change, recreate the affected Encoder object rather than assuming the existing graph discarded its earlier videodevice unexpected state.
Interpret neighboring results carefully
| Result | Why it is a different boundary |
|---|---|
NS_E_VIDEODEVICE_BUSY | exclusive opening of the selected video capture device or capture pin |
NS_E_VIDEODRIVER_UNSTABLE | driver state after an unrecoverable capture failure makes further graph use unsafe |
NS_E_VIDCAPSTARTFAILED | transition of the configured video capture graph into streaming state |
Resolution and verification
The direct repair for this occurrence is to test a native format in a fresh process and repair or replace the driver only if the same lower-level fault repeats. Recreate the affected source group, profile or output object, repeat the same operation, and confirm that the first failing HRESULT no longer comes from the videodevice unexpected checkpoint.
Do not keep retrying an unstable capture driver in the same process after preserving the first error; close the graph and test one known-native format in a fresh process in a session that returns it.
References for the boundary
- IWMEncVideoSource2.Width and live capture sizing.
- BITMAPINFOHEADER structure.
- ICCompressQuery video-compressor format check.
- Retrieving the configured encoder input.
Looking for a different code? Search another status or error code.