| Previous | Next |
| SL_REMAPPING_SP_PUB_CRYPTO_INVALID_PADDING | SL_REMAPPING_SP_PUB_TS_REARMED |
SL_REMAPPING_SP_PUB_TS_TAMPERED
What the protected licensing code means
SL_REMAPPING_SP_PUB_TS_TAMPERED (0xC004D301) is emitted by the trusted store and secure-timer layer. It marks a specific point inside the protected state store that keeps namespaced entries, attributes, secure timers, trusted time, hardware binding, rearm state and integrity breadcrumbs: the trusted store failed an integrity check and its protected state cannot be accepted as authentic.
For triage, this belongs to the trusted store and secure-timer layer. This is an integrity verdict, not merely a missing entry or full store. Product-key changes or network tests are useful only when the evidence points back to those layers.
Minimum data for a reliable diagnosis
- requested and actual data size
- trusted time, timer deadline and hardware-binding state
- tamper/recreation/rearm events in chronological order
- namespace, entry key and attribute name
- entry/timer flags including read-only state
Where it sits in the licensing pipeline
Trusted-store results concern protected persistent state; deleting the store can erase the evidence that distinguishes missing data, capacity, access, binding and integrity failures. To verify this, preserve tamper event details, store generation, hashes, servicing history and the first affected boot.
A positive trusted-time or rearm/recreation result must be interpreted by HRESULT severity and the subsequent license state, not by treating every nonzero value as a fatal error.
Similar symptoms, different conditions
| Result | Different condition |
|---|---|
SL_REMAPPING_SP_PUB_TS_REARMED | Compared with this result, the trusted store has completed a supported rearm transition and licensing timers/state were reset according to policy. |
SL_REMAPPING_SP_PUB_TS_RECREATED | Compared with this result, the trusted store was recreated rather than opened in its previous generation. |
SL_REMAPPING_SP_PUB_TS_ENTRY_KEY_NOT_FOUND | Compared with this result, the requested entry key is absent from the selected trusted-store namespace. |
Investigation sequence
- Start with the earliest event carrying it; later status queries may only report the resulting unlicensed or notification state.
- Use read-only inspection first: preserve tamper event details, store generation, hashes, servicing history and the first affected boot.
Actions that usually destroy useful evidence
- Do not manually delete protected store files before collecting state and event evidence.
- Do not use rearm as a generic repair for unrelated activation or integrity errors.
Safe recovery direction
Repair system integrity and use supported licensing-store recovery; investigate unauthorized modifications before rebuilding.
Representative case: Protected store bytes or related system components are altered outside supported servicing.
Treat the first occurrence as an integrity incident
Before rebuilding any licensing store, preserve the Security-SPP event export, hashes and signatures of relevant protected components, the servicing history and the original store generation. The question is not merely whether activation can be made to work again, but whether corruption, an unsupported patch, a partial restore or unauthorized modification changed protected state.
Run component-integrity diagnostics from a trusted administrative environment and repair the Windows image with supported DISM and SFC workflows. Only after platform integrity is established should the documented Tokens.dat recovery procedure be considered. Rearm, product-key replacement and clock changes do not authenticate a tampered store.
| Finding | Diagnostic direction |
|---|---|
| Signed system file mismatch | Repair the component store and protected files before licensing recovery. |
| Partial backup restore | Look for generation or breadcrumb inconsistency across restored artifacts. |
| Unofficial patching tool | Remove the modification and restore a trusted platform image. |
Technical references
- SoftwareLicensingProduct WMI class — reference for evidence collection and post-repair verification.
- SoftwareLicensingService WMI class — technical contract for the subsystem producing it.
- Slmgr.vbs options — official platform context used to interpret it.
- Rebuild the Tokens.dat file — supported state, API or recovery information relevant to this HRESULT.
Looking for a different code? Search another status or error code.