| Previous | Next |
| SL_I_NONGENUINE_GRACE_PERIOD_2 | SL_I_TIMEBASED_VALIDITY_PERIOD |
SL_I_STORE_BASED_ACTIVATION
What the licensing code means
The actionable meaning of SL_I_STORE_BASED_ACTIVATION is tied to license state, grace and validity. At the Software Protection Platform state machine that evaluates whether a license is active, in a grace or validity interval, out of tolerance, expired, non-genuine, or in notification, Windows determined that the current product activation is backed by a Store-delivered license rather than a conventional installed key channel alone.
Telemetry should retain 0x4004F401, this result, and the affected Activation ID. The same computer can expose several licensing products, and a state read from the wrong instance can contradict the operation that actually failed.
Checks in the order that matters
- Begin with the operation that emitted this result and its target Activation ID.
- Inventory Activation ID, LicenseStatus, LicenseStatusReason, GracePeriodRemaining, EvaluationEndDate, GenuineStatus, trusted time and hardware binding; this establishes whether the request was aimed at the intended product and activation channel.
- Use events and tool output to demonstrate: record edition, Store entitlement/account correlation, Product ID, LicenseStatus and device association without collecting credentials.
- Rule out the adjacent case: this is an informational activation source; scripts should not overwrite it simply because no conventional full key is available.
- After the targeted fix, verify both the immediate HRESULT and the persistent licensing state after service restart or reboot when relevant.
Two platform rules are especially relevant to this result. Grace expiration, validity expiration, hardware out-of-tolerance, non-genuine state, and notification mode have different causes and transitions even when the user sees a similar activation banner. Informational licensing HRESULTs can describe a valid grace or time-based state even though the value is not S_OK; callers should inspect severity and state rather than treating every nonzero code as failure.
This result is actionable because this is an informational activation source; scripts should not overwrite it simply because no conventional full key is available.
Data that identifies the actual cause
Record edition, Store entitlement/account correlation, Product ID, LicenseStatus and device association without collecting credentials. Before changing the system, add the following context:
- Product identity: LicenseStatus and LicenseStatusReason for the exact Activation ID.
- Activation context: GracePeriodRemaining and EvaluationEndDate.
- State at failure: trusted time and recent time-service events.
- Correlation evidence: hardware or firmware changes affecting binding.
- Change history: activation channel, partial product key and last successful activation/renewal.
When investigating it, protect secrets while collecting evidence. Full product keys, complete IID/CID values, private keys, PINs, challenge blobs, account credentials, and unredacted certificate material do not belong in public tickets. Partial keys, hashes, thumbprints, IDs, timestamps, and state transitions are normally enough to correlate the failure.
Recommended handling
Resolve this code at its producing layer: preserve the Store entitlement and use the supported account/device recovery path if activation must be restored. A successful command is not enough by itself; verify the stored licensing state and any renewal, validity, or binding data affected by the operation.
Representative failure: A licensing inventory sees an activated device with a Store license and no reusable retail key to export.
Do not collapse these related states
| Result | Different condition |
|---|---|
SL_I_NONGENUINE_GRACE_PERIOD_2 | Different condition: the installation is in the second defined non-genuine grace category used by the licensing state machine. |
SL_I_NONGENUINE_GRACE_PERIOD | Different condition: genuine validation placed the installation in the first valid non-genuine grace state before enforcement or notification transition. |
SL_I_OOT_GRACE_PERIOD | Different condition: the license has entered an out-of-tolerance grace interval after hardware or binding change exceeded the normal tolerance. |
The comparison is also useful for tests: each branch should have a fixture that produces its own HRESULT and verifies the expected persistent licensing state.
Actions that usually make this harder to diagnose
- Avoid resetting licensing state merely to hide an expired or non-genuine condition.
- Avoid interpreting a positive informational HRESULT as an activation failure without checking LicenseStatus.
Verification after the change
Verification should include a failing fixture for “the current product activation is backed by a Store-delivered license rather than a conventional installed key channel alone” and a passing fixture after the targeted fix. Reboot or restart only when the documented mechanism requires it, and confirm that the state persists afterward.
Technical references
- SoftwareLicensingProduct WMI class — Microsoft guidance for the activation mechanism represented by this HRESULT.
- WMI properties for volume activation — platform behavior relevant to this HRESULT.
- Slmgr.vbs activation options — diagnostic and operational context.
- Microsoft activation error-code troubleshooting — supported tools and state fields used to verify the resulting state.
Looking for a different code? Search another status or error code.