| Previous | Next |
| SL_E_VL_INFO_PRODUCT_USER_RIGHT | SL_I_NONGENUINE_GRACE_PERIOD_2 |
SL_I_NONGENUINE_GRACE_PERIOD
Where this licensing result is produced
SL_I_NONGENUINE_GRACE_PERIOD belongs to license state, grace and validity. The producing mechanism is 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. The important boundary is: genuine validation placed the installation in the first valid non-genuine grace state before enforcement or notification transition.
The stored HRESULT is 0x4004F065. Keep that value, the symbolic name, and the target Activation ID together; converting it to a generic “Windows is not activated” status discards the stage that selected the next diagnostic step.
Minimum evidence for a defensible diagnosis
Record GenuineStatus, LicenseStatusReason, partial key/channel, validation event and remaining grace. 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.
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.
The diagnostic fork is precise: the OS is temporarily operating under a non-genuine transition; it is not a normal activation grace period. A broad instruction to “try another key” or “check the Internet” would discard the more specific condition already established by the code.
A practical investigation order
- Select the exact licensing product or Activation ID that returned this result; do not rely only on the first line of
slmgr /dlv. - Confirm the mechanism in use: 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.
- Prove the code-specific condition by collecting: record GenuineStatus, LicenseStatusReason, partial key/channel, validation event and remaining grace.
- Apply the distinction “the OS is temporarily operating under a non-genuine transition; it is not a normal activation grace period” before choosing a key, network, certificate, firmware, time, or entitlement repair.
- Change one relevant precondition, rerun one activation/evaluation operation, and verify the resulting LicenseStatus and LicenseStatusReason.
Targeted fix
Recovery should preserve entitlement and state rather than erase symptoms. In this case, resolve the invalid or blocked license source and reactivate with a legitimate entitlement before expiry; then query the same product instance and retain the post-fix this result HRESULT and status.
Representative failure: A validation check detects an invalid key and starts a bounded remediation period.
Nearby results that require a different response
| Result | Different condition |
|---|---|
SL_I_NONGENUINE_GRACE_PERIOD_2 | Relative to this result: the installation is in the second defined non-genuine grace category used by the licensing state machine. |
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. |
SL_I_OOB_GRACE_PERIOD | Different condition: the product is operating in its initial out-of-box grace period before activation is required. |
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 “genuine validation placed the installation in the first valid non-genuine grace state before enforcement or notification transition” 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 — diagnostic and operational context.
- WMI properties for volume activation — supported tools and state fields used to verify the resulting state.
- Slmgr.vbs activation options — Microsoft guidance for the activation mechanism represented by this HRESULT.
- Microsoft activation error-code troubleshooting — platform behavior relevant to this HRESULT.
Looking for a different code? Search another status or error code.