0xC004F050 and 0xC004C001: Windows Says This Product Key Is Invalid

Fix it now

Both codes say the key was refused, in two different places. 0xC004F050 is the local licensing service reporting an invalid product key before any network traffic. 0xC004C001 is Microsoft’s activation server reporting the same thing after the request arrived. Which one you have decides whether to check your typing or your supplier.

cscript //nologo %windir%\system32\slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
cscript //nologo %windir%\system32\slmgr.vbs /ato
cscript //nologo %windir%\system32\slmgr.vbs /dli

1. Type the key rather than pasting it. Microsoft names em dashes substituted for hyphens as a documented cause of 0xC004F050, and that substitution is invisible in most mail clients.
2. Check the edition you are running with winver and compare it with what the key was sold as.
3. If the /ipk line fails, the key never left the machine. You are looking at a format, product or edition problem you can fix.
4. If /ipk succeeds and /ato then returns a 0xC004C code, the request reached Microsoft and was refused there. Stop retrying and read the next section.

Do not run slmgr /upk to clear the old key first. It leaves the machine Unlicensed after the next restart, and if the new key turns out to be wrong you have made the problem worse rather than better.

If the key installs and activates, you can stop here. If not, the next section explains which of the two rejections you have and what each one rules out.

Why it happens

A Windows product key is not a random string. It encodes the product and channel it belongs to and carries enough internal structure for a mistyped key to be caught without asking Microsoft anything. That local check is what produces 0xC004F050: Microsoft documents it as the Software Protection Service reporting the product key is invalid, and gives three causes – a typo, a key for a pre-release build used on a released one, and em dashes substituted for the hyphens when the key was copied out of a document.

0xC004C001 comes from the other end of the exchange. Microsoft documents it as the activation server determining that the specified product key is invalid. The key passed the local structure check, was sent, and was refused. That rules out an entire class of fixes at once: nothing you do to the local licence store, the token cache or the network configuration alters a decision made on Microsoft’s side.

0xC004E016 is the companion code that catches people, because it looks like a server code and is not one. Microsoft documents it as the Software Licensing Service reporting the product key is invalid, and its consumer list gives it as a key for a different version or edition of Windows. It is a local mismatch you can correct, and treating it as a refusal from Microsoft sends you back to your supplier over something that was never their fault.

0x803FA065, 0xC004C801 and 0xC004C802 are not published. What can be said about 0x803FA065 is that it behaves as a server-side refusal in the 0xC004C001 class, so retyping the key will not move it; the two 0xC004C8 codes appear during the licensing exchange and are diagnosed the same way.

Full reference

Reading the two rejections apart

Where the key came from usually explains the code

Why cscript matters here

slmgr is a script, and run bare it reports through the default Windows script host – which means a pop-up dialog you cannot copy text out of. Microsoft’s own edition-upgrade documentation invokes it as cscript.exe c:\windows\system32\slmgr.vbs /ipk <key>. Use that form for anything where you need to read the code rather than just see that something failed. It is the difference between diagnosing this error and guessing at it.

What not to do while you are working through this

• Do not run slmgr /upk speculatively. Microsoft documents that the system enters the Unlicensed state after the next restart, and a machine sitting in a grace period loses that state.
• Do not reinstall Windows to clear a server-side refusal. The refusal is not stored on your computer, so a clean installation presents the same key and receives the same answer.
• Do not retry a refused key repeatedly. It achieves nothing and can add a second failure that confuses the diagnosis.
• Do not assume a cheap key is fake because it failed locally. A local failure is usually an edition or channel mismatch, and those are fixable.
• Do not change the edition before you have read slmgr /dli. Half the edition changes performed in response to this error were not needed.

If the key is genuinely refused at the server

At that point the useful question is what documentation exists behind the key. A supply chain that can produce an invoice naming the product and the licence type can also escalate a refusal. One that cannot, usually cannot. That is the practical difference between the two ways of buying a Windows licence, and it only becomes visible on the day something goes wrong.

Every code this article covers

Confirm the fix worked

1. slmgr /dli names the edition and channel you expect.
2. Licence Status reads Licensed rather than Notification or Unlicensed.
3. The last five characters of the partial key shown match the key you meant to install.
4. Settings > System > Activation reports Windows as active.
5. Reboot once and re-check, since a key applied but not committed reverts on restart.

Questions people ask about this