| Previous | Next |
| SL_REMAPPING_SP_PUB_KM_CACHE_IDENTICAL | SL_I_OOB_GRACE_PERIOD |
SL_REMAPPING_SP_PUB_KM_CACHE_POLICY_CHANGED
What this Software Protection result isolates
0x4004D602 maps to SL_REMAPPING_SP_PUB_KM_CACHE_POLICY_CHANGED. This result belongs to Software Protection integrity and kernel-cache enforcement and narrows the operation to the integrity path that authenticates protected modules, compares security-processor state with kernel-mode policy data, restores cached state and detects proxy or patch interference. In concrete terms, policy changes that require reboot were detected while preparing the kernel-mode licensing cache.
the first result diagnostic fork is precise: the cache update can be valid even though enforcement cannot fully switch until reboot. That is why this result can require a different correction from the same visible activation banner.
Where it sits in the licensing pipeline
A module or cache integrity result should be investigated as a component-integrity problem before changing product keys or activation endpoints. The decisive proof for it is to record changed policy identifiers, old/new cache generations and reboot-pending state.
Servicing tools can repair protected system files, while unofficial replacements, patchers or permission resets can create a second mismatch and destroy provenance. Keep that product/object identity because the same service can expose several independent licensing instances.
Checks in the useful order
- Record this result,
0x4004D602, the exact API or service operation, and the affected product or protected object. - capture the five state items above before restarting the service, rebuilding the store, repairing files or retrying activation.
- prove the specific condition: record changed policy identifiers, old/new cache generations and reboot-pending state.
- compare the neighboring results below and identify which boundary is actually present.
- change one decisive precondition, repeat the original operation, and verify both the immediate HRESULT and durable license state.
What to capture before recovery
| Item | Why it matters here |
|---|---|
| SFC/DISM results and Security-SPP event correlation | Reveals whether servicing, migration, restore, cloning or concurrent work changed the precondition. |
| exact module/file and version | Identifies the protected object or product instance that returned the code. |
| digital signature and file hash | Separates format/version failure from damage, absence or access failure. |
| OS build and servicing level | Shows the state transition immediately before the HRESULT. |
| kernel-cache policy generation and reboot state | Correlates service-level evidence with storage, crypto or policy evidence. |
Code-specific check: record changed policy identifiers, old/new cache generations and reboot-pending state.
Why the symbolic code matters
| Result | Different condition |
|---|---|
SL_REMAPPING_SP_PUB_KM_CACHE_IDENTICAL | Compared with this result, a kernel-mode policy-cache refresh produced data identical to the active cache, so no replacement was required. |
SL_REMAPPING_SP_PUB_TAMPER_MODULE_AUTHENTICATION | Compared with it, a protected module failed authentication against the expected signed system component. |
SL_REMAPPING_SP_PUB_TAMPER_SECURITY_PROCESSOR_PATCHED | Compared with it, the security-processor implementation appears patched or inconsistent with the signed platform image. |
Actions that usually destroy useful evidence
- do not replacing protected binaries from another computer or build.
- do not using unofficial activation, patching or proxy tools to bypass the integrity check.
- While resolving it, do not use unofficial activation tools, patched binaries, copied stores, disabled integrity checks or hand-edited signed data; they can create a second tamper condition.
Correcting the producing condition
Schedule a controlled reboot and verify the new policy/cache generation afterward. Preserve the original store, event export, hashes and licensing inventory until the operation succeeds and the expected state survives any required restart.
Representative case: A servicing update changes boot-time licensing policy while the system remains running.
Verification after correction
Repeat the operation that originally produced it, not merely a UI refresh. Confirm the exact product/object completes, review LicenseStatus and LicenseStatusReason when applicable, and check that no related boundary replaces it.
Regression testing, retain one failing fixture that reproduces “policy changes that require reboot were detected while preparing the kernel-mode licensing cache” and one passing fixture that changes only the decisive precondition; this avoids mistaking a broad reset for verification.
Technical references
- System File Checker — reference for it evidence collection and post-repair verification.
- Repair-WindowsImage — technical contract for the subsystem producing it.
- Software Licensing provider — official platform context used to interpret it.
- Windows SDK constants — supported state, API or recovery information relevant to it.
Looking for a different code? Search another status or error code.