| Previous | Next |
| MF_E_UNSUPPORTED_SERVICE | MF_E_INVALIDNAME |
MF_E_UNEXPECTED
What the code tells you
MF_E_UNEXPECTED (0xC00D36BB) is a failure result from Windows Media Foundation. The generated section above already contains the platform message; the useful extra information is that this result isolates the called Media Foundation component reached an internal branch that its public state machine did not expect.
The producer is the first Media Foundation object that returned the HRESULT, so diagnosis should begin with that object and its state rather than with a broad reinstall or an unrelated codec change. A representative occurrence is a third-party MFT accepts configuration but fails when streaming starts and its wrapper returns this generic result.
Read the call sequence as a timeline. First, the application reaches the first Media Foundation object that returned the HRESULT. Next, the component evaluates the called Media Foundation component reached an internal branch that its public state machine did not expect. Only after the checkpoint can a wrapper, user interface, or fallback path emit a less specific message.
Build a useful incident record
- Exact request: method name, all identifiers, units, flags, stream number, requested action, and this result.
- Object state: the exact method, object identity, prior asynchronous event, current media type, and the first lower-level HRESULT in the same operation.
- Correlation for it: callback cookie, object generation, URL or file identity, device identity, and timestamps from the same attempt.
- Underlying cause: the first Win32, COM, network, driver, policy, or component error reported before
0xC00D36BB.
Reproduce without erasing context
Use one controlled experiment: recreate only the failing source, transform, session, or sink and replay the same minimal sequence. A useful this result comparison changes exactly that variable; changing content, account, proxy, device, components, and version together makes attribution impossible.
| Outcome | Interpretation |
|---|---|
| The same checkpoint now succeeds | The changed condition belongs to the producing boundary for it. |
| A more specific earlier HRESULT appears | Preserve it; this result was probably a wrapper or terminal state. |
| The operation advances and fails later | The condition is fixed even though the complete workflow still has another defect. |
| No behavior changes | Restore the result baseline and test another documented prerequisite instead of stacking workarounds. |
Comparison with adjacent conditions
| Related code | Why it is not interchangeable |
|---|---|
MF_E_INVALIDNAME | Invalid name; compare this boundary specifically with it. |
MF_E_INVALIDTYPE | Invalid type; compare this boundary specifically with it. |
MF_E_INVALIDINDEX | Invalid index; compare this boundary specifically with it. |
The important distinction is this: invalid input is normally reported by a more specific name, type, index, or state code. Searching only for the visible English message collapses different states; the constant and 0xC00D36BB retain the boundary.
Resolution and proof
Apply the narrow remedy: preserve the first failure, validate call ordering, and update or replace the component that produces the unexpected branch. Then discard stale media objects, pending callbacks, cached provider sessions, or installer state as appropriate and rerun the exact request that originally returned it.
A confirmed it repair produces the requested stream, attribute, state transition, license decision, store callback, or setup result. Suppressing it, broadly enabling legacy controls, or falling back to unrelated content is not proof of repair.
References
- Media Foundation architecture — reference used for the checkpoint.
- Media Foundation error codes — reference used for the checkpoint.
- Media sources — reference used for the checkpoint.
- Media Foundation events — reference used for the checkpoint.
Looking for a different code? Search another status or error code.