0xC004F013: No Licence Installed – Windows Has No Permission to Run

Fix it now

Microsoft documents 0xC004F013 as SL_E_RIGHT_NOT_GRANTED: the caller does not have permission to run the software. In practice nothing in the licence store grants the running edition the right to run, so the first job is to find out whether the store is damaged or simply empty. Those need different fixes.

cscript //nologo %windir%\system32\slmgr.vbs /dlv
cscript //nologo %windir%\system32\slmgr.vbs /rilc
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

1. Read the /dlv output before anything else. If it cannot describe the installed edition at all, the licence files are the problem. If it describes the edition correctly and reports no key, the store is fine and you need a key.
2. slmgr /rilc reinstalls the licence files that ship with Windows from the system folders. Microsoft documents that it replaces matching licences in the store; it does not remove your product key.
3. After the reboot, install the key for the edition you are running: cscript //nologo %windir%\system32\slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX.
4. Activate with /ato and confirm with /dli.

Do not go looking for the token store to rename or delete. Microsoft documents no such procedure, the location differs between builds, and the supported repair is the sequence above.

If the store repairs and the key activates, you can stop here. If slmgr /dlv still cannot describe the edition afterwards, the next section covers what else to look at.

Why it happens

The name behind this code says more than the message does. Microsoft’s software licensing API reference documents 0xC004F013 as SL_E_RIGHT_NOT_GRANTED, described as the caller not having permission to run the software, and in one place as the policy list being empty. That is a statement about rights and policy, not about a specific missing file, and it is why the error reads so alarmingly while the machine carries on working perfectly.

Windows keeps two related things. The licence files describe every edition and channel the installation is entitled to be, and they ship with the image. The activation state records that an activation actually happened. The licensing service needs a licence granting the right, and something to prove that right was exercised. When the first is missing, damaged or simply describes nothing that covers the running edition, no right is granted and this is what you get.

It is worth knowing which codes mean what, because three of them get used interchangeably and only one of them means what people usually assume. Microsoft documents 0xC004F011 as the licence file not being installed, 0xC004F015 and 0xC004F017 as the licence not being installed, and 0xC004F008 as the licence not being found. Those are the missing-file codes. 0xC004F013 is the right not being granted, which is the outcome rather than the cause.

Full reference

Which licensing code means which thing

Only the first of those is in this article’s record, and it is the one that is least specific. If you can get any of the others out of the machine – from slmgr /dlv, from the activation page, or from the event log – use it, because they name the failure more precisely than 0xC004F013 does.

The repair sequence, and why it is in that order

1. slmgr /rilc first. It is the narrowest operation, it reinstalls only the descriptive licences, and Microsoft documents that it leaves the product key alone.
2. DISM /Online /Cleanup-Image /RestoreHealth next, because it repairs the component store that /rilc reinstalls from.
3. sfc /scannow after DISM, not before. It repairs system files using the component store, so a damaged store makes it far less useful.
4. Reboot, then slmgr /rilc again. Running it once more after the repairs is cheap and often the step that makes the difference.
5. Only then install the key and activate. There is no point supplying a key to a store that cannot describe the edition.

Renaming or deleting files in the licensing store affects every licensed Microsoft product on the machine, not just Windows. Microsoft documents no procedure for doing it by hand, and the location has changed between Windows versions. Use the documented commands, and on a production server use a maintenance window.

When repair does not change anything

• Confirm the machine really is running the edition you think. slmgr /dlv names the product; winver names the edition and build. They disagree more often than you would expect.
• Check whether the installation is an evaluation or preview build. Neither carries a licence for the full product, and no amount of store repair invents one.
• Check the Application log for Software Protection Platform entries around the time of the failure. A service that logs errors as soon as it starts is a different problem from one that runs and refuses a request.
• Confirm the Software Protection service is running and set to start automatically with a delayed start.
• If the machine was previously activated by an unofficial tool, treat a rebuild from clean media as the safer route. Those tools modify more than the licensing state.

Do not copy licence files between machines

It gets suggested, and it produces a worse problem than the one you started with. The licences are tied to the build and edition of the installation they came from, and slmgr /rilc already reinstalls the correct ones from the local system folders at no risk. If /rilc cannot find them, the component store is the thing to repair, not another computer to raid.

Every code this article covers

Confirm the fix worked

1. slmgr /dlv describes the edition and channel correctly.
2. Licence Status reads Licensed and a partial product key is shown.
3. slmgr /xpr reports permanent activation rather than a countdown.
4. Reboot and re-check, to prove the state was written to the store rather than held in memory.

Questions people ask about this