0x80070643 on KB5034441: the recovery partition is too small to patch

Fix it now

0x80070643 is ERROR_INSTALL_FAILURE, decimal 1603, a generic fatal installation error. Against the recovery environment servicing update it usually means one specific thing: Microsoft’s WinRE update KB states it needs 250 MB of free space in the recovery partition, and layouts carried forward through upgrades often have far less.

reagentc /info

1. Note whether Windows RE status shows as Enabled and which partition holds the image. If it is Disabled, run reagentc /enable and retry the update before anything else.
2. Check the System log in Event Viewer for event ID 4502, ‘Windows Recovery Environment servicing failed’, with an ErrorPhase of 2. That is the published signal that the WinRE servicing attempt failed, and it is a better confirmation than the code.
3. Open Disk Management and look at the recovery partition. Confirm it sits after the OS partition; the resize procedure requires that order.
4. Take a full image backup before going further. If the disk is encrypted, suspend protection and make sure you hold the recovery key.
5. Follow the resize: reagentc /disable, shrink the Windows partition, delete and recreate the recovery partition, then reagentc /enable.

If partition creation fails, or you decide not to extend the partition, run reagentc /enable to put WinRE back before you leave the machine.

If the update installs after the resize, you are done. The next section covers the layouts where a shrink does not help and what to do instead.

Why it happens

The recovery environment is a small bootable Windows image stored in its own partition and registered with the operating system. Updating it is not a matter of copying a file over: the image has to be mounted, the changes applied inside it, and the result committed. All of that needs working space in the same partition that holds the image, on top of the image itself. Microsoft’s WinRE servicing update states the requirement plainly: 250 MB of free space in the recovery partition.

Older layouts did not budget for that. A recovery partition sized when it was created has no reason to grow, and every subsequent update to the recovery image takes a little more of what is left. Eventually an update arrives that will not fit, and it fails on every attempt while ordinary cumulative updates keep installing normally. That pattern, one update failing repeatedly while everything else succeeds, is the characteristic signature.

Be clear about what the code itself says, because a lot of advice about this treats 0x80070643 as a WinRE-specific error. It is not. It is ERROR_INSTALL_FAILURE, decimal 1603, a generic fatal error during installation, and it appears against all sorts of installers. The evidence that ties it to the recovery partition on this particular update is the published space requirement and the event the servicing attempt writes, not the code.

Position matters as much as size. You can only grow the recovery partition by taking space from the partition immediately before it, which on most modern layouts is the Windows partition. Microsoft’s own resize instructions state the requirement outright: the device must have the recovery partition after the OS partition. Where it sits before, shrinking Windows leaves unallocated space on the wrong side and does not help at all.

Full reference

The commands, in the order Microsoft publishes them

reagentc /info
reagentc /disable

diskpart
  list disk
  sel disk <OS disk index>
  list part
  sel part <OS partition index>
  shrink desired=250 minimum=250
  sel part <WinRE partition index>
  delete partition override
  rem GPT disks
  create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
  gpt attributes =0x8000000000000001
  rem MBR disks instead
  rem create partition primary id=27
  rem set id=27
  format quick fs=ntfs label="Windows RE tools"
  list vol
  exit

reagentc /enable
reagentc /info

Replace the placeholders with the numbers list disk and list part show on your own machine. Selecting the wrong disk or partition destroys data with no undo, and copying indexes from any article, including this one, is how that happens.

What each step is for

Reading the evidence rather than the code

• Event ID 4502 in the System log, ‘Windows Recovery Environment servicing failed’, with ErrorPhase 2, is the published signal that this specific servicing attempt failed. Look for it before you plan partition work.
• reagentc /info names the partition holding the image. Compare it against what Disk Management shows.
• Disk Management shows the order of partitions, which is what decides whether a shrink can help.
• Update history gives you the KB number, which tells you whether the failing update is the WinRE servicing one or an ordinary cumulative update that happens to have failed with the same generic code.
• 0x8024200B, WU_E_UH_INSTALLERFAILURE, alongside it says only that the installer failed to install or uninstall one or more updates. It adds no detail of its own.

The three codes in this article

Deciding whether to do the work at all

Partition surgery on a working machine carries real risk, and it is reasonable to weigh it. What you are deferring if you skip it is a hardening update to the recovery environment, which matters most on encrypted laptops, because the recovery side is a route around disk encryption that this update exists to close. On a fleet, redeploying with an image whose layout has room is usually less risky than scripting diskpart across hundreds of machines, and it fixes the problem permanently rather than buying another few years of headroom.

If you do the work by hand, give the partition more than the bare minimum. The recovery image will be serviced again, and a partition sized to exactly today’s requirement puts you back here at the next one.

Every code this article covers

Confirm the fix worked

1. Run reagentc /info and confirm the recovery environment shows as Enabled with a valid location.
2. Open Disk Management and confirm the recovery partition is the size you intended and has free space.
3. Reapply the update and confirm Update history records it as installed.
4. Check the System log and confirm no new event ID 4502 after the change.
5. Boot into the recovery environment once to confirm it actually starts.

Questions people ask about this