0xC004F027 and 0xC004FE00: Windows Detected Licence Tampering

Fix it now

These four codes turn up on machines whose licensing components were interfered with, usually by an activation tool. Microsoft publishes no meaning for any of them, so treat the situation rather than the code: find and remove what did this, repair the system, then license the machine properly.

slui.exe 0x2a 0xC004F027
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
slmgr /ckms

1. Read what slui.exe 0x2a prints for the code you actually have. It is Microsoft’s own text for your build and the only authoritative description available.
2. Find what produced the state. Look for scheduled tasks you do not recognise running as SYSTEM, services with no publisher and no description, and activation utilities in the installed programs list.
3. Review the machine’s trusted root certificate store for authorities you cannot account for, using the local machine certificates console.
4. slmgr /ckms clears any pinned activation host from the registry and restores auto-discovery, which is what an emulator leaves behind.
5. Repair the component store with DISM, then run sfc /scannow, reboot, and install a genuine key with slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX followed by slmgr /ato.

Install the genuine key over whatever is there. Microsoft’s licensing repair guidance says not to use slmgr /upk, and /ipk validates the key against the installed edition and replaces the existing one.

If that fixed it you can stop here. If not – and before you decide it did – the next section explains why clearing the codes is the easy part of this problem.

Why it happens

Ordinary activation errors describe a licence that is wrong. This family turns up when the licensing components find something about their own data or the code around them is not what it should be. The licensing service holds its data in a protected store and the security processor checks the binaries it depends on; when either check fails against a signature rather than against content, what you get is a report of interference rather than a refusal to license.

There is an important limit on what can honestly be said here. Microsoft publishes no meaning for 0xC004F027, 0xC004FE00, 0xC004D501 or 0xC004D502 on learn.microsoft.com or support.microsoft.com, and it does not publish that any of them is produced by activation cracks. Earlier versions of this article stated both. What is left is still worth reading, because the situation these codes cluster around is real and the response to it is the same whether or not the vendor has named the code: an installation whose licensing state was manufactured rather than issued.

The genuine states the platform distinguishes are a short list, and one of them is the tampered flag on a licence being set. That is a published property of the licensing model, and it is the closest thing to a formal statement that this category exists. It does not tell you which code corresponds to it, which is why this article works from evidence on the machine instead.

The part that matters beyond activation is what the tools that produce this state actually do. They do not politely edit a registry value. They run with full system privilege, install services or drivers, create scheduled tasks so the machine can be re-activated on a timer, place a certificate in the trusted root store so that a fake licensing host is believed, and sometimes replace signed system files. You cannot see what else that code did, because the only account of it is the tool’s own description of itself.

Full reference

What is published, and what is not

The platform does publish that a licence carries a tampered flag among its genuine states, alongside genuine, invalid licence, offline and unchanged since last check. That is the vocabulary the licensing model actually uses. It is not a mapping to these four values, and this article will not pretend otherwise.

The clean-up, in order

1. Identify and remove whatever created the state: scheduled tasks, services, drivers and installed utilities.
2. Remove any certificate planted in Trusted Root Certification Authorities.
3. Clear any pinned activation host with slmgr /ckms.
4. Repair the component store: DISM /Online /Cleanup-Image /RestoreHealth.
5. Repair system files: sfc /scannow. Running DISM first gives sfc a good source to repair from.
6. Reinstall the licence files: slmgr /rilc, then reboot.
7. If licensing still fails, run the documented tokens.dat rebuild: stop sppsvc, rename tokens.dat under %windir%\system32\spp\store\2.0, start sppsvc, run slmgr /rilc, restart twice.
8. Install a genuine key with slmgr /ipk <key> and activate with slmgr /ato.

Treat this as a security incident rather than a licensing inconvenience. Code ran on this machine with the highest privilege available, from a source that had every reason to hide what it did. On any machine holding work data, credentials or access to a company network, the defensible response is a clean installation from trusted media and a password change for the accounts used on it – not a repair sequence that leaves the original code in place.

Microsoft’s guidance for licensing store repair says not to use slmgr /upk to uninstall a product key, and to install the intended key over the existing one instead. That applies here too: /upk drops the machine into an unlicensed state and gains you nothing that /ipk does not already do.

What a real volume activation infrastructure looks like

It is worth knowing what you are comparing against. A genuine Key Management Service host is a Windows Server you run, holding a KMS host key issued against your own volume agreement, publishing a _vlmcs service record into DNS and answering clients on TCP 1688. Active Directory-based activation is the other supported route and needs no host at all: an activation object is published into the forest and domain-joined clients running their generic volume licence key take activation from it. Both are things you can point at and audit. An emulator pretending to be a host is not, which is why the licensing components react to it the way they do.

Deciding whether to rebuild

• Personal machine, nothing sensitive on it, and you accept the risk knowingly: cleaning up may be a reasonable choice.
• Work machine, or any machine that has held credentials for a company network: rebuild from trusted media and change the passwords used on it.
• A machine where sfc cannot repair the same files after a successful DISM run: rebuild, because you are no longer repairing a known-good baseline.
• A machine where the task or service comes back after removal: rebuild. That is persistence, not a leftover.

Every code this article covers

Confirm the fix worked

1. sfc /scannow completes and reports no integrity violations.
2. slmgr /dlv reports a licence status of Licensed with the key you installed and a channel you can account for.
3. No scheduled task or service reactivates the machine on a timer, and no unfamiliar root certificate remains.
4. slmgr /dlv shows no pinned activation host you did not configure.
5. Install pending Windows updates, reboot, and confirm activation still holds afterwards.

Questions people ask about this