| Previous | Next |
| SL_E_STORE_UPGRADE_TOKEN_NOT_PRS_SIGNED | SL_E_STORE_UPGRADE_TOKEN_NOT_AUTHORIZED |
SL_E_STORE_UPGRADE_TOKEN_WRONG_VERSION
The activation stage represented here
SL_E_STORE_UPGRADE_TOKEN_WRONG_VERSION identifies a specific point in Store upgrade licensing: authorization of a Store-delivered edition upgrade against the installed Windows edition, active product identity, version and signing level. Its diagnostic consequence is that the Store upgrade token authorizes a Windows version different from the currently installed version.
This result is HRESULT 0xC004E02D. Pair it with the selected product/Activation ID and operation name so later logs do not attribute an add-on, edition, or volume-license result to the base Windows product.
What to collect from the affected system
Capture OS version/build, token version target, purchase date/channel, upgrade history and base edition. Before changing the system, add the following context:
- Product identity: upgrade token issue time and target edition/version.
- Activation context: edition servicing and Software Protection events.
- State at failure: current Windows edition and build.
- Correlation evidence: activation state and partial product key.
- Change history: Store account/entitlement correlation without credentials.
The surrounding licensing model prevents two common misdiagnoses. An edition-upgrade entitlement is evaluated against the current base license and installed OS identity; downloading a token does not make it valid for every edition or build. Wrong edition, Product ID, version, signing level, missing token, and authorization failure represent different mismatches and require different evidence.
Diagnostic sequence
- Begin with the operation that emitted this result and its target Activation ID.
- Inventory base edition, target edition, Store upgrade token, active Product ID/key channel, OS build/version, signing level and account entitlement; this establishes whether the request was aimed at the intended product and activation channel.
- Use events and tool output to demonstrate: capture OS version/build, token version target, purchase date/channel, upgrade history and base edition.
- Rule out the adjacent case: a token can match edition and account but still be outside the supported version range.
- After the targeted fix, verify both the immediate HRESULT and the persistent licensing state after service restart or reboot when relevant.
How to correct the producing condition
The appropriate correction is to re-download or purchase the upgrade entitlement that covers the installed Windows version. Keep the original evidence until a subsequent status query confirms that the intended Activation ID reached the expected state.
Representative failure: A token retained from an earlier Windows release is applied after a major version change.
This result is actionable because a token can match edition and account but still be outside the supported version range. Automation handling it should route the result to the owner of that layer rather than starting every recovery path at once.
Nearby results that require a different response
| Result | Different condition |
|---|---|
SL_E_STORE_UPGRADE_TOKEN_NOT_AUTHORIZED | Different condition: the Store entitlement could not be authorized for the current account, device or license context. |
SL_E_STORE_UPGRADE_TOKEN_NOT_PRS_SIGNED | Different condition: the upgrade token does not satisfy the signing level expected by the installed Windows image. |
SL_E_STORE_UPGRADE_TOKEN_WRONG_PID | Different condition: the Store upgrade token is bound to a Product ID that does not match the currently active base license. |
Actions that usually make this harder to diagnose
- Avoid changing edition packages before preserving the original activation and entitlement state.
- Avoid reinstalling the same token without checking the base edition and Product ID.
Verification after the change
Verification should include a failing fixture for “the Store upgrade token authorizes a Windows version different from the currently installed version” 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
- Activate Windows — supported tools and state fields used to verify the resulting state.
- Windows subscription activation — Microsoft guidance for the activation mechanism represented by this HRESULT.
- Microsoft activation error-code troubleshooting — platform behavior relevant to this HRESULT.
- SoftwareLicensingProduct WMI class — diagnostic and operational context.
Looking for a different code? Search another status or error code.