| Previous | Next |
| NS_E_DRM_UNABLE_TO_GET_SECURE_CLOCK_FROM_SERVER | NS_E_DRM_TRANSFER_CHAINED_LICENSES_UNSUPPORTED |
NS_E_DRM_POLICY_METERING_DISABLED
Where the operation stopped
0xC00D2776 maps to NS_E_DRM_POLICY_METERING_DISABLED. Read it as a result from portable-device certificate, secure clock and transfer policy: the content requires metering but metering is disabled for the client or device path. Keeping the “policy metering disabled” boundary intact prevents a later playback message from hiding the original DRM failure.
Record license metering requirement, policy state and metering object initialization.
State to capture before retry
- 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.
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
- Start from
0xC00D2776and map it to the first WMDRM object that returned it. - Separate content/header evidence, license evidence, machine/device evidence and service/network evidence around “policy metering disabled”.
- Before retrying this result, check whether another “policy metering disabled” operation was active or whether the previous result may have committed partially.
- Apply the smallest supported fix: enable supported metering or obtain a license that does not require it; avoid resetting unrelated protected state.
Targeted fix
The supported response to this result is narrow: enable supported metering or obtain a license that does not require it. After correcting it, reopen or recreate the object that owned “policy metering disabled” so the verification does not reuse state from the failed operation.
Representative case: Playback is denied because the license expects usage reports that policy has disabled.
What not to do first
- Avoid treating an unsupported-device result as a generic USB or file-copy failure.
- Avoid formatting the device before preserving its certificate, clock and firmware evidence.
Nearby results with different meanings
| Result | Different condition |
|---|---|
NS_E_DRM_TRANSFER_CHAINED_LICENSES_UNSUPPORTED | The requested device transfer does not support the selected chained-license relationship. |
NS_E_DRM_UNABLE_TO_GET_SECURE_CLOCK_FROM_SERVER | The client cannot obtain authoritative secure-clock data from the service. |
NS_E_DRM_UNABLE_TO_SET_SECURE_CLOCK | The DRM client cannot commit secure-clock data to the device. |
Verification after correction
A valid regression has two fixtures: one that deliberately produces “the content requires metering but metering is disabled for the client or device path” and one that applies the targeted correction. Compare callback order, selected license/KID, final rights decision and persistence state; disappearance of the “policy metering disabled” dialog alone is not proof.
Code-specific operational note
The user-facing message “This content requires the metering policy to be enabled.” describes the visible condition but does not identify the producing API, object instance, or protected identity by itself.
Technical references
Looking for a different code? Search another status or error code.