| Previous | Next |
| SL_REMAPPING_SP_PUB_TS_ENTRY_KEY_ALREADY_EXISTS | SL_REMAPPING_SP_PUB_TS_MAX_REARM_REACHED |
SL_REMAPPING_SP_PUB_TS_ENTRY_KEY_SIZE_TOO_BIG
Why this is more specific than an activation failure
0xC004D306 maps to SL_REMAPPING_SP_PUB_TS_ENTRY_KEY_SIZE_TOO_BIG. 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, the entry-key identifier exceeds the trusted store’s supported key-size limit.
This distinction matters because the identifier is too large; entry data size can still be acceptable. A later “not licensed” state should not replace the first exact HRESULT in logs.
A practical way to isolate the cause
- Identify the caller and operation instance that produced
0xC004D306. - Collect the code-specific evidence: record encoded key length, character encoding, namespace and generating component.
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 encoded key length, character encoding, namespace and generating component.
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.
What to capture before recovery
- 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
Targeted fix
Shorten or correctly encode the key according to the component’s schema.
Representative case: A caller embeds an entire URI in a field intended for a compact entry key.
Why the symbolic code matters
| Result | Different condition |
|---|---|
SL_REMAPPING_SP_PUB_TS_ENTRY_KEY_ALREADY_EXISTS | Compared with this result, creation conflicts with an existing entry key in the same trusted-store namespace. |
SL_REMAPPING_SP_PUB_TS_MAX_REARM_REACHED | Compared with this result, the protected rearm counter has reached the maximum permitted by licensing policy. |
SL_REMAPPING_SP_PUB_TS_DATA_SIZE_TOO_BIG | Compared with it, the value being stored exceeds the maximum data size for one trusted-store entry. |
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.