Forum Discussion
KB5034441 fails to install with error code 0x80070643.
Feedback from a long time patcher here:
The manner in which this particular update has been handled has been poor in my opinion. The update is only being pushed out to Windows update or Windows update for business and is not on the Microsoft catalog nor WSUS. So this update has been pushed to machines that I would call "lightly" managed or "unmanaged". Some of these impacted machines have no TPM chip nor do they have bitlocker installed so the need for this update is nil.
The communication thus far has been to instruct us to manually attempt to resize partitions which are not easy to do for anyone, and particularly not for a lot of machines. There are few tools that I can see that let us know if we're going to hit this issue other than to attempt to install and see if it fails. The PowerShell script is not something I'd have my 95 Dad want to do to his machine, let alone me wanting to do it to a bunch of machines at the office.
We're now at Friday, right before patching weekend and may I request a lot more communication and perhaps someone going back and adding in detection into the patch to at least not attempt to install on machines that have no tpm chip and do not have bitlocker installed. These machines are not at risk.
What you are asking your Microsoft patchers to do with this update is not acceptable and not attainable by your Windows 10 patching audience.
70 Replies
I've found the easiest and safest workaround for Windows RE update problem is to (1) disable Windows RE, (2) change the Windows RE partition type from "Recovery" to "Primary", (3) enable Windows RE, apply the update, then repeat the first three steps, changing the partition type back to "Recovery". You don't need to resize or delete partitions.
WARNING: The steps below involve making changes to your hard disk's partition table. Any misstep could render your system unbootable and potentially result in data loss. This may not work for everyone. Stop if your results at any step are inconsistent with those shown below. Proceed at your own risk.
From an elevated PowerShell prompt, use reagentc to check the current Windows RE state.
PS> reagentc /info
...
Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsREThe Windows RE status should show Enabled. Make note of the hard disk and partition number.
Disable Windows RE.
PS> reagentc /disable
This should move Windows RE image file Winre.wim from \Recovery\WindowsRE on the hidden partition to C:\Windows\System32\Recovery.
IMPORTANT: This doesn't appear to occur in every case. Verify that Winre.wim exists in C:\Windows\System32\Recovery. If it doesn't, reenable Windows RE with reagentc /enable and stop. This file is normally hidden. Use the -Force parameter with dir (in PowerShell) to see it.
PS> dir C:\Windows\System32\Recovery -Force
Directory: C:\Windows\System32\Recovery
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2/4/2024 3:37 AM 1139 ReAgent.xml
---hs- 8/6/2021 8:26 PM 440718104 Winre.wimUse diskpart to temporarily change the type of the recovery partition. Select the disk and partition using the numbers in the Windows RE location shown above.
PS> diskpart
DISKPART> select disk 0
Disk 0 is now the selected disk.
DISKPART> select partition 4
Partition 4 is now the selected partition.IMPORTANT: Verify that you've selected the correct partition. The selected partition is marked with an asterisk and should show as type Recovery.
DISKPART> list partition
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 260 MB 1024 KB
Partition 2 Reserved 16 MB 261 MB
Partition 3 Primary 237 GB 277 MB
* Partition 4 Recovery 860 MB 237 GBDisplay partition details to show the partition type.
DISKPART> detail partition
Partition 4
Type : de94bba4-06d1-4d40-a16a-bfd50179d6ac
Hidden : Yes
Required: Yes
Attrib : 0X8000000000000001
Offset in Bytes: 255158386688
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
* Volume 2 Windows RE NTFS Partition 860 MB Healthy HiddenChange the partition type from Recovery to Primary (normal).
If the type is 27, this is an MBR partition. Set the type to 7.
DISKPART> set id=7 override
If the type is de94bba4-06d1-4d40-a16a-bfd50179d6ac, this is a GPT partition. Set the type to ebd0a0a2-b9e5-4433-87c0-68b6b72699c7.
DISKPART> set id=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 override
List the partitions to verify that the change was applied.
DISKPART> list partition
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 260 MB 1024 KB
Partition 2 Reserved 16 MB 261 MB
Partition 3 Primary 237 GB 277 MB
* Partition 4 Primary 860 MB 237 GBExit diskpart.
DISKPART> exit
When you re-enable Windows RE, if a valid recovery partition isn't available, reagentc will use C:\Recovery\WindowsRE as the location for the recovery image. If a WindowsRE directory already exists in C:\Recovery, rename it.
PS> dir C:\Recovery -Force
Directory: C:\Recovery
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 12/2/2020 8:57 PM WindowsRE
d---- 3/20/2022 3:10 AM OEM
-a--- 1/12/2021 4:35 AM 1139 ReAgentOld.xml
PS> ren C:\Recovery\WindowsRE WindowsRE.old -ForceRe-enable Windows RE and confirm that the location has changed. Here, it changed from partition4 to partition3, which, in this case, is the OS partition (C:\).
PS> reagentc /enable
PS> reagentc /info
Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition3\Recovery\WindowsREAt this point, attempt to apply the Windows Update. Regardless of success or failure, complete the steps below to reverse the changes made above.
PS> reagentc /disable
PS> diskpart
DISKPART> select disk 0
DISKPART> select partition 4
DISKPART> list partition
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 260 MB 1024 KB
Partition 2 Reserved 16 MB 261 MB
Partition 3 Primary 237 GB 277 MB
* Partition 4 Primary 860 MB 237 GB
For GPT partition
DISKPART> set id=de94bba4-06d1-4d40-a16a-bfd50179d6ac override
For MBR Partition
DISKPART> set id=27 override
DISKPART> list partition
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 260 MB 1024 KB
Partition 2 Reserved 16 MB 261 MB
Partition 3 Primary 237 GB 277 MB
* Partition 4 Recovery 860 MB 237 GB
DISKPART> exit
PS> reagentc /enable
...
Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsREPRSGroupITI got the update installed with your way and I got the Recovery Partition back to Recovery. (I even redid it by recreating it, too) but WinRE still uses the Primary OS partition. It won't seem to go back to the Recovery Partition. Do I even want it to? I got to this thread because I was still getting the error after recreating the Recovery Partition and ended up with 499MB (all Free). Is there going to be issue with future updates if it still says it's using the OS Partition? Winre.wim isn't appearing anymore which surprised me.
Hi PRSGroupIT - could you please reply to Jagerbomber's message? I think Arto has tried twice but appears to be assuming that the recovery partition is not the right type. In my case, the recovery partition IS the right type (GPT = de94bba4-06d1-4d40-a16a-bfd50179d6ac) but reagentc does not use the partition when it is renabled.
Disabling Bitlocker seems to work as well. PRSGroupIT
Good source for a "fix" - or, how to block the update until Microsoft actually fixes it.
https://www.askwoody.com/2024/quick-video-to-showcase-how-to-hide-kb5034441/
which points to the tool (from microsoft) found here: https://blockapatch.com/
- Thank you howzat.
The MS app was easy to use and it found KB5034441 and removed it. It also removed it from being listed in the Settings> Update & Security> View update history - Select
On the 8th April 2024, KB5034441 was listed as an optional update. I chose not to install it! I then successfully updated the major (March) WIN 10 update on both a WIN 10 Pro and WIN 10 Home device . Then I successfully created a USB Recovery Disk.
On the 12th April 2024, I updated both a WIN 10 Pro and WIN 10 Home devices with the April Cumulative update. I noticed that when I created a USB Recovery Disks it took a substantially longer for each device to get to the create button. It also took substantially longer for the finish button to appear. I have no idea what the back ground processes do, but being optimistic MS might have recognised and fixed some or all of the issues listed in this post. KB5034441 fails to install with error code 0x80070643- Note,
After the April Cumulative update. was installed
Sign into the WIN 10 admin user
I used Control Panel> Administration Tools> Disk Clean-up app to delete the large amount of redundant WIN 10 update files. After the Disk Clean-up app is run for the 1st time there were files which consume tens of megabits. Clean up system files button - select. After the Disk Clean-up app is run for the 2nd time there were files which consumed up to 6GB, which can take up to a hour to remove.
I created USB Recover Disks (as administrator). This can take up to 2 hours.
- Yes, I know. I wrote that site and did the video.
This is my suggestion (ignore this error)!
Re: Failure to install update error: 0x80070643 @allmembers - Microsoft Community Hub
This is my way to fix that problem.
I know disk and partition numbers. Disk is number 0 and partition is numeber 3 in my case. That is what I need when i do fix to the revovery partition fix with command prompt and admistrator rights.
C:\Windows\system32>reagentc /disable
REAGENTC.EXE: Operation Successful.
C:\Windows\system32>diskpart
Microsoft DiskPart version 10.0.19041.3636
Copyright (C) Microsoft Corporation.
On computer: YOUR-PC
DISKPART> sel disk 0
Disk 0 is now the selected disk.
DISKPART> sel part 3
Partition 3 is now the selected partition.
DISKPART> det part
Partition 3
Type : 27
Hidden: No
Active: No
Offset in Bytes: 255269535744
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
* Volume 3 Windows RE NTFS Partition 759 MB Healthy Hidden
DISKPART> delete partition override
DISKPART> create partition primary id=27
DiskPart succeeded in creating the specified partition.
DISKPART> format quick fs=ntfs label="Windows RE tools"
100 percent completed
DiskPart successfully formatted the volume.
DISKPART> det part
Partition 3
Type : 07 <- ALERT!. PATITION NUMNER IS 7 NOT 27 WTF!
Hidden: No
ctive: No
Offset in Bytes: 255269535744
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
* Volume 3 Windows RE NTFS Partition 759 MB Healthy
DISKPART> set id=27 <- PARTITION NUMBER IS FIXED!
DiskPart successfully set the partition ID.
DISKPART> det part
Partition 3
Type : 27
Hidden: No
Active: No
Offset in Bytes: 255269535744
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
* Volume 3 Windows RE NTFS Partition 759 MB Healthy Hidden
DISKPART> list part
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 Primary 50 MB 1024 KB
Partition 2 Primary 237 GB 51 MB
* Partition 3 Recovery 759 MB 237 GB
DISKPART> exit
Leaving DiskPart...
C:\Windows\system32>reagentc /enable <- Windows start copying rocovery boot files place where reagentc /info status pointing. That is not easy to expalain, but i think i hit correct point.- Thank you! Works perfect
- Having people "manually" F around with drive partitions is beyond dangerous. If you don't know exactly what you are doing, the potential is there to lose everything on your hard drive. Microsoft needs to release a fix for this mess.
I agree.
I managed to repair the partitions manually with the diskpart program and Microsoft's MBR disk instruction is incorrect and leads to errors, but the GPT disk instruction works. Microsoft made a mistake when it combined the instructions for MBR and GPT disks into one instruction, it led to errors in the MBR disk instruction. Formatting works differently on MBR and GPT disks.
- The January 2024 Windows RE update might fail to install
Status
Confirmed
Affected platforms
Client VersionsMessage IDOriginating KBResolved KB
Windows 10, version 22H2 WI706429 KB5034441 -
Windows 10, version 21H2 WI706430 KB5034441 -
Devices attempting to install the January 2024 Windows Recovery Environment update (the Originating KBs listed above) might display an error related to the size of the Recovery Environment's partition. The Windows Recovery Environment (WinRE) is used to repair or recover from issues affecting Windows.
Resulting from this error, the following message might be displayed.
"0x80070643 - ERROR_INSTALL_FAILURE"
Workaround: 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. Guidance to change the WinRE partition size can be found in KB5028997: Instructions to manually resize your partition to install the WinRE update.
Next steps: We are working on a resolution and will provide an update in an upcoming release.- Seemed like an easy solution--but it didn't work. It did seem to cause the failure to happen more quickly. I remain extremely leery of manually tweaking the disk partitions. I do NOT have the expertise and I believe a juicy mistake will kill the computer.
Rather amazing to me that this problem started more than six months ago in this discussion. Perhaps older from whenever I first encountered it. And it remains unresolved, with fresh reports still appearing. My theory is that Microsoft is merely hoping that the victims' computers will die. Or perhaps the people will die before their computers?
In conclusion, I hate Microsoft even more than before. If that is possible. SusanBradleyGeek I have a WRE of 509MB and still get this error. Plus the fixes here are beyond the scope of most users.
SusanBradleyGeek I do not have BitLocker installed, so don't even need the patch. I do have 522MB free space on my Partition Drive, which ought to be more than ample. Still no successful install.
