What does HRESULT 0xC004D30E (SL_REMAPPING_SP_PUB_TS_FULL) mean?

 
Previous Next
SL_REMAPPING_SP_PUB_TIMER_NAME_SIZE_TOO_BIG SL_REMAPPING_SP_PUB_TS_ENTRY_READ_ONLY

SL_REMAPPING_SP_PUB_TS_FULL

Why this is more specific than an activation failure

Keep the symbolic result SL_REMAPPING_SP_PUB_TS_FULL together with HRESULT 0xC004D30E. 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 the trusted store has no capacity for the requested additional protected state.

the first result diagnostic fork is precise: overall capacity exhaustion differs from one entry whose key or value is individually oversized. That is why this result can require a different correction from the same visible activation banner.

Evidence worth preserving

  • 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 store size, namespace/entry counts, attempted allocation and repeated abandoned objects.

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.

Testing the failing stage

  1. Identify the caller and operation instance that produced 0xC004D30E.
  2. Collect the code-specific evidence: record store size, namespace/entry counts, attempted allocation and repeated abandoned objects.

Correcting the producing condition

Remove only obsolete data through supported ownership APIs or rebuild if the store is structurally unhealthy.

Representative case: A faulty component repeatedly creates unique protected entries until capacity is exhausted.

Comparison with neighboring results

ResultDifferent condition
SL_REMAPPING_SP_PUB_TIMER_NAME_SIZE_TOO_BIGCompared with this result, the secure-timer name exceeds the supported encoded length.
SL_REMAPPING_SP_PUB_TIMER_EXPIREDCompared with this result, trusted time has passed the secure timer’s protected deadline.
SL_REMAPPING_SP_PUB_TS_ENTRY_READ_ONLYCompared with this result, the requested mutation targets a trusted-store entry marked read-only.

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


Looking for a different code? Search another status or error code.