| Previous | Next |
| NS_E_CUB_FAIL_LINK | NS_E_GLITCH_MODE |
NS_E_BAD_CUB_UID
NS_E_BAD_CUB_UID — 0xC00D0192
Treat this code as a record of incorrect Content Server UID: in the operation that returned it, the server identity presented by a Content Server does not match the UID expected by the topology or peer.
Operational meaning
Legacy content-server links carry topology and content coordination between server identities. In the context of incorrect Content Server UID, reachability, authentication, UID consistency, and post-outage reconciliation are separate checks; a TCP connection alone does not prove a healthy peer relationship. Locate the first component that changes state and distinguish later summary errors.
Important distinction. A reachable server with the wrong UID is not a networking failure; accepting it can corrupt ownership and topology decisions.
Facts worth preserving
- Server name, presented UID, expected UID, configuration source, and peer reporting the mismatch
- Clone, restore, rename, or reinstallation history
- Duplicate UID search across all servers
- Disk ownership and link records tied to the identity
Reproduce the condition safely
- Compare local and peer configuration without changing either. Use a disposable publishing point or maintenance window when the test can alter server or storage state.
- Start a known correctly identified peer on the same link path. Retain a known-good stream, session, or server object so a broad restart is not mistaken for repair of the reported failure.
- Verify cloned server images generate or receive distinct supported identities.
Stop after the first comparison that changes the result and diagnose the replacement status independently instead of accumulating unrelated server changes.
What not to infer
- Known-good comparison succeeds: isolate the production object or configuration associated with the failing operation.
- Same failure on the control: investigate the shared server, plug-in, storage, topology, or network layer before changing media content.
- Different status after one change: preserve both results; the first rejected condition was removed, but the operation is not yet proved complete.
Closing the incident
Correction: Restore the authoritative identity mapping or re-provision the cloned/replaced server through the supported process.
Accept the repair only when every server has one unique consistent UID across peers, disks, and management data, and links remain stable.
Technical references
These sources describe the API, service architecture, and status values relevant to this diagnosis: Check version-specific behavior against the Windows Media Services and SDK generation that produced the event.
- Microsoft Open Specifications: HRESULT values — defines the formal status.
- Microsoft: Windows Media Services 9 Series SDK — documents the relevant API or lifecycle.
- Microsoft: Windows Media Services SDK architecture — provides the architecture, format, or protocol context.
- Microsoft: programming the Windows Media server object model — supports the controlled verification criteria.
Looking for a different code? Search another status or error code.
