| Previous | Next |
| SL_REMAPPING_MDOLLAR_TIMEBASED_ACTIVATION_BEFORE_START_DATE | SL_REMAPPING_MDOLLAR_TIMEBASED_ACTIVATION_NOT_AVAILABLE |
SL_REMAPPING_MDOLLAR_TIMEBASED_ACTIVATION_AFTER_END_DATE
The scope of SL_REMAPPING_MDOLLAR_TIMEBASED_ACTIVATION_AFTER_END_DATE, HRESULT 0x803FA098, is Microsoft-hosted activation and product-key rule processing: the activation request was made after the entitlement end date. In a hosted activation time-based activation after end date incident, UTC request and response times should be captured before another retry changes state.
Evidence that can change the diagnosis
| Record | Why it matters |
|---|---|
| Primary record | UTC request and response times; this is the shortest evidence path to the decision. |
| Object correlation | Keep the product, account, package, device, key, or API identity associated with the recorded identifiers and values beside the first timestamped result. |
| Neighboring-state control | Use a controlled comparison that tests whether an expired activation window differs from a CLiP app-license expiration and from a local grace-period countdown; this separates the named condition from a nearby status. |
| Before/after result | Retain the outcome before and after the corrective action “check that the device is using the intended current entitlement”; keep the same identifiers until the current entitlement covers the request time and activation status remains valid after time resynchronization. |
Why this HRESULT is specific
The activation service evaluated the request against an expired time window. Local reinstall or key re-entry does not extend the server-side end date.
The decisive question is whether the primary record supports the reported condition that the activation request was made after the entitlement end date. Keep evidence tied to the failing operation.
How to distinguish nearby failures
The key comparison is this: An expired activation window differs from a CLiP app-license expiration and from a local grace-period countdown. A valid hosted activation time-based activation after end date test keeps UTC request and response times attached to the same object and varies one supported prerequisite.
Controlled troubleshooting sequence
- Locate the exact object: Use the primary record to identify the transaction or licensed object that actually returned this result.
- Preserve the first decision: Record the earliest event stating that the activation request was made after the entitlement end date, together with the code, UTC time, and the same identity fields.
- Change one prerequisite: Check that the device is using the intended current entitlement; do not combine this with a store reset, key replacement, account removal, package reinstall, or unrelated repair.
- Repeat the user operation: Re-run the original operation and require that the current entitlement covers the request time and activation status remains valid after time resynchronization; if another HRESULT appears, diagnose it as a new boundary.
Evidence-preserving cautions
While investigating this result, do not backdate the device clock or reuse an expired entitlement. That shortcut can replace or invalidate that evidence before the original decision is understood.
Verification
The incident is resolved only when the current entitlement covers the request time and activation status remains valid after time resynchronization. Confirm the result by repeating the exact operation that produced this result; maintenance success alone is insufficient.
Technical references
- Microsoft Win32 metadata: winerror.h — status definition reference.
- Microsoft: SoftwareLicensingProduct WMI class — owning service/API reference.
- Microsoft: Troubleshoot Windows activation error codes — diagnostic/remediation API reference.
- Microsoft: Plan for volume activation — lifecycle reference.
Looking for a different code? Search another status or error code.