| Previous | Next |
| SL_E_EUL_NOT_AVAILABLE | SL_E_VL_NOT_ENOUGH_COUNT |
SL_E_VL_NOT_WINDOWS_SLP
Where this licensing result is produced
Interpret SL_E_VL_NOT_WINDOWS_SLP inside volume activation and KMS/ADBA, not as a generic activation failure. Windows has reached the volume-activation path that selects KMS, Active Directory-based activation, or another volume channel for a particular Activation ID; in this case, the installed Windows lineage or qualifying-license state does not permit activation with the supplied volume key.
Telemetry should retain 0xC004F035, 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.
The surrounding licensing model prevents two common misdiagnoses. A Generic Volume License Key identifies a KMS or Active Directory-based activation client; it is not a retail key and does not activate directly against Microsoft hosted activation services. KMS discovery, KMS-host activation, the client-count threshold, and client renewal are separate checks, while ADBA relies on a suitable activation object in Active Directory.
How to test the failing boundary
- 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 volume-activation path that selects KMS, Active Directory-based activation, or another volume channel for a particular Activation ID.
- Prove the code-specific condition by collecting: record the currently installed edition, original/qualifying OS channel, upgrade history, Activation ID, and the type of volume key being applied.
- Apply the distinction “this is a qualification/channel problem, not failure to locate a KMS host” before choosing a key, network, certificate, firmware, time, or entitlement repair.
- Change one decisive precondition, rerun one activation/evaluation operation, and verify the resulting LicenseStatus and LicenseStatusReason.
Signals that separate this case from its neighbors
Record the currently installed edition, original/qualifying OS channel, upgrade history, Activation ID, and the type of volume key being applied. Before changing the system, add the following context:
- Product identity: slmgr.vbs /dlv output for the exact Activation ID.
- Activation context: installed key channel and partial product key.
- State at failure: KMS host name, port, DNS SRV answer, current count and required count.
- Correlation evidence: client and host UTC time.
- Change history: AD activation object name/DN and domain/schema level.
When investigating this result, 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.
Nearby results that require a different response
| Result | Different boundary |
|---|---|
SL_E_VL_NOT_ENOUGH_COUNT | Relative to this result: the KMS host is reachable but its current unique-client count has not reached the activation threshold required for this product family. |
SL_E_VL_BINDING_SERVICE_NOT_ENABLED | Different boundary: the local or selected volume-activation binding service is disabled for the requested KMS operation. |
SL_E_VL_KEY_MANAGEMENT_SERVICE_NOT_ACTIVATED | Different boundary: the KMS service exists, but the KMS host key itself has not been successfully activated. |
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.
Do not infer the cause of it from the activation UI alone. This is a qualification/channel problem, not failure to locate a KMS host. Preserve the boundary when converting the HRESULT into user-facing diagnostics.
Recovery without damaging licensing evidence
The appropriate correction is to install or upgrade from a qualifying Windows license and then apply the correct volume activation method for that edition. Keep the original evidence until a subsequent status query confirms that the intended Activation ID reached the expected state.
Representative failure: A machine deployed from inappropriate media receives a GVLK even though the underlying installation does not satisfy the volume-license qualification path.
Actions that usually make this harder to diagnose
- While diagnosing this HRESULT, avoid installing an unrelated key merely to force another activation attempt.
- Avoid treating all volume activation failures as DNS or firewall problems.
- Do not delete licensing stores, edit signed license files, alter firmware markers, bypass certificate checks, or use unofficial activation tools. During investigation, those actions can create a second integrity problem and destroy the evidence needed to repair the legitimate license.
Verification after the change
A useful test records the before/after values for the exact Activation ID. It should prove that the correction removes “the installed Windows lineage or qualifying-license state does not permit activation with the supplied volume key” without replacing it with a different key, KMS, certificate, OEM, Store, or validity failure.
Technical references
- Microsoft volume activation overview — supported tools and state fields used to verify the resulting state.
- Plan for volume activation — Microsoft guidance for the activation mechanism represented by this HRESULT.
- KMS troubleshooting guidance — platform behavior relevant to this HRESULT.
- SoftwareLicensingProduct WMI class — diagnostic and operational context.
Looking for a different code? Search another status or error code.