| Previous | Next |
| NS_E_AUDIODEVICE_BUSY | NS_E_AUDIODEVICE_BADFORMAT |
NS_E_AUDIODEVICE_UNEXPECTED
Where the Encoder produces this result
0xC00D1B62 (NS_E_AUDIODEVICE_UNEXPECTED) identifies audio capture initialization after device discovery but outside a recognized busy or format rejection. The important diagnostic boundary is the Encoder object that validates this state; a later “cannot start encoding” dialog can hide that more precise origin.
For a live audio input, the source plug-in must open the selected endpoint and negotiate a WAVEFORMATEX-compatible stream before the source group can be prepared in a session that returns this result. Device ownership and format support are independent checks.
What has already succeeded
A device visible in the Encoder UI can still reject the requested format or be exclusively held by another process when the encoding graph is built in a session that returns this result. In a representative audiodevice unexpected case, the endpoint enumerates but the capture driver fails while creating its streaming pin. The result 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 | driver/plug-in HRESULT, device instance ID, WAVEFORMATEX and event sequence leading to open |
| Producing object | device moniker and friendly name, process holding the endpoint, WAVEFORMATEX tag, channel count, samples per second, bits per sample, block alignment and source-plug-in HRESULT |
| 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 audiodevice unexpected boundary |
How to read the next observation
| Observation | How to interpret it |
|---|---|
| Observation that supports it | The decisive evidence is driver/plug-in HRESULT, device instance ID, WAVEFORMATEX and event sequence leading to open. It confirms audio capture initialization after device discovery but outside a recognized busy or format rejection in the same object generation. |
| Observation that points to an earlier failure | The recorded values satisfy the audiodevice 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 (audio capture initialization after device discovery but outside a recognized busy or format rejection), but a codec, archive or broadcast sink then fails in a subsequent stage. |
| Verification after correction | Apply this isolated change: reproduce with the device native format and collect the lower-level driver result before reinstalling anything. The original audiodevice unexpected call should then advance past the same checkpoint. |
The operational impact of it is limited to the audio capture-device negotiation transition that owns audio capture initialization after device discovery but outside a recognized busy or format rejection. In the representative case where the endpoint enumerates but the capture driver fails while creating its streaming pin, keep the first failing call and its object identity so a later wrapper cannot replace the audiodevice unexpected evidence.
A controlled diagnostic sequence
- Record
0xC00D1B62, it, the Encoder version and the exact API call or property access that returned it. - Export the current
.wmeor.prxconfiguration, then capture driver/plug-in HRESULT, device instance ID, WAVEFORMATEX and event sequence leading to open. - verify the audio capture-device negotiation precondition without changing the source, profile and output sink at the same time.
- Run one controlled comparison in which only this condition changes: reproduce with the device native format and collect the lower-level driver result before reinstalling anything.
- After the change, recreate the affected Encoder object rather than assuming the existing graph discarded its earlier audiodevice unexpected state.
Nearby HRESULTs that mean something else
| Result | Why it is a different boundary |
|---|---|
NS_E_AUDIODEVICE_BUSY | exclusive opening of the selected audio capture endpoint |
NS_E_AUDIODEVICE_BADFORMAT | negotiation of the requested WAVEFORMATEX with the audio capture device |
NS_E_NO_AUDIODATA | watchdog detects that an opened audio source has stopped delivering samples |
Corrective action at the right layer
The focused correction is to reproduce with the device native format and collect the lower-level driver result before reinstalling anything. A retry is useful only after the recorded audiodevice unexpected precondition changes.
Do not change the audio driver, sample rate and source plug-in simultaneously; first preserve the exact WAVEFORMATEX and the first open or negotiation HRESULT in a session that returns it.
Technical references
- Retrieving the configured encoder input.
- WAVEFORMATEX structure.
- Preparing a source group for encoding.
- WMEncoder.Start.
Looking for a different code? Search another status or error code.