0xC004D307: Maximum Rearms Exceeded and the Grace Timer Is Gone

Fix it now

The remaining rearm count on this installation has reached zero, so slmgr /rearm will not reset the licensing timers again. Microsoft publishes no meaning for 0xC004D307, but the count itself is readable on the machine and settles it. Once it is zero, the only route that ends the countdown is activating with a key you hold.

cscript //nologo %windir%\system32\slmgr.vbs /dlv
cscript //nologo %windir%\system32\slmgr.vbs /xpr

1. Find the remaining rearm count line in the /dlv output. If it reads zero, no command raises it and nothing on this page will.
2. Check whether a rearm was even the right idea: if a valid key is already installed, run slmgr /ato instead and troubleshoot whatever code that returns.
3. If the rearm appeared to do nothing rather than fail, check HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\SkipRearm. Microsoft documents that /rearm does nothing when that value is 1.
4. Install the key you are entitled to and activate: cscript //nologo %windir%\system32\slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX, then /ato.

A clean installation resets the counter, but it also erases the system drive. That is a real option for a lab machine and a poor one for anything with data on it.

If the machine activates, you can stop here. If you want to know where the rearms went, or you are hitting this while building an image, the next section is the useful part.

Why it happens

A rearm resets the licensing timers so an unactivated installation gets its grace period back. It exists for deployment: when an administrator builds a reference image, installs software and tests it, the clock is quietly running down, and a rearm ships the image to users with a full period rather than the remains of one. It was never a licensing mechanism, and the count is capped and held where the operating system protects it.

Microsoft does not publish a meaning for 0xC004D307, or for the three companion codes in this record. What it does publish is the thing that actually settles the question: the detailed licence output carries a remaining rearm count, and slmgr /rearm is documented as resetting the activation timers. Read the count. A zero there is worth more than any code, and it is the one number in this article that cannot be argued with.

There is a second reason a rearm appears to fail that has nothing to do with the count, and it is easy to miss. Microsoft documents that slmgr /rearm does nothing at all if the registry value SkipRearm under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform is set to 1. On a machine built from someone else’s image that value may well be sitting there, and the symptom is a rearm that returns without changing anything.

Full reference

The sysprep story, corrected

Guidance written for Windows 7 says that generalising an image consumes a rearm, that you only get three, and that the fix is the SkipRearm setting in the answer file. That was true then and it is not the situation now. Microsoft documents a Sysprep count limit of 1001 on Windows 8.1 and Windows Server 2012 and later – it was 3 on Windows 7 and Windows Server 2008 R2 – and after 1001 runs you must recreate the image. On the same page it describes SkipRearm as something you used in previous versions of Windows to reset the activation clock when running Sysprep, and adds that if you are using a volume licensing key or a retail product key you do not have to use it, because Windows activates automatically.

The practical consequence for anyone building images today: if your reference image has run out of something, check which counter you have actually exhausted before you rebuild. A Sysprep count and a rearm count are different numbers with different limits, and advice written for the old ones is still circulating widely.

Reading the licensing timers

Microsoft documents the registry value that disables rearm as SkipRearm under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform. That is the only condition Microsoft states under which slmgr /rearm silently does nothing, and it is worth checking before concluding the count is exhausted.

Activating a machine with no route to Microsoft

Older guidance for an isolated machine said to run slui 4 and telephone the activation centre. Microsoft’s current offline activation page says that if you are shown a telephone number you should not call it. The installation ID and confirmation ID exchange still works, but the confirmation ID now comes from the product activation portal at aka.ms/WindowsActivate.

1. Get the installation ID with slmgr /dti, or from the option on the activation page that displays it.
2. Submit it at aka.ms/WindowsActivate and take the confirmation ID returned.
3. Finish with slmgr /atp <ConfirmationID> and confirm using slmgr /dli.

What is not worth trying

• Registry edits circulated for resetting the rearm counter. The count lives in the protected store, and the values people share either do nothing or leave the licensing service broken.
• Repeated rearms in the hope that one takes. If the count is zero it stays zero.
• Reinstalling Windows purely to reset the counter on a machine that holds data. It works, and it is a poor trade against the price of a licence.
• Assuming an in-place upgrade restores the licensing state. Nothing Microsoft publishes says it does, so do not plan around it.
• Chasing the companion codes. None of 0xC004D301, 0xC004D302 or 0xC004D303 has a published meaning, and the rearm count answers the question they are being asked to answer.

Every code this article covers

Confirm the fix worked

1. slmgr /dli reports Licence Status: Licensed.
2. slmgr /xpr reports permanent activation rather than a remaining period.
3. The personalisation options in Settings are no longer greyed out.
4. Reboot and re-check, so you know the state was committed rather than held in memory.

Questions people ask about this