| Previous | Next |
| SL_E_POLICY_CACHE_INVALID | SL_E_SLP_NOT_SIGNED |
SL_E_INVALID_RUNNING_MODE
The exact failure boundary
HRESULT 0xC004F029 is exposed as SL_E_INVALID_RUNNING_MODE by the local Software Protection Platform. The code says more than the friendly message: the Software Protection service is being started or used in an OS mode that does not support this operation.
A local licensing operation can fail while loading a package, verifying a signature, resolving policy, authorizing a right, registering an event or changing service state. Each boundary is narrower than the final activation status shown in Settings. The code is not interchangeable with the service stopping or already running in a supported mode.
AllStat records “The Software Licensing Service cannot be started in the current OS mode”. That identifies the official outcome; the additional value is the producing object, evidence set, nearby conditions and safe verification path.
How the request reaches this stage
| Stage | Role |
|---|---|
| Product instance | Application ID and Activation ID identify the exact licensed object. |
| License inputs | Packages, dependencies, signatures and policies feeding this result are loaded for that object. |
| Requested transition | The right, property, event, plug-in or service operation that returns this result is evaluated. |
| Commit or status | The intended state cannot be trusted or committed while this result remains unresolved. |
A later unlicensed, notification or grace-state message describes a consequence. Preserve the earliest event carrying this HRESULT for the same product object or service request.
What the constant itself tells you
- The result is local to Software Protection Platform and should be tied to one product object, not the computer in general.
- validation rejected the named object; it was present but not acceptable.
- The suffix names the object or transition to inspect before any broad activation reset.
- Its HRESULT severity is failure; later status messages can describe only the resulting state.
Inputs worth preserving
| Evidence | Question answered |
|---|---|
| Application ID, Activation ID and product name | Which Application ID and Activation ID returned the code? |
| LicenseStatus, LicenseStatusReason and grace values | Was the failure during package load, policy evaluation, authorization or service maintenance? |
| first API/slmgr method and earliest Security-SPP event | Is the named object absent, invalid, mismatched, duplicated or in the wrong lifecycle state? |
| sppsvc state, boot session and concurrent maintenance | Can caller identity and elevation be captured before changing state? |
| caller identity and elevation | Does the evidence support “record Safe Mode/WinPE/audit setup context and perform the operation in normal supported Windows” rather than the service stopping or already running in a supported mode? |
Redact full keys, activation blobs, account tokens, private certificate material and raw hardware identifiers. Partial keys, hashes, IDs and UTC timestamps retain correlation value without publishing secrets.
Triage without destroying evidence
- Capture sppsvc state, boot session and concurrent maintenance.
- Prove the distinction between the named boundary and the service stopping or already running in a supported mode before remediation.
- After one supported change, repeat the same operation and compare state, events and response correlation.
- Bind this result to the exact Application ID, Activation ID, edition and partial key.
- Record
0xC004F029, UTC time, caller and the first method or server request that returned it.
REM Evidence context: SL_E_INVALID_RUNNING_MODE
cscript %windir%\system32\slmgr.vbs /dlv
powershell -NoProfile -Command "Get-CimInstance SoftwareLicensingProduct | Where-Object PartialProductKey | Select Name,ApplicationID,ID,LicenseStatus,LicenseStatusReason,PartialProductKey"Use the status output as evidence. Run an activation retry only after the collected state supports the identified prerequisite; blind retries can add quota, throttle or cleanup noise.
Results that require different fixes
| Result | Different condition |
|---|---|
SL_E_POLICY_CACHE_INVALID | the compiled or cached licensing policy cannot be trusted or parsed |
SL_E_SLP_NOT_SIGNED | the license or SLP artifact is expected to be signed but no acceptable signature is present |
SL_E_TAMPER_DETECTED | the local licensing platform detects modification of protected license state or components |
A focused reproduction for this exact result
| Control | Design |
|---|---|
| Failing fixture | Activation tooling is run from an unsupported recovery or setup phase. |
| Single variable | Change only sppsvc lifecycle state at the instant of the operation. |
| Positive control | The operation runs in its required stable service state without force termination. |
| Different result | If the experiment instead proves “the compiled or cached licensing policy cannot be trusted or parsed”, follow that neighboring boundary rather than treating it as it. |
Supported correction and proof
A supported correction is to record Safe Mode/WinPE/audit setup context and perform the operation in normal supported Windows.
Changes that make this code harder to diagnose
- Avoid force-deleting policy, plug-in or license files while sppsvc owns them.
- Avoid using rearm or key replacement as a universal package/policy repair.
- Avoid copying license packages or protected stores from another computer.
Technical references
- SoftwareLicensingService WMI class — official reference for the mechanism surrounding it.
- WMI properties and methods for volume activation
- Slmgr.vbs options
- Troubleshoot Windows activation error codes
Looking for a different code? Search another status or error code.