| Previous | Next |
| NS_E_PLAYLIST_PLUGIN_NOT_FOUND | NS_E_MEDIA_PARSER_INVALID_FORMAT |
NS_E_DATA_SOURCE_ENUMERATION_NOT_SUPPORTED
NS_E_DATA_SOURCE_ENUMERATION_NOT_SUPPORTED: owning object, evidence and recovery
Mechanism and scope
This result (0xC00D1580) marks the selected data source can open content but does not implement directory/container enumeration. The code identifies a narrow server contract, so diagnosis should preserve the object generation and the first native return.
Windows Media Services selects plug-ins by class, registration, enabled state and advertised format or protocol., the server may successfully load one plug-in class while failing to find the data source, parser or script engine required by a particular request. In a this result trace, record the selected plug-in CLSID, class, load type, enabled state and custom error event. While diagnosing it, plug-in discovery and plug-in execution fail differently. 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.
Reading the second result
| Retest observation | Interpretation |
|---|---|
| The same call still returns this result | 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 boundary was cleared. After this result, diagnose the new code at its own source, parser, sink, network or client stage. |
| A new object succeeds while the retained object fails | 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 | The evidence favors object-specific configuration or content over a server-wide outage. |
Code-specific failure anatomy
In a representative incident, the server reaches the selected data source can open content but does not implement directory/container enumeration and rejects the operation before the caller can safely assume the next stage occurred. The incident record should therefore join data-source plug-in identity, URL prefix, requested enumeration method and source object type with the object generation and the exact administrative or protocol request.
A useful negative control is request a concrete object path or use a data source that explicitly supports enumeration. If that change advances the same it call, the result supports this boundary. If it remains, return to the first lower-level event instead of broadening the repair.
The tempting but misleading response is assuming every URL-like source can act as a directory. That action does not test the distinction that matters here: source plug-in not found means no source was selected; here a source exists but lacks one optional capability. 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 it |
|---|---|
| Decisive state | data-source plug-in identity, URL prefix, requested enumeration method and source object type. |
| Owning object | Record the server, publishing point, playlist, namespace node, plug-in or cache item that returned it, 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 it. |
| Controlled comparison | Use a known-good object of the same type and vary only the precondition described as “the selected data source can open content but does not implement directory/container enumeration”. |
| Security-sensitive data | Log identifiers, lengths, hashes and redacted URLs where possible; do not publish passwords, authorization files or unrestricted client data. |
A controlled correction
- Capture
0xC00D1580, it, the exact API/administrative action and the first failure timestamp. - Preserve data-source plug-in identity, URL prefix, requested enumeration method and source object type.
- confirm that the object still belongs to the current WMServer, publishing-point or presentation generation.
- Perform one isolated experiment: request a concrete object path or use a data source that explicitly supports enumeration.
- Repeat the original the operation through the same protocol and service account; do not substitute a different client-side test.
- After it, verify the expected next state and retain any later HRESULT as a separate pipeline result.
Success means the same operation crosses this checkpoint and produces the expected next state, not merely that the symbolic code disappears.
Comparison with adjacent states
Primary distinction: source plug-in not found means no source was selected; here a source exists but lacks one optional capability.
| Nearby result | Different checkpoint |
|---|---|
NS_E_MEDIA_PARSER_INVALID_FORMAT | Compare its own symbolic boundary and the first failing call; it must not be grouped automatically with it. |
NS_E_PLAYLIST_PLUGIN_NOT_FOUND | Relative to it, this neighboring result belongs to another state or validation branch even when the user-visible symptom is similar. |
NS_E_SCRIPT_DEBUGGER_NOT_INSTALLED | Use the object type and operation sequence to determine which result is authoritative. |
Changes that do not establish the cause
- assuming every URL-like source can act as a directory.
- a broad reinstall is especially weak evidence here because it changes many unrelated components while leaving the rejected server precondition unexplained.
- Do not suppress it or replace it with a generic “media server error”; retain the symbolic code and owning operation in telemetry.
Technical references
- Plug-in classes in Windows Media Services
- Using Internal Events to Identify Errors
- System Media Parser Plug-ins
- Microsoft HRESULT registry
Close the incident only after it clears on a current object.
Looking for a different code? Search another status or error code.