| Previous | Next |
| SL_REMAPPING_SP_PUB_TS_INVALID_HW_BINDING | SL_REMAPPING_SP_PUB_TIMER_NOT_FOUND |
SL_REMAPPING_SP_PUB_TIMER_ALREADY_EXISTS
Why this is more specific than an activation failure
Keep the symbolic result SL_REMAPPING_SP_PUB_TIMER_ALREADY_EXISTS together with HRESULT 0xC004D30A. The producer is the trusted store and secure-timer layer; at the protected state store that keeps namespaced entries, attributes, secure timers, trusted time, hardware binding, rearm state and integrity breadcrumbs, Windows determined that creation was requested for a secure timer whose name already exists in the namespace.
the first result diagnostic fork is precise: the timer exists; this is not an expired or read-only timer. That is why this result can require a different correction from the same visible activation banner.
Investigation sequence
- Record this result,
0xC004D30A, the exact API or service operation, and the affected product or protected object. - Prove the specific condition: record timer name, namespace, existing deadline/flags and original creator.
- Compare the neighboring results below and identify which condition actually applies.
Minimum data for a reliable diagnosis
- 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
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 timer name, namespace, existing deadline/flags and original creator.
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_TIMER_NOT_FOUND | Compared with this result, the named secure timer is absent from the selected namespace. |
SL_REMAPPING_SP_PUB_TS_INVALID_HW_BINDING | Compared with this result, the trusted-store state no longer matches the machine hardware identity within allowed tolerance. |
SL_REMAPPING_SP_PUB_TIMER_EXPIRED | Compared with it, trusted time has passed the secure timer’s protected deadline. |
What to repair—and what not to reset
Open the existing timer or create a separate documented timer identity.
Representative case: A retry recreates a validity timer after the initial transaction committed.
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.