| Previous | Next |
| SL_REMAPPING_SP_PUB_TS_TAMPERED_INVALID_DATA | SL_REMAPPING_SP_PUB_TS_TAMPERED_DATA_BREADCRUMB_MISMATCH |
SL_REMAPPING_SP_PUB_TS_TAMPERED_NO_DATA
What the security processor has established
0xC004D31A maps to SL_REMAPPING_SP_PUB_TS_TAMPERED_NO_DATA. This result belongs to the trusted store and secure-timer layer and narrows the operation to the protected state store that keeps namespaced entries, attributes, secure timers, trusted time, hardware binding, rearm state and integrity breadcrumbs. In concrete terms, required protected trusted-store data is absent when integrity validation expects it.
the first result diagnostic fork is precise: absence differs from present data that fails validation. That is why this result can require a different correction from the same visible activation banner.
State to compare on both sides of the failure
- namespace, entry key and attribute name
- entry/timer flags including read-only state
- requested and actual data size
- trusted time, timer deadline and hardware-binding state
- tamper/recreation/rearm events in chronological order
A practical way to isolate the cause
- Record this result,
0xC004D31A, the exact API or service operation, and the affected product or protected object. - Prove the specific condition: record expected namespace/entry, store generation, recreation history and the component that should have created the data.
- Compare the neighboring results below and identify which condition actually applies.
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, record expected namespace/entry, store generation, recreation history and the component that should have created the data.
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.
Why the symbolic code matters
| Result | Different condition |
|---|---|
SL_REMAPPING_SP_PUB_TS_TAMPERED_DATA_BREADCRUMB_MISMATCH | Compared with this result, trusted-store data and the associated integrity breadcrumb do not authenticate the same state. |
SL_REMAPPING_SP_PUB_TS_TAMPERED_INVALID_DATA | Compared with it, trusted-store data fails internal semantic or integrity validation. |
SL_REMAPPING_SP_PUB_TS_TAMPERED_BREADCRUMB_GENERATION | Compared with it, the trusted store and its integrity breadcrumb belong to incompatible generations. |
Correcting the producing condition
Reinstall or reinitialize the owning licensing component, preserving evidence before any rebuild.
Representative case: An incomplete migration creates the store shell but omits required protected records.
Actions that usually destroy useful evidence
- Do not use rearm as a generic repair for unrelated activation or integrity errors.
- Do not manually delete protected store files before collecting state and event evidence.
Technical references
- SoftwareLicensingProduct WMI class — technical contract for the subsystem producing it.
- SoftwareLicensingService WMI class — official platform context used to interpret it.
- Slmgr.vbs options — supported state, API or recovery information relevant to this HRESULT.
- Rebuild the Tokens.dat file — reference for evidence collection and post-repair verification.
Looking for a different code? Search another status or error code.