| Previous | Next |
| NS_E_WRONG_PUBLISHING_POINT_TYPE | NS_E_INVALID_PLUGIN_LOAD_TYPE_CONFIGURATION |
NS_E_UNSUPPORTED_LOAD_TYPE
Diagnosing NS_E_UNSUPPORTED_LOAD_TYPE in Windows Media Services
Mechanism and scope
NS_E_UNSUPPORTED_LOAD_TYPE (0xC00D1453) marks a plug-in does not implement the requested in-process or out-of-process activation mode. For NS_E_UNSUPPORTED_LOAD_TYPE, the code identifies a narrow server contract, so diagnosis should preserve the object generation and the first native return.
For NS_E_UNSUPPORTED_LOAD_TYPE, publishing points are stateful server objects with a type, path, name, plug-in collections and start/stop lifecycle. When NS_E_UNSUPPORTED_LOAD_TYPE is returned, broadcast, on-demand, cache/proxy and push points do not expose identical methods or valid transitions. In a NS_E_UNSUPPORTED_LOAD_TYPE trace, read the point type and status from the live server object model. While diagnosing NS_E_UNSUPPORTED_LOAD_TYPE, a name in an old MMC view or retained COM interface can describe an earlier generation. For NS_E_UNSUPPORTED_LOAD_TYPE, the decisive question is whether the live object and values match that boundary; the base AllStat description alone does not reveal the object generation, selected plug-in or lower-level failure.
Code-specific failure anatomy
In a representative NS_E_UNSUPPORTED_LOAD_TYPE incident, the server reaches a plug-in does not implement the requested in-process or out-of-process activation mode and rejects the operation before the caller can safely assume the next stage occurred. The incident record should therefore join requested load type, plug-in registration flags, COM server model, architecture and default load policy with the object generation and the exact administrative or protocol request.
A useful negative control is select a load type advertised by the plug-in or install a build registered for the required model. If that change advances the same NS_E_UNSUPPORTED_LOAD_TYPE call, the result supports this boundary. If NS_E_UNSUPPORTED_LOAD_TYPE remains, return to the first lower-level event instead of broadening the repair.
The tempting but misleading response is repeatedly restarting WMServer; capability metadata does not change. That action does not test the distinction that matters here: invalid load-type configuration means the plug-in advertises no usable mode at all. For NS_E_UNSUPPORTED_LOAD_TYPE, this distinction is also why monitoring should retain the symbolic name instead of storing only a generic COM failure.
Build a reproducible incident record
| Evidence | Why it matters for NS_E_UNSUPPORTED_LOAD_TYPE |
|---|---|
| Decisive state | requested load type, plug-in registration flags, COM server model, architecture and default load policy. |
| Owning object | Record the server, publishing point, playlist, namespace node, plug-in or cache item that returned NS_E_UNSUPPORTED_LOAD_TYPE, including its creation or restart time. |
| First lower-level result | Preserve the earliest Win32, socket, COM, parser or plug-in event before the HRESULT; later wrappers can map several causes to NS_E_UNSUPPORTED_LOAD_TYPE. |
| Controlled comparison | Use a known-good object of the same type and vary only the precondition described as “a plug-in does not implement the requested in-process or out-of-process activation mode”. |
| Security-sensitive data | For NS_E_UNSUPPORTED_LOAD_TYPE, log identifiers, lengths, hashes and redacted URLs where possible; do not publish passwords, authorization files or unrestricted client data. |
A controlled correction
- Capture
0xC00D1453,NS_E_UNSUPPORTED_LOAD_TYPE, the exact API/administrative action and the first failure timestamp. - Preserve requested load type, plug-in registration flags, COM server model, architecture and default load policy.
- For
NS_E_UNSUPPORTED_LOAD_TYPE, confirm that the object still belongs to the current WMServer, publishing-point or presentation generation. - Perform one isolated experiment: select a load type advertised by the plug-in or install a build registered for the required model.
- Repeat the original
NS_E_UNSUPPORTED_LOAD_TYPEoperation through the same protocol and service account; do not substitute a different client-side test. - After
NS_E_UNSUPPORTED_LOAD_TYPE, verify the expected next state and retain any later HRESULT as a separate pipeline result.
For NS_E_UNSUPPORTED_LOAD_TYPE, repeat the test with a newly resolved server object; a stale COM pointer can make a correct configuration appear unchanged.
Do not merge nearby HRESULT values
Primary distinction: invalid load-type configuration means the plug-in advertises no usable mode at all.
| Nearby result | Different checkpoint |
|---|---|
NS_E_INVALID_PLUGIN_LOAD_TYPE_CONFIGURATION | Compare its own symbolic boundary and the first failing call; it must not be grouped automatically with NS_E_UNSUPPORTED_LOAD_TYPE. |
NS_E_WRONG_PUBLISHING_POINT_TYPE | Relative to NS_E_UNSUPPORTED_LOAD_TYPE, this neighboring result belongs to another state or validation branch even when the user-visible symptom is similar. |
NS_E_INVALID_PUBLISHING_POINT_NAME | For NS_E_UNSUPPORTED_LOAD_TYPE, use the object type and operation sequence to determine which result is authoritative. |
Interpret the retest
| Retest observation | Interpretation |
|---|---|
The same call still returns NS_E_UNSUPPORTED_LOAD_TYPE | For NS_E_UNSUPPORTED_LOAD_TYPE, the rejected precondition has not changed, or the caller is still using an old object/configuration generation. |
| The operation advances and a later code appears | The NS_E_UNSUPPORTED_LOAD_TYPE boundary was cleared. After NS_E_UNSUPPORTED_LOAD_TYPE, diagnose the new code at its own source, parser, sink, network or client stage. |
| A new object succeeds while the retained object fails | For NS_E_UNSUPPORTED_LOAD_TYPE, object lifetime or stale context is part of the incident; update lifecycle handling rather than applying a machine-wide repair. |
| Only one publishing point, playlist, cache key or plug-in fails | For NS_E_UNSUPPORTED_LOAD_TYPE, the evidence favors object-specific configuration or content over a server-wide outage. |
Changes that do not establish the cause
- repeatedly restarting WMServer; capability metadata does not change.
- For
NS_E_UNSUPPORTED_LOAD_TYPE, a successful ping or local file open is not sufficient proof: the failing service account and Windows Media Services object must perform the same operation. - Do not suppress
NS_E_UNSUPPORTED_LOAD_TYPEor replace it with a generic “media server error”; retain the symbolic code and owning operation in telemetry.
Technical references
- Expanded Use of Publishing Points
- Expanded Use of Plug-ins
- WMS Multicast Data Writer Plug-in Properties
- Microsoft HRESULT registry
Close the incident only after NS_E_UNSUPPORTED_LOAD_TYPE clears on a current object.
Looking for a different code? Search another status or error code.