Microsoft is working to fix a known issue causing 0x80070643 errors when installing the KB5034441 security update that patches the CVE-2024-20666 BitLocker vulnerability.
While the security issue was resolved during this month's Patch Tuesday, deploying KB5034441 on systems with a Windows Recovery Environment (WinRE) partition that's too small will fail and mistakenly show generic '0x80070643 - ERROR_INSTALL_FAILURE' error messages instead of the correct CBS_E_INSUFFICIENT_DISK_SPACE error.
As a workaround, until a fix is available, the company provides customers with affected systems detailed—and quite complex—instructions on how to resize their WinRE partitions on its support website.
If creating a new WinRE partition large enough to complete this update fails, you can run reagentc /enable to re-enable the partition.
"Devices attempting to install the January 2024 Windows Recovery Environment update (KB5034441) might display an error related to the size of the Recovery Environment's partition. We are working on a resolution and will provide an update in an upcoming release," Microsoft says in an update to the Windows release health dashboard.
"It might be necessary to increase the size of the WinRE partition in order to avoid this issue and complete the installation. Note that 250 megabytes of free space is required in the recovery partition."
Script to update WinRE with BitLocker fixes
Microsoft has also released a PowerShell script that helps automate updating the WinRE partition to fix the CVE-2024-20666 flaw that allows for BitLocker encryption bypass.
The script addresses the known issue causing KB5034441 install failures on Windows 10 systems, leaving the devices vulnerable to attacks exploiting the BitLocker flaw that provides threat actors access to encrypted data.
When executed, it mounts the WinRE image, applies an architecture-specific Safe OS Dynamic Update you have to first download from the Windows Update Catalog, unmounts the image, and then reconfigures WinRE for BitLocker service if the BitLocker TPM protector is present.
After running the script, you should also use Microsoft's Show or Hide Tool to hide the KB5034441 update to prevent Windows Update from repeatedly trying to install the faulty update and displaying 0x80070643 errors.
If you decide to resize the WinRE partition manually, it's highly recommended that you back up your data, given that there's always a chance that your system's partitions may be damaged during the process.
Comments
GT500 - 4 months ago
I ran into that issue as well, and followed the instructions to manually resize my recovery partition to fix it, only to run into an error. Apparently if I had read more thoroughly I might have noticed where it said (in the block of seemingly unimportant text at the top of the page) that it only works if your recovery partition is the last partition on the drive.
Fortunately I have spare USB flash drives, so I loaded a GParted live ISO onto one and booted into their little mini Debian boot "disk" where I was able to move the partitions where they needed to be for this nonsense to work. Thank God my partition layout was GPT, because if it was MBR apparently moving certain partitions (such as the one Windows is installed on) can cause your system to fail to boot. I think the warning from GParted said that was fixable, and pointed to the FAQ on their website, but I don't remember offhand what it said.
Seriously Microsoft, your stupid Windows install disk is what created the partitions, and it's what decided to put the recovery partition first. You had to know that most Windows 10 users were limited to half a gig of total storage space on the recovery partition, and that a large percentage (if not most) of the recovery partitions with Window 10 installs were at the front of the drive, before you pushed this stupid update out. After all it was the geniuses that work for you that set the Windows 10 installer up that way to begin with, not to mention the Windows 7 and Windows 8 installers for people who upgraded instead of doing a fresh install like I did.
Winston2021 - 4 months ago
WHY are they even trying to install it on Windows Home machines to fix a BitLocker vulnerability when there is no BitLocker capability in Windows Home?
DrkKnight - 4 months ago
That was my question also, or what about those that do not have Bitlocker capability or a recovery partition?
Something doesn't smell right.
GT500 - 4 months ago
Is this happening on Windows 10 Home? The issue happened on Windows 10 Pro for me.
JohnC_21 - 4 months ago
This was my problem also, the WinRE partition was at the front of the disk, before the EFI and System partitions. Apparently earlier versions of Windows 10 placed the WinRE partition at the beginning of the disk. See the below link. Since I don't use Bitlocker, I just hid the update.
https://www.bleepingcomputer.com/forums/t/793160/kb5034441-error-0x80070643/?p=5603245
Misure2 - 4 months ago
FYI this is also effecting some Server 2022 based systems installing KB 5034439
lteak - 4 months ago
I have Win10 Pro, but have always had BitLocker turned off on all my drives (too complicated for me, and just one more thing to go wrong). My hard disk does have a Q:\ recovery drive which is of course unused since BitLocker is off.
Nonetheless, I am getting this same install error for KB5034441.
So am I being forced to use BitLocker now, and have my drive encrypted?
sysut1 - 4 months ago
This worked for me using this tool to " hide " the update " . Maybe it will work for you -
https://www.majorgeeks.com/files/details/wushowhide.html
NJJoe - 4 months ago
If I had a nickel for everytime I had to hide a bad update...
sysut1 - 4 months ago
You'd have a few hundred dollars
NJJoe - 4 months ago
LOL, true! For us IT workers, it's unfortunately all too common when an update fails, just hide it and move on for at least 30 days and check back again to see it was fixed or removed all together. It's just SOP. In fact this one happened to me last night updating a few PCs I administer. I didn't even blink. Just logged out and went about the rest of my evening. I'm certainly not wasting time going through that laborious and clunky repetition exercise.
ArloSmurf - 4 months ago
I have the same problem on Windows 10.
The windows recovery update failed. I followed the recommended procedure to fix the problem.
I shrank the boot partition, deleted the recovery partition, created a new recovery partion, formatted it NTFS, and marked it "Windows RE tools".
REAGENTC cannot find the new recovery partition.
Windows DISKMANAGEMENT GUI sees it and reports "healthy partition".
REAGENTC /INFO shows no location for the recovery partition, as in the previous user's screen shot.
I tried us8ng REAGENTC /SETREIMAGE /PATH \\?\\GLOBALROOT\HARDDISK0\PARTITION4\RECOVERY\WINDOWSRE, but I cannot get the path syntax correct. The MSLearn article only explains how to point to a recovery file, not to a partition.
Tapio - 3 months ago
Solution that worked for me (Win10):
As told, the first requirement is to have 250 megabytes of free space in the recovery partition.
But because of some disk (/partition) operations (like move, migrate etc.) the Recovery partition may not be recognized by the system. In elevated (admin) cmd.exe please type: reagentc /info. In reply you may get 'Windows RE status: Disabled', which means not recognized. To fix this, I copied from the Recovery partition \Recovery\WindowsRE\ReAgent.xml -file to %windir%\system32\Recovery\ -folder (by replace). That after cmd.exe command 'reagentc /info' did find Windows RE status as 'Enabled'.
Restarted Windows and then the Security update (KB5034441) in Windows update had no more errors.
RaceJay - 3 months ago
Hi'all..!
I had this issue and i manage to solve it.
Bottom line is, the core reason for the update to fail has nothing to do with the recovery partition amount needed.
However, for the fix to work, it does some space available on that recovery partition, if you so inclined to keep it that way, separate from the other the disk partitions.
In my personal case, i keep the recovery files on the "C:\Windows\System32\Recovery" folder which, point accepted, is not a very good idea indeed.
Prior to fix the problem and after finding the current path of the recovery folder ( using the command REAGENTC.EXE in a run-as-admin command prompt window ), i noticed the reason; the Winre.wim file wasn't there.
Went on to mount a Windows 10 Home 64-bit ISO on a SSD connected via USB ( can also be a flash drive as well, 16GB minimum ) and extract the file ( in fact it doesn't just extract 1 file, but a whole Windows installation ) by running the appropiate DISM command ( there are several posts online describing this step ).
Afterwards, just copied the 2 files from the "<connected drive>:\Windows\System32\Recovery" folder ( there's the Winre.wim file and a executable one also ) to the path shown through the fore-mentioned REAGENTC.EXE in a command prompt window ran-as-administrator.
Tried again the Windows Update feature and there it was; it installed correctly and is now showing in the "View update history" section.
So this was it, any questions regarding this, or some part of it in need of clarification, just fire away :-)
Cheers!
( Final note: just noticed that Tapio already have done what i recently did :-) )