| Previous | Next |
| SL_REMAPPING_SP_PUB_TS_ENTRY_KEY_NOT_FOUND | SL_REMAPPING_SP_PUB_TS_ENTRY_KEY_SIZE_TOO_BIG |
SL_REMAPPING_SP_PUB_TS_ENTRY_KEY_ALREADY_EXISTS
Why this is more specific than an activation failure
0xC004D305 maps to SL_REMAPPING_SP_PUB_TS_ENTRY_KEY_ALREADY_EXISTS. 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, creation conflicts with an existing entry key in the same trusted-store namespace.
For triage, this belongs to the trusted store and secure-timer layer. This is a key-identity collision, not lack of overall store capacity. Product-key changes or network tests are useful only when the evidence points back to those layers.
Investigation sequence
- Use read-only inspection first: capture namespace/key, existing flags, creator and commit history.
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, capture namespace/key, existing flags, creator and commit history.
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.
State to compare on both sides of the failure
- 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
- requested and actual data size
Recovery while preserving licensing evidence
Open/update the existing entry when allowed or allocate a distinct supported key.
Representative case: A retry repeats entry creation after the original transaction already committed.
Do not confuse it with these nearby results
| Result | Different condition |
|---|---|
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. |
SL_REMAPPING_SP_PUB_TS_ENTRY_KEY_SIZE_TOO_BIG | Compared with it, the entry-key identifier exceeds the trusted store’s supported key-size limit. |
SL_REMAPPING_SP_PUB_TS_MAX_REARM_REACHED | Compared with it, the protected rearm counter has reached the maximum permitted by licensing policy. |
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.
Technical references
- SoftwareLicensingProduct WMI class — official platform context used to interpret it.
- SoftwareLicensingService WMI class — supported state, API or recovery information relevant to this HRESULT.
- Slmgr.vbs options — reference for evidence collection and post-repair verification.
- Rebuild the Tokens.dat file — technical contract for the subsystem producing it.
Looking for a different code? Search another status or error code.