| Previous | Next |
| NS_E_DRM_ACTION_NOT_QUERIED | NS_E_DRM_INDIVIDUALIZING |
NS_E_DRM_ACQUIRING_LICENSE
How to classify this result
When the client returns NS_E_DRM_ACQUIRING_LICENSE (0xC00D272B), the decisive condition is another license acquisition is already active for the DRM object. This result belongs to license challenge, acquisition and server response processing, specifically the asynchronous path that builds a license request from the protected content header, sends or exposes the challenge, receives a response and commits accepted licenses to the local store, when reproducing acquiring license.
The built-in message summarizes the user-visible outcome, while the symbolic phrase “acquiring license” preserves the exact WMDRM boundary for diagnosis. For this code, the proof step is to identify the active operation, its completion callback and cancellation cookie,.
Minimum incident record
Capture the first occurrence before automatic retry, player teardown, store repair or license reacquisition changes the state,. The smallest useful record contains:
- Code-specific proof: identify the active operation, its completion callback and cancellation cookie, while tracing acquiring license.
- Protected identity: silent or non-silent acquisition mode and callback/event sequence, for the acquiring license boundary.
- Operation state: request or challenge identifier and response HTTP status, during acquiring license diagnosis.
- Persistence or transport: server certificate, response signature and returned license count, in a acquiring license incident.
- Security context: store commit result after a successful server response, for this acquiring license result.
- Correlation point: content KID and license acquisition URL from the header, when reproducing acquiring license.
For the “acquiring license” investigation, use KIDs, license IDs, hashes, certificate thumbprints, sizes and timestamps where possible. While diagnosing this result, do not place content keys, complete license blobs, passwords, cookies or decrypted media in ordinary logs,.
Why the producing layer matters
Two platform rules frame this result. License acquisition and license storage are separate stages: a valid server response can still fail while being validated or committed locally,. Because acquisition is asynchronous, starting a second request before the completion event can produce a state error rather than a network failure, while tracing acquiring license.
Triage without destroying evidence
- Locate the earliest API return, callback or event containing this result and
0xC00D272B. - identify the exact content, license, store, device or migration object generation involved in “acquiring license”.
- determine whether “acquiring license” occurred before network exchange, during response validation, while enforcing policy, or while committing protected state.
- Perform the code-specific check: identify the active operation, its completion callback and cancellation cookie, for the boundary.
- Make one narrow correction — wait for or explicitly cancel the existing acquisition before starting another — and repeat the same producing operation, during acquiring license diagnosis.
Why the symbolic name matters
| Result | Different boundary |
|---|---|
NS_E_DRM_INVALID_LICENSE_ACQUIRED | The server response completed but the returned license is not acceptable to the client, in a incident. |
NS_E_DRM_UNABLE_TO_ACQUIRE_LICENSE | The acquisition workflow did not produce a usable license, for this acquiring license result. |
NS_E_DRM_INVALID_LICENSE_REQUEST | The generated or supplied license request is not valid for the protected content, when reproducing acquiring license. |
Several values can accompany the “acquiring license” condition in one incident. Order the result event chain by timestamp and prefer the first code produced at the lowest specific boundary over a later player-level summary,.
Shortcuts that make diagnosis worse
- Avoid blindly retrying a state-changing license request without correlating the previous challenge and completion event,. That changes evidence without demonstrating why it was produced.
- Avoid logging complete license challenges, responses, cookies or credentials in diagnostic output, while tracing acquiring license. That shortcut can create a second store, identity or policy problem, for the boundary.
- Do not reduce it to “DRM failed” in telemetry; retain the HRESULT, symbolic name, operation and object identity, during acquiring license diagnosis.
Recovery at the right layer
The corrective direction is to wait for or explicitly cancel the existing acquisition before starting another, in a incident. Preserve the original content/header, store or migration material for it until the “acquiring license” operation succeeds and survives a fresh application object or required restart.
Representative case: Two UI paths start acquisition for the same content while the first request is pending, for this acquiring license result.
Completion criteria
After the repair, recreate the WMDRM object and run the smallest reproducer for it. Confirm that 0xC00D272B no longer occurs, that the intended license action completes, and that no store, certificate, clock or migration warning replaces it, when reproducing acquiring license.
Code-specific operational note
The symbolic phrase “acquiring license” is the important search and telemetry key for it. Keep it beside the exact value 0xC00D272B; the official message “You cannot begin a new license acquisition process until the current one has been completed,.” is useful to users, but it does not identify the producing API, object generation or protected identity on its own,.
Technical references
- Acquiring licenses — API and state rules relevant to this the boundary.
- Handling license acquisition events — platform documentation used to distinguish it from adjacent results.
- DRM protection and license distribution — official Windows Media DRM context for it.
- DRM client programming guide — API and state rules relevant to this the boundary.
Looking for a different code? Search another status or error code.