| Previous | Next |
| NS_E_WMX_ATTRIBUTE_UNRETRIEVABLE | NS_E_WMX_ITEM_TYPE_ILLEGAL |
NS_E_WMX_ITEM_DOES_NOT_EXIST
Understanding NS_E_WMX_ITEM_DOES_NOT_EXIST in a Windows Media playlist
NS_E_WMX_ITEM_DOES_NOT_EXIST (0xC00D1071) is returned when the requested playlist item index or identity is not part of the current playlist generation.
Distinguish in-memory Playlist state, WPL or ASX parsing, nested-list expansion, Media-object resolution and execution of referenced items. This result identifies a narrower stage than the dialog text exposes, so preserve its operation before trying a workaround. In this case the rejected checkpoint is the requested playlist item index or identity is not part of the current playlist generation.
Playlist boundary
AllStat already supplies the standard user-facing description for this HRESULT; this custom block instead isolates the additional technical boundary. Earlier success in file lookup, network connection, parser creation or graph construction does not prove that the later the operation is valid.
Case-specific checkpoint: playlist count, requested index, item URL, mutation history and whether an auto playlist was refreshed. The controlled comparison for this HRESULT is: enumerate the list immediately before the operation and use an item returned by that enumeration.
Closest distinction: NS_E_WMPCORE_ITEMNOTINPLAYLIST concerns a Media object not belonging to a list; this result is commonly tied to WMX item lookup.
Evidence from the list model
| Capture | Why it matters for this HRESULT |
|---|---|
| Object or resource | playlist count, requested index, item URL, mutation history and whether an auto playlist was refreshed |
| State snapshot | Record the Player openState/playState or operation phase, object identity and exact timestamp when this result was returned. |
| First lower result | Keep the earliest Win32, Winsock, COM, parser, codec, DRM or device result that appears before this result. |
| Comparison record | Use one known-good case that follows the same API, protocol and component path while changing only the rejected precondition. |
Minimal playlist experiment
- Freeze the current object state and collect playlist count, requested index, item URL, mutation history and whether an auto playlist was refreshed.
- Reproduce it once without automatic retries or fallback applications.
- Change only one precondition: enumerate the list immediately before the operation and use an item returned by that enumeration.
- compare the first nested status and next Player event with the failed run.
- After testing it, restore the original configuration if the change was diagnostic only.
What the result means
| Retest outcome | Interpretation |
|---|---|
| Same it on the same object | The governing state or value is unchanged, or the caller is reusing an object created before the relevant change. |
| Fresh object succeeds | Lifetime, cached configuration or stale playlist/graph state contributed to it. |
| A later HRESULT appears | The rejected condition — the requested playlist item index or identity is not part of the current playlist generation — was cleared for this HRESULT; diagnose the new code at its own layer. |
| Only one item or endpoint fails for this HRESULT | The evidence favors resource-specific data, rights, routing or device state rather than a global Player failure. |
Actions that obscure the cause
- caching numeric indexes across playlist rebuilds.
- Do not discard the first occurrence by repeatedly invoking Play, open, save or retry; later events can replace its original state.
- do not publish credentials, private URLs, license material or complete protected-content headers; retain only redacted identifiers, lengths, hashes and protocol fields.
Technical references
- Windows Media Player SDK
- Windows Media Playlists
- Windows Media Playlist elements
- Managing playlists
- Microsoft HRESULT registry
After it, a different downstream HRESULT is progress and should be recorded as a separate condition.
Looking for a different code? Search another status or error code.