| Previous | Next |
| SL_REMAPPING_SP_PUB_TS_TAMPERED_NO_DATA | SL_REMAPPING_SP_PUB_TS_TAMPERED_DATA_VERSION_MISMATCH |
SL_REMAPPING_SP_PUB_TS_TAMPERED_DATA_BREADCRUMB_MISMATCH
What the protected licensing code means
The useful meaning of SL_REMAPPING_SP_PUB_TS_TAMPERED_DATA_BREADCRUMB_MISMATCH, value 0xC004D31B, is not simply “activation failed.” It comes from the trusted store and secure-timer layer, where the protected state store that keeps namespaced entries, attributes, secure timers, trusted time, hardware binding, rearm state and integrity breadcrumbs. The condition to investigate is trusted-store data and the associated integrity breadcrumb do not authenticate the same state.
the first result diagnostic fork is precise: both objects may be individually parseable; their relationship is inconsistent. That is why this result can require a different correction from the same visible activation banner.
A reproducible troubleshooting path
- Use read-only inspection first: retain both generation IDs, hashes, last-write evidence, snapshot/restore history and first mismatch event.
Inputs that distinguish this condition
- 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, retain both generation IDs, hashes, last-write evidence, snapshot/restore history and first mismatch event.
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_TAMPERED_DATA_VERSION_MISMATCH | Compared with this result, trusted-store protected data uses a version incompatible with the integrity metadata or current processor. |
SL_REMAPPING_SP_PUB_TS_TAMPERED_NO_DATA | Compared with this result, required protected trusted-store data is absent when integrity validation expects it. |
SL_REMAPPING_SP_PUB_TS_TAMPERED_INVALID_DATA | Compared with it, trusted-store data fails internal semantic or integrity validation. |
What to repair—and what not to reset
Restore a matching state set or use supported recreation after investigating partial restore or modification.
Representative case: Backup software restores the store and breadcrumb from different points in time.
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.
The store and breadcrumb must be restored as one state set
It is characteristic of non-atomic restoration: the trusted-store data is parseable and the breadcrumb is parseable, but they authenticate different snapshots. Compare generation identifiers, hashes and backup timestamps rather than replacing whichever file appears older.
For virtual machines and image-based backup products, determine whether application-consistent quiescing included every protected licensing artifact. A crash-consistent snapshot can capture one member of the pair before commit and the other after commit. The safe correction is a matching state set or supported store recreation, not manually copying a breadcrumb from another machine.
| Evidence | What it can show |
|---|---|
| Store generation | Which committed trusted-store state the data represents. |
| Breadcrumb generation/hash | Which state the integrity proof authenticates. |
| Snapshot boundary | Whether backup captured the pair on opposite sides of a commit. |
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.