| Previous | Next |
| SL_E_SERVICE_RUNNING | SL_E_INVALID_PRODUCT_KEY_TYPE |
SL_E_SLP_INVALID_MARKER_VERSION
What Windows has already determined
SL_E_SLP_INVALID_MARKER_VERSION identifies a specific point in OEM firmware activation: OEM activation that binds an OEM key and certificate or firmware marker to the edition and manufacturer data embedded by the device maker. Its diagnostic consequence is that the firmware OEM marker version is incompatible with the licensing implementation evaluating it.
Telemetry should retain 0xC004F07C, 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.
Minimum evidence for a defensible diagnosis
The decisive record is to capture marker/SLIC revision, OS version, firmware version, manufacturer support matrix and edition/key channel. Before changing the system for this HRESULT, add the following context:
- Product identity for this HRESULT: installed key channel and edition.
- Activation context for this HRESULT: OEM certificate presence where the mechanism requires it.
- State at failure for this HRESULT: hardware or firmware change preceding the failure.
- Correlation evidence for this HRESULT: system manufacturer/model and firmware version.
- Change history for this HRESULT: presence and version of the relevant ACPI licensing table or firmware marker.
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 for this HRESULT do not belong in public tickets. Partial keys, hashes, thumbprints, IDs, timestamps, and state transitions are normally enough to correlate the failure.
The diagnostic fork is precise: the marker is present and parseable; its version compatibility is the failing property. A broad instruction for this HRESULT to “try another key” or “check the Internet” would discard what this HRESULT already established.
This result should be read against these rules: for this HRESULT: A missing marker, malformed marker, missing certificate, and wrong marker version are different evidence states and are not repaired by changing KMS discovery settings. for this HRESULT: Legacy OEM SLP activation validates an OEM key and OEM certificate against the manufacturer-specific SLIC data in firmware; later OA3 systems use a firmware-injected product key workflow.
Checks in the order that matters
- Identify whether this result came from key installation, activation, renewal, validation, certificate selection, offline deposit, or status query.
- tie that call to ACPI firmware tables, SLIC or OA3 marker, OEM certificate/key channel, edition, system manufacturer and firmware version.
- capture the proof needed for this specific result: capture marker/SLIC revision, OS version, firmware version, manufacturer support matrix and edition/key channel.
- use the related-code comparison below to avoid correcting the wrong layer.
- retest with a fresh operation generation and confirm that no parallel retry or stale response can overwrite the result.
Important distinctions
| Result | Different boundary |
|---|---|
SL_E_SLP_OEM_CERT_MISSING | Relative to it: the legacy OEM SLP installation lacks the OEM certificate needed to pair the key with firmware SLIC data. |
SL_E_SLP_BAD_FORMAT | Relative to it: the OEM licensing data found in firmware cannot be parsed or validated in the required SLP format. |
SL_E_SLP_MISSING_SLP_MARKER | Relative to it: the firmware licensing table exists, but the manufacturer-specific SLP marker required by the installed OEM license is absent. |
These values can appear in the same deployment but are not interchangeable. Preserve the first exact result in the failing operation; later notification, retry, or state-query codes may only describe the consequence.
Actions that usually make this harder to diagnose
- While diagnosing it, avoid assuming a motherboard replacement preserves the original OEM binding automatically. That action changes evidence for this HRESULT without correcting the established boundary.
- avoid injecting unofficial firmware tables or certificates. The result already narrows the problem more precisely.
- 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.
Recommended handling
Resolve this code at its producing layer: use manufacturer-supported firmware and an OS/license combination designed for that OEM activation generation. 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: An old OEM marker is evaluated by an installation expecting a different SLP marker revision.
Verification after the change
Verification for this HRESULT should include a failing fixture for “the firmware OEM marker version is incompatible with the licensing implementation evaluating it” and a passing fixture after the narrow correction. Reboot or restart only when the documented mechanism requires it, and confirm that the state persists afterward.
Technical references
- Microsoft OEM activation error guidance — Microsoft guidance for the activation mechanism represented by it.
- OEM Activation 3.0 system — platform behavior relevant to it.
- Microsoft activation error-code troubleshooting — diagnostic and operational context for this HRESULT.
- Activate Windows — supported tools and state fields used to verify it.
Looking for a different code? Search another status or error code.