| Previous | Next |
| NS_E_INTERLACE_REQUIRE_SAMESIZE | NS_E_NO_MULTIPASS_FOR_LIVEDEVICE |
NS_E_TOO_MANY_DEVICECONTROL
How to interpret the code in a real encoding session
0xC00D1B96 is named NS_E_TOO_MANY_DEVICECONTROL. Its practical scope is more than one control plug-in attempts to own the same encoding device, which belongs to tape-device control and edit decision lists rather than to every part of Windows Media playback or Windows itself.
Mechanism and point of failure
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 this result. The capture device and the control device must refer to the same usable hardware path.
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 this result. A typical reproduction is: configuration import adds a second device-control plug-in without removing the first. This makes the first result from the Encoder more valuable than a later generic message.
Reproduction matrix
| Field | What to preserve |
|---|---|
| Decisive values | control plug-in count, CLSIDs, source-group bindings and device identifiers |
| 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 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 too many devicecontrol boundary |
Evidence matrix
| Observation | How to interpret it |
|---|---|
| Observation that supports it | The decisive evidence is control plug-in count, CLSIDs, source-group bindings and device identifiers. It confirms more than one control plug-in attempts to own the same encoding device in the same object generation. |
| Observation that points to an earlier failure | The recorded values satisfy the too many devicecontrol 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 (more than one control plug-in attempts to own the same encoding device), but a codec, archive or broadcast sink then fails in a subsequent stage. |
| Verification after correction | Apply this isolated change: retain a single control owner for the device. The original too many devicecontrol call should then advance past the same checkpoint. |
The operational impact of it is limited to the tape-device control and edit decision lists transition that owns more than one control plug-in attempts to own the same encoding device. In the representative case where configuration import adds a second device-control plug-in without removing the first, keep the first failing call and its object identity so a later wrapper cannot replace the too many devicecontrol evidence.
Minimal experiment
- Record
0xC00D1B96, it, the Encoder version and the exact API call or property access that returned it. - Export the current
.wmeor.prxconfiguration, then capture control plug-in count, CLSIDs, source-group bindings and device identifiers. - 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: retain a single control owner for the device.
- After the change, recreate the affected Encoder object rather than assuming the existing graph discarded its earlier too many devicecontrol state.
Do not collapse these results together
| 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_ACTIVE_SG_DEVICE_CONTROL_DISCONNECTED | the control device for the active source group disconnects while capture is active |
NS_E_INVALID_DEVICE | selected hardware lacks the tape-transport control capabilities required by the control plug-in |
What to change—and what to leave alone
Change the smallest responsible precondition: retain a single control owner for the device. While retesting it, keep all unrelated source, audience and output values fixed until the same call is repeated.
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 it.
Authoritative documentation
- 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.