0xC004F307 and 0xC004F308: Activation Data Invalid or Tampered

Fix it now

Offline activation pairs an installation ID generated on the machine with a confirmation ID issued against it. When the pair is refused, run the whole sequence again from a fresh installation ID rather than trying to salvage the confirmation you already have.

slmgr /dti
slmgr /atp <ConfirmationID>
slmgr /dlv

1. Generate the installation ID with slmgr /dti, which displays it without opening a wizard. Copy it from there rather than reading it off a window you then close.
2. Obtain the confirmation ID against that exact value, in one sitting. For the telephone route, SLUI 04 opens the wizard for activating Windows through the automated telephone system.
3. Apply it with slmgr /atp <ConfirmationID>, entered with no spaces or dashes.
4. Do not install, remove or change the product key between the two steps, and do not reboot in between if you can avoid it.
5. Read the result with slmgr /dlv and confirm the licence status and channel are what you expect.

Microsoft documents a neighbouring code for this exact area: 0xC004F02C, the format for the offline activation data is incorrect, with the check being that the confirmation ID was entered correctly during phone activation. If you have that code, you have a typing problem rather than a licensing one.

If that fixed it you can stop here. If not, the next section covers what is and is not published about these six codes, and the repair sequence for the store underneath them.

Why it happens

When a machine cannot reach Microsoft’s activation service directly, activation becomes a two-step exchange. The machine produces an installation ID, that value goes to the clearing house by telephone or through a portal, and a confirmation ID comes back. The confirmation is issued against the request that produced it. It is not a password, it is not reusable, and it is one half of a pair.

That is why the sequence is unforgiving in practice. Doing the two halves in one sitting, without changing the key and without regenerating the installation ID in between, is the difference between this working and this producing a code. slmgr /dti is documented as displaying the installation ID for offline activation, and slmgr /atp as activating the product using a user-provided confirmation ID. Between them they do the whole job without a wizard, which removes the most common way of accidentally generating a second request.

Be clear about the evidence for the codes themselves. None of 0xC004F307, 0xC004F308, 0xC004F309, 0xC004F024, 0xC004D317 or 0xC004D318 has a published meaning on learn.microsoft.com or support.microsoft.com. Earlier versions of this article described each of them – a confirmation that does not match the request, a payload that failed an integrity check, a protected store that failed a consistency check – and none of those descriptions was sourced. They have been removed. Run slui.exe 0x2a followed by your code to read Microsoft’s own wording on the machine in front of you.

What Microsoft does publish in this area is 0xC004F02C: the format for the offline activation data is incorrect, with the documented check being that the caller ID or confirmation ID was entered correctly during phone activation. It is worth knowing because it is the code most readers of this article actually have, and because it points at the boring cause first – a value entered wrongly – rather than at anything about the licence.

Full reference

What is published about these six codes

The code Microsoft does publish for offline activation is 0xC004F02C – the format for the offline activation data is incorrect – with the documented check being to verify that the caller ID was entered correctly during phone activation. If you are working through a batch of machines and one of them produces that instead, you have found the easy one.

The offline sequence, with the documented commands

Doing the whole thing from the command line rather than the wizard is worth the small extra effort. It keeps the installation ID in your scrollback, it does not depend on a window staying open, and it makes the sequence repeatable across a batch of machines.

Repairing what sits underneath

1. DISM /Online /Cleanup-Image /ScanHealth to see the extent of any component store damage.
2. DISM /Online /Cleanup-Image /RestoreHealth to repair it.
3. sfc /scannow, which repairs system files from that store – so running DISM first is what makes this pass useful.
4. Reboot.
5. If licensing operations still fail: net stop sppsvc, rename tokens.dat under %windir%\system32\spp\store\2.0, net start sppsvc, cscript.exe %windir%\system32\slmgr.vbs /rilc, restart twice.
6. Install the key with slmgr /ipk <key>, then run the offline activation sequence from a fresh installation ID.

Microsoft’s guidance alongside that rebuild is explicit: never use the /upk switch to uninstall a product key, and install a key over an existing one with /ipk instead. Earlier versions of this article opened several remedies with slmgr /upk followed by slmgr /cpky, which drops the machine into an unlicensed state and gains nothing that /ipk does not already do.

Working through a batch of machines

• Do one machine end to end before starting the rest, so that a systematic problem shows up on the first one rather than the fortieth.
• Record the installation ID and the confirmation ID together against the machine name. They are a pair and neither is useful without the other.
• Do not reuse a confirmation ID on a second machine. It was issued against a specific request.
• If several machines in a batch fail identically, look at what they have in common – the same key, the same image, the same clock source – rather than at the offline sequence.

When the sequence is not the problem

There is a version of this that no repair resolves. If the key was never legitimate, or the machine was previously made to look activated by something that modified the licensing components, the platform is refusing for a reason and a cleaner run of the same sequence will refuse identically. The tell is that the repair sequence completes without error and the state comes back unchanged. At that point the missing item is an entitlement, and the next step is a licence rather than another command.

Every code this article covers

Confirm the fix worked

1. slmgr /dlv reports a licence status of Licensed with the channel and partial product key you expect.
2. sfc /scannow completes with no integrity violations.
3. Settings, System, Activation shows a state that matches what slmgr reports.
4. The confirmation ID you used was issued against the installation ID currently on the machine, not an earlier one.
5. Reboot and re-check, since a manufactured state often reverts on restart while a genuine activation does not.

Questions people ask about this