| Previous | Next |
| SL_E_VL_MACHINE_NOT_BOUND | SL_E_SLP_MISSING_SLP_MARKER |
SL_E_SLP_MISSING_ACPI_SLIC
What this result narrows down
SL_E_SLP_MISSING_ACPI_SLIC belongs to OEM firmware activation. The producing mechanism is OEM activation that binds an OEM key and certificate or firmware marker to the edition and manufacturer data embedded by the device maker. The important the boundary is: the legacy OEM SLP path cannot find the ACPI SLIC table required to validate the OEM key and certificate.
The stored HRESULT is 0xC004F057. 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.
Keep the mechanism’s contract in view: 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. In addition, the second rule for this HRESULT is: 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.
Evidence to preserve before changing anything
The decisive record is to capture firmware table inventory, manufacturer/model, BIOS/UEFI version, motherboard replacement history, key channel and OEM certificate. Before changing the system for this HRESULT, add the following context:
- Product identity for this HRESULT: hardware or firmware change preceding the failure.
- Activation context for this HRESULT: system manufacturer/model and firmware version.
- State at failure for this HRESULT: presence and version of the relevant ACPI licensing table or firmware marker.
- Correlation evidence for this HRESULT: installed key channel and edition.
- Change history for this HRESULT: OEM certificate presence where the mechanism requires it.
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.
Choose recovery by the producing stage
| Result | Different boundary |
|---|---|
SL_E_SLP_MISSING_SLP_MARKER | Relative to this result: the firmware licensing table exists, but the manufacturer-specific SLP marker required by the installed OEM license is absent. |
SL_E_SLP_BAD_FORMAT | Relative to this result: the OEM licensing data found in firmware cannot be parsed or validated in the required SLP format. |
SL_E_SLP_OEM_CERT_MISSING | Relative to this result: the legacy OEM SLP installation lacks the OEM certificate needed to pair the key with firmware SLIC data. |
When it appears with related results, order them by timestamp and Activation ID. The earliest code at the producing boundary usually carries more diagnostic value than a later summary state.
How to test the failing boundary
- Preserve it,
0xC004F057, timestamp, caller, and the exact licensing method. - read the current product state before making changes, including key channel, LicenseStatusReason, and relevant time or binding data.
- test the producing boundary directly: capture firmware table inventory, manufacturer/model, BIOS/UEFI version, motherboard replacement history, key channel and OEM certificate.
- do not continue until the evidence supports this distinction: missing SLIC data differs from a present table whose marker contents are malformed.
- perform the targeted action, then repeat the same query/activation path and compare state, events, and expiry/renewal information.
The most useful separator is this: missing SLIC data differs from a present table whose marker contents are malformed. That it distinction determines whether the next action belongs to key/edition selection, the activation endpoint, certificate policy, firmware, trusted time, or persistent licensing state.
Actions that usually make this harder to diagnose
- While diagnosing it, avoid injecting unofficial firmware tables or certificates. That action changes evidence for this HRESULT without correcting the established boundary.
- avoid assuming a motherboard replacement preserves the original OEM binding automatically. 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.
Corrective direction
Use the narrow remediation: restore manufacturer-supported firmware for the licensed device or activate with a legitimately acquired non-SLP key. Avoid simultaneous key changes, store resets, service restarts, and network changes because they make it impossible to identify which precondition mattered.
Representative failure: A motherboard replacement or generic firmware image removes the OEM SLIC table expected by the installed image.
Verification after the change
A useful it test records the before/after values for the exact Activation ID. It should prove that the correction removes “the legacy OEM SLP path cannot find the ACPI SLIC table required to validate the OEM key and certificate” without replacing it with a different key, KMS, certificate, OEM, Store, or validity failure.
Technical references
- Microsoft OEM activation error guidance — platform behavior relevant to it.
- OEM Activation 3.0 system — diagnostic and operational context for this HRESULT.
- Microsoft activation error-code troubleshooting — supported tools and state fields used to verify it.
- Activate Windows — Microsoft guidance for the activation mechanism represented by it.
Looking for a different code? Search another status or error code.