| Previous | Next |
| XACT_E_REPLAYREQUEST | SL_REMAPPING_SP_STATUS_DEBUGGER_DETECTED |
SL_REMAPPING_SP_STATUS_SYSTEM_TIME_SKEWED
What the security processor has established
0x8004D102 maps to SL_REMAPPING_SP_STATUS_SYSTEM_TIME_SKEWED. This result belongs to the Software Protection security-processor API and narrows the operation to the stateful API layer that initializes a protected environment, validates handles and versions, commits changes, enumerates data and enforces trusted-time or debugger restrictions. In concrete terms, the security processor’s trusted time and the machine time are outside the accepted relationship.
This distinction matters because this is a trusted-time consistency check, not ordinary KMS clock-skew alone. A later “not licensed” state should not replace the first exact this result HRESULT in logs.
Where it sits in the licensing pipeline
These results describe the protected API contract; they are not automatically evidence that the installed product key is invalid. The decisive proof for it is to compare UTC system time, TrustedTime, time-service source, recent clock jumps, firmware time and suspend/restore events.
Handle creation, mutation, commit and enumeration are separate stages, so the first failing call is more useful than a later activation summary. Keep that product/object identity because the same service can expose several independent licensing instances.
Minimum data for a reliable diagnosis
| Item | Why it matters here |
|---|---|
| operation and API version | Identifies the protected object or product instance that returned the code. |
| environment or handle lifetime | Separates format/version failure from damage, absence or access failure. |
| buffer length and returned required size | Shows the state transition immediately before the HRESULT. |
| trusted time and system UTC time | Correlates service-level evidence with storage, crypto or policy evidence. |
| Security-SPP event sequence and caller process | Reveals whether servicing, migration, restore, cloning or concurrent work changed the precondition. |
Code-specific check: compare UTC system time, TrustedTime, time-service source, recent clock jumps, firmware time and suspend/restore events.
Testing the failing boundary
- Start with the earliest event carrying this result; later status queries may only report the resulting unlicensed or notification state.
- tie the event to one Application ID/Activation ID, handle, namespace, token or crypto object rather than to the computer in general.
- use read-only inspection first: compare UTC system time, TrustedTime, time-service source, recent clock jumps, firmware time and suspend/restore events.
- check whether the issue reproduces after normal service restart without altering signed store or policy data.
- After a supported repair for it, query the same object and confirm that the original boundary no longer fails.
Similar symptoms, different boundaries
| Result | Different condition |
|---|---|
SL_REMAPPING_SP_STATUS_DEBUGGER_DETECTED | Compared with this result, the protected security-processor operation detected a debugger or equivalent instrumentation and refused to run. |
SL_REMAPPING_SP_PUB_API_HANDLE_NOT_COMMITED | Compared with it, a protected handle was consumed before its staged changes were finalized with the required commit operation. |
SL_REMAPPING_SP_PUB_GENERAL_NOT_INITIALIZED | Compared with it, the security-processor environment was used before initialization completed successfully. |
Safe recovery direction
Correct the authoritative time source and clock state, then refresh license status without manually altering trusted-store timestamps. Preserve the original store, event export, hashes and licensing inventory until the operation succeeds and the expected state survives any required restart.
Representative case: A VM snapshot restores an older system clock while protected trusted time has already advanced.
Actions that usually destroy useful evidence
- do not retrying the whole activation workflow without preserving the first API result.
- do not attaching debuggers or instrumentation to a protected production path while reproducing the issue.
- While resolving it, do not use unofficial activation tools, patched binaries, copied stores, disabled integrity checks or hand-edited signed data; they can create a second tamper condition.
Verification after correction
Repeat the operation that originally produced it, not merely a UI refresh. Confirm the exact product/object completes, review LicenseStatus and LicenseStatusReason when applicable, and check that no related boundary replaces it.
Regression testing, retain one failing fixture that reproduces “the security processor’s trusted time and the machine time are outside the accepted relationship” and one passing fixture that changes only the decisive precondition; this avoids mistaking a broad reset for verification.
Technical references
- Software Licensing provider — official platform context used to interpret it.
- SoftwareLicensingService WMI class — supported state, API or recovery information relevant to it.
- SoftwareLicensingProduct WMI class — reference for it evidence collection and post-repair verification.
- Windows SDK constants — technical contract for the subsystem producing it.
Looking for a different code? Search another status or error code.