Windows Update error 0x80070643: the real fix for KB5034441
This error hits during KB5034441 or KB5034440 installs because the Windows Recovery partition is too small. The fix is resizing it manually.
If you're on Windows 10 22H2 or Windows 11 22H2/23H2 and seeing error 0x80070643 when trying to install the January 2024 security update KB5034441 (or KB5034440), you're not alone. The error pops up after the download completes, during the install phase, and the system rolls back with no changes. The typical trigger: you have BitLocker enabled (even just device encryption) and the recovery partition is smaller than roughly 800 MB.
Why this happens
Microsoft pushed a fix for a BitLocker bypass vulnerability (CVE-2024-20666) through the WinRE (Windows Recovery Environment) update. The patch needs more space in the recovery partition—about 250 MB free on top of the existing WinRE files. Most OEMs ship recovery partitions at only 500–600 MB total, so there's not enough room. The update fails silently because Windows won't expand a partition without explicit instructions. Error 0x80070643 is a generic "installation failure" code, but in this specific case, it's 100% about partition size.
The fix: resize the recovery partition
Skip the sfc /scannow and DISM restorehealth. They don't fix disk layout. The real fix is shrinking your main C: partition by ~800 MB and giving it to the recovery partition. Here's how to do it with Windows built-in tools—no third-party software needed.
Step 1: Disable BitLocker (if enabled)
BitLocker locks the partition so diskpart can't touch it. Open an elevated Command Prompt (Admin) and run:
manage-bde -status
If BitLocker is on for C:, disable it with:
manage-bde -off C:
Wait for decryption—you'll see "Decryption in Progress" but it finishes fast on SSDs. Check with manage-bde -status until it shows "Protection Off".
Step 2: Shrink C: to free up space
In the same Command Prompt, run diskpart. Then:
list disk
select disk 0
list partition
select partition 2 (or whatever partition C: is—usually partition 2 or 3)
shrink desired=800 minimum=800
The shrink command carves 800 MB of unallocated space right after C:. If it fails with "not enough space", try a smaller number like 500 MB. You need at least 250 MB free, but 800 MB gives room for future updates.
Step 3: Delete and recreate the recovery partition
Now find the recovery partition—usually the last one, around 500–600 MB, type "Recovery partition". List partitions again with list partition. Identify it by size. Then delete it and recreate it in the free space:
select partition x (x = your recovery partition number)
delete partition override
create partition primary
format quick fs=ntfs label="Recovery"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac" (for GPT disks)
gpt attributes=0x8000000000000001
If you're on MBR (older BIOS systems), replace the set id with:
set id=27
The override flag forces deletion of protected partitions. The set id tells Windows this is a recovery partition. The gpt attributes line hides it from Explorer and marks it as required.
Step 4: Reapply the WinRE updates
Exit diskpart with exit. Then:
reagentc /enable
reagentc /info
You should see "Windows RE status: Enabled". Re-run Windows Update and KB5034441 should install cleanly.
What if the fix still fails?
Three things to check. First, verify the recovery partition is now at least 800 MB—run diskpart and list partition again. If it's smaller, the shrink didn't create enough space. Second, if BitLocker re-enabled itself automatically (some enterprise policies do that), disable it again before retrying. Third, if you're on a system with RAID or Intel Optane, the partition layout might be different—run list disk and check if disk 0 is really your boot drive. In rare cases, the recovery partition lives on a separate disk. Adjust the select disk step accordingly.
If you're still stuck after all this, the update itself might have been superseded. Check for a newer cumulative update (like February 2024's) that includes the same fix. The partition size issue is permanent—once expanded, future updates won't choke on this.
Was this solution helpful?