What does HRESULT 0xC00D0192 (NS_E_BAD_CUB_UID) mean?

 
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.


Looking for a different code? Search another status or error code.