| Previous | Next |
| NS_E_DUPLICATE_DRMPROFILE | NS_E_SPEECHEDL_ON_NON_MIXEDMODE |
NS_E_INVALID_DEVICE
Where the Encoder produces this result
0xC00D1B91 (NS_E_INVALID_DEVICE) identifies selected hardware lacks the tape-transport control capabilities required by the control plug-in. For NS_E_INVALID_DEVICE, the important diagnostic boundary is the Encoder object that validates this state; a later “cannot start encoding” dialog can hide that more precise origin.
Windows Media Encoder device control coordinates a capture source with a control plug-in, tape transport, mark-in/mark-out entries and an edit decision list in a session that returns NS_E_INVALID_DEVICE. The capture device and the control device must refer to the same usable hardware path at the invalid device checkpoint.
What has already succeeded
Video capture can remain available while the separate control plug-in loses transport control, so a device-control failure is not automatically a capture-format failure in a session that returns NS_E_INVALID_DEVICE. In a representative invalid device case, a webcam is chosen with a DV tape-control plug-in. The NS_E_INVALID_DEVICE observation should be tested at the producing object instead of being treated as a general codec or operating-system failure.
State snapshot to capture
| Field | What to preserve |
|---|---|
| Decisive values | capture-device identity, control plug-in, supported transport commands and source binding |
| Producing object | control plug-in CLSID, controlled device identifier, transport state, tape presence, EDL entry count, mark-in/mark-out values, seek result, source-group binding and disconnect event |
| Session correlation | the same source-group generation, audience index, object identity and callback sequence that produced NS_E_INVALID_DEVICE |
| Lower-level evidence | the first COM, driver, file-system or codec HRESULT observed before the Encoder mapped the condition to NS_E_INVALID_DEVICE |
| Controlled comparison | a known-good session that changes only the setting named in the invalid device boundary |
How to read the next observation
| Observation | How to interpret it |
|---|---|
| Observation that supports this result | The decisive evidence is capture-device identity, control plug-in, supported transport commands and source binding. It confirms selected hardware lacks the tape-transport control capabilities required by the control plug-in in the same object generation. |
| Observation that points to an earlier failure | The recorded values satisfy the invalid device 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 (selected hardware lacks the tape-transport control capabilities required by the control plug-in), but a codec, archive or broadcast sink then fails in a subsequent stage. |
| Verification after correction | Apply this isolated change: select a controllable tape device or disable device-control operations. The original invalid device call should then advance past the same checkpoint. |
The operational impact of NS_E_INVALID_DEVICE is limited to the tape-device control and edit decision lists transition that owns selected hardware lacks the tape-transport control capabilities required by the control plug-in. For NS_E_INVALID_DEVICE, it does not, by itself, prove that every input is corrupt, every codec is missing or the complete Windows Media installation is unusable. In the representative case where a webcam is chosen with a DV tape-control plug-in, keep the first failing call and its object identity so a later wrapper cannot replace the invalid device evidence.
A controlled diagnostic sequence
- Record
0xC00D1B91,NS_E_INVALID_DEVICE, the Encoder version and the exact API call or property access that returned it. - Export the current
.wmeor.prxconfiguration, then capture capture-device identity, control plug-in, supported transport commands and source binding. - For
NS_E_INVALID_DEVICE, verify the tape-device control and edit decision lists precondition without changing the source, profile and output sink at the same time. - Run one controlled comparison in which only this condition changes: select a controllable tape device or disable device-control operations.
- After the change, recreate the affected Encoder object rather than assuming the existing graph discarded its earlier invalid device state.
Nearby HRESULTs that mean something else
| Result | Why it is a different boundary |
|---|---|
NS_E_DEVCONTROL_FAILED_SEEK | device-control plug-in cannot position tape at the requested EDL mark-in |
NS_E_TOO_MANY_DEVICECONTROL | more than one control plug-in attempts to own the same encoding device |
NS_E_ACTIVE_SG_DEVICE_CONTROL_DISCONNECTED | the control device for the active source group disconnects while capture is active |
Corrective action at the right layer
For NS_E_INVALID_DEVICE, the focused correction is to select a controllable tape device or disable device-control operations. A retry is useful only after the recorded invalid device precondition changes.
Do not rewind, eject or overwrite the tape before recording the failing EDL entry and current timecode; that changes the evidence used to reproduce the seek or end-of-tape condition in a session that returns NS_E_INVALID_DEVICE.
Technical references for NS_E_INVALID_DEVICE
- WMEncEditDecisionList.Item.
- WMTIMECODE device-control structure.
- IWMEncSource.MarkOut.
- Preparing a source group for encoding.
Looking for a different code? Search another status or error code.