NS_E_INVALIDCALL_WHILE_ENCODER_STOPPED (0XC00D1B7F) Fix

Yeah, this one's annoying. You're working with Windows Media Encoder or something built on top of it, and boom — NS_E_INVALIDCALL_WHILE_ENCODER_STOPPED (0XC00D1B7F). It means you tried to call a method that only works when the encoder is actively encoding, but it's stopped. Let's fix it.

The Quick Fix: Restart the Encoding Session

The most common fix is to restart the encoding session before you make that call. If you're using the Windows Media Encoder API directly, do this:

1. Stop the encoder if it's running — encoder.Stop().
2. Call encoder.Start() again.
3. Now do your operation (like PrepareToEncode or setting a new profile).

If you're coding in C# or C++, here's the pattern:

if (encoder.State == WMEncoderState.WMEncoderState_Stopped)
{
    encoder.Start();
}
// Now safe to call PrepareToEncode, SetProfile, etc.

That's it. 90% of the time, the issue is you're calling PrepareToEncode or SetProfile after a stop without restarting. The encoder's state machine is strict — it expects a start before those calls.

Why This Happens

The encoder has a simple state machine: stopped, starting, encoding, paused, stopping. Certain operations are only valid during the encoding state. NS_E_INVALIDCALL_WHILE_ENCODER_STOPPED fires when you try something like GetOutput or PrepareToEncode while in the stopped state. It's not a bug — it's by design. The encoder needs to be actively processing to prepare outputs or modify profiles.

If you're using Windows Media Encoder 9 (WME9) for screen capture or live streaming, this usually pops up when your automation script calls Stop(), then immediately tries to change the profile or output path. The encoder doesn't queue those changes — it rejects them.

Less Common Variations and Edge Cases

1. The Start() Call Fails Silently

Sometimes Start() returns success but the encoder doesn't actually transition to encoding. This happens if the source device (like a webcam or capture card) is disconnected. Check the encoder's state after start — if it's still stopped, the source is gone.

encoder.Start();
if (encoder.State != WMEncoderState.WMEncoderState_Encoding)
{
    // Source not available — handle it
}

2. Calling PrepareToEncode Before Start

Some people call PrepareToEncode before Start, which is wrong. The order should always be: set profile, call PrepareToEncode, then Start. If you Stop and then PrepareToEncode again without Start, you get the error.

3. Double Events or Async Timing

If you're handling the encoder's OnStateChange event and you trigger an operation in that handler, be careful. The handler fires in the stopped state before the encoder fully transitions. A delay of 100-200ms after Stop before you do anything else clears this up.

encoder.Stop();
await Task.Delay(200);
// Now safe to call PrepareToEncode

4. Using Media Foundation Instead of WME

If you've moved to Media Foundation, the error is rarer but still possible. It maps to MF_E_INVALIDREQUEST. Same fix — restart the session by calling IMFMediaSession::Start again.

Prevention: Don't Let the Encoder Get Stuck

To avoid hitting this in the future, follow these rules:

• Always check the encoder state before calling any method that modifies encoding. Use encoder.State or the equivalent in your API.
• Implement a state machine in your app. Don't call PrepareToEncode unless the encoder is in the encoding state.
• Add a small delay after Stop if you plan to restart. 200ms is safe.
• Test with a dummy source — a static file instead of a live device — to rule out hardware issues.
• Log every state change. When this error hits, your logs will show the sequence that led to it.

That's it. Restart the encoder, check your timing, and this error disappears. I've seen it on everything from Windows XP to Server 2019 with WME9. The fix hasn't changed in 20 years.