| Previous | Next |
| NS_E_DRM_UNABLE_TO_SET_SECURE_CLOCK | NS_E_DRM_POLICY_METERING_DISABLED |
NS_E_DRM_UNABLE_TO_GET_SECURE_CLOCK_FROM_SERVER
The exact DRM condition
0xC00D2775 maps to NS_E_DRM_UNABLE_TO_GET_SECURE_CLOCK_FROM_SERVER. Read it as a result from portable-device certificate, secure clock and transfer policy: the client cannot obtain authoritative secure-clock data from the service. Keeping the “unable to get secure clock from server” boundary intact prevents a later playback message from hiding the original DRM failure.
Record endpoint, network response, certificate validation and returned time status.
Place in the DRM workflow
The workflow around this result matters: a device can be reachable as storage while still failing WMDRM authentication, secure-clock or policy requirements. In addition, time-bound and subscription licenses may require a trusted device clock; changing the host clock does not repair a device clock that was never obtained or set.
A useful investigation order
- Prove the boundary by ensuring you can record endpoint, network response, certificate validation and returned time status.
- After you restore service reachability and repeat the trusted-time exchange, verify both the requested right and the final store/device state.
State to capture before retry
- Code-specific proof: record endpoint, network response, certificate validation and returned time status.
- Protected identity: device activation, registration and metering result.
- Operation state: device model, firmware and WMDRM capability.
- Persistence or transport: device certificate chain and serial identity.
- Security context: secure clock value, source and last successful update.
- Correlation point: requested transfer/burn action and license restriction.
Targeted fix
Resolve the underlying condition directly: restore service reachability and repeat the trusted-time exchange. A player reinstall, reboot or new license request is useful only when it changes the condition “unable to get secure clock from server” and can be verified against the original evidence.
Representative case: Ordinary web access works, but the DRM secure-clock service request fails.
Nearby results with different meanings
| Result | Different condition |
|---|---|
NS_E_DRM_POLICY_METERING_DISABLED | The content requires metering but metering is disabled for the client or device path. |
NS_E_DRM_UNABLE_TO_SET_SECURE_CLOCK | The DRM client cannot commit secure-clock data to the device. |
NS_E_DRM_TRANSFER_CHAINED_LICENSES_UNSUPPORTED | The requested device transfer does not support the selected chained-license relationship. |
Verification after correction
Repeat the operation that originally returned it. Assert the exact HRESULT at the producing API in the failing “unable to get secure clock from server” fixture; then change only the relevant precondition and confirm that the corrected run completes without substituting a neighboring DRM result. After correcting it, verify the requested action and the final license-store, secure-clock, device or migration state relevant to “unable to get secure clock from server”.
Code-specific operational note
The user-facing message “A problem has occurred in obtaining the secure clock from server.
Technical references
Looking for a different code? Search another status or error code.