Tech Community Live: Windows edition
Jun 05 2024, 07:30 AM - 11:30 AM (PDT)
Microsoft Tech Community

KB5034441 fails to install with error code 0x80070643.

MVP

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.

52 Replies

@PRSGroupITNo, she seemed to make it fairly clear that she was speaking on behalf of someone else who apparently didn't want to be clearly identified.

I'm speaking on behalf of everyone dealing with this update and the frustration we all have. We're on month two with no good resolution other than potentially destroy your computer. I was trying to be diplomatic about my feedback. What I said here: "What you are asking your Microsoft patchers to do with this update is not acceptable and not attainable by your Windows 10 patching audience." still stands. This is feedback TO Microsoft.
Yes, I know. I wrote that site and did the video.

@Susan Bradley It's a great article. Very in-depth and detailed ,and I think you're spot-on in your criticism of Microsoft for the way they handled this update.

 

I've found in most cases, the problem isn't that the partition is too small for the updated WindowsRE, but that it's too small to apply the update in-place. If WindowsRE is updated outside of the recovery partition, it can be returned with space to spare. The method I described above, which may not work in every case, temporarily moves the WindowsRE files to the system (C:) drive where the update can succeed--providing C: has adequate space--then returns the files back to the hidden recovery partition.

 

I'm not sure if space would be a problem if we mount the recovery partition and perform an in-place, offline update to Winre.wim, but if so, the file could always be manually copied out, updated offline, and copied and back in. Microsoft supports offline updates using dism (https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-update-to-winre?view=wind...).

 

I can't imagine why Microsoft released the update that created this problem in the first place, but it's even more puzzling why they recommended a solution that involved a risky process of resizing a system partition and deleting the recovery partition.

Maybe they dont have another solution :)@PRSGroupIT 

Here's what doesn't make sense to me:
1. The risk of this vulnerability is in the enterprise space. Yet the patch isn't released to WSUS or on the Microsoft catalog site - those are the two landing spots for more enterprise patching.
2. One could argue that in this era of cloud first that WU is the the right target channel, but it's also offered up to EVERY Windows 10 HOME pc that probably doesn't have a TPM, doesn't have bitlocker anyway (they can only do drive encryption and down on that platform it's probably not enabled by default. So why not
3. have a more targeted deployment to ONLY those Windows 10 pro with bitlocker enabled. To release it to Windows 10 Home/Consumers that could possibly make their systems unbootable poking around their partitions is being more damaging to the consumer/home segment. There is little to no risk to a segment of patchers that problem aren't vulnerable to this security issue in the first place.

As a FYI it was recommended to me to provide feedback to Microsoft in this venue. So I was trying as best as I could to be respectful. I am the long time patcher. So when I say "Feedback from a long time patcher": That's me I am talking about. I have been patching systems and computers and remember when Code Red hit the Internet and I couldn't figure out why ebay was so slow. Since before Microsoft update was a thing. Since before Patch Tuesday was on a Tuesday.

@PRSGroupITI 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.

@Jagerbomber If the recovery partition is the wrong type, then windows does not accept it and it automatically creates hidden folder C:\Recovery where the recovery files are stored, when the WinRE enablement command is given. Command triger automatic file copy function. This is something I have learned the hard way. Because of this, the WinRE partition can also point to the wrong partition.

 

In my case, I fixed the Recovery partition type to the correct one and Windows accepted it. Microsoft's own instructions made the wrong type of partition and I followed them exactly. Because of this, the recovery partition was broken and the new location of WinRE became automaticly C:\Recovery hidden folder. In the case of an MBR disk, Microsoft's own instructions create a recovery partition whose ID is actually 7. The MBR recovery partition ID must be 27 and windows does not accept the ID number 7. The situation with a GPT disk is different and chaos occurs when the instructions for GPT and MRB disks are mixed together. GPT is needed on hard drive size is over than 2TB, because the MBR disk maximum limit is broken. This can cause a problem if the physical Windows hard disk needs to be copied to a larger than 2TB hard disk and the old hard disk is saved as MBR type.

@Arto_Montonen If the recovery partition is the "wrong type"?  The partitions were created by MICROSOFT during the windows 10 install media for EVERY machine I have that refuses to apply this update.  So please explain how the recovery partition can be "the wrong type", or even the wrong size for that matter.

The problem is in Microsoft's own manual instructions, which it guides to make changes. In the case of MRB disk, they destroy the entire Recovery partition operation on all computers. Microsoft own istructions make ID 7 partition, but Recovery partition ID is 27 in MBR disk. Windows rejects the MBR disk recovery partition if its ID number is 7. Windows rejects the MBR disk recovery partition if its ID number is 7, which is caused by Microsoft's own incorrect instructions. Microsoft tries to make the ID 27, but it fails and the ID is 7. How to change ID 7 to ID 27 can be found when you read the entire message thread. I try to tell how to fix that all **bleep** what hapen. GPT format needen over 2TB disk, because MBR Disk limits are not enough. Over limit is 2TB and then GPT is only option, if I'm right.

@Arto_MontonenI'm that fix will break windows..

@bobcat6231 

:)

On many computers I have a -> error for this patch, but other updates install correctly and the computers work fine.

I believe that Microsoft, unfortunately for Windows10 -> will not fix this during a standard update, only upgrading to Windows11 is a hassle-free solution if your computer meets the technical requirements for Windows11.

@Arto_Montonen  

I've seen your tips and I'm wondering if the end user who doesn't know what configuration they have

your computer's motherboard and does not understand what GPT or MBR is, or UEFI, should you take the steps you recommend?

@Azucho98 

ID 7 is not ID 27 very simple and windows does not accept ID 7 as a recovery partition if the disk type is MBR format,

 

C:\WINDOWS\system32>diskpart

 

Microsoft DiskPart version 10.0.19041.3636

 

Copyright (C) Microsoft Corporation.

 

On computer: AMON-P9

 

DISKPART> list disk

 

Disk ### Status Size Free Dyn Gpt
-------- ------------- ------- ------- --- ---
Disk 0 Online 279 GB 1024 KB
Disk 1 Online 279 GB 0 B
Disk 2 Online 279 GB 0 B

 

DISKPART> sel disk 0

 

Disk 0 is now the selected disk.

 

DISKPART> list part

 

Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 Primary 100 MB 1024 KB
Partition 2 Primary 278 GB 101 MB
Partition 3 Recovery 783 MB 278 GB

 

DISKPART> sel part 3

 

Partition 3 is now the selected partition.

 

DISKPART> det part

 

Partition 3


Type : 27 <---- There is ID number
Hidden: No
Active: No
Offset in Bytes: 299245764608

 

Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
* Volume 2 NTFS Partition 783 MB Healthy Hidden

 

DISKPART> set id=27 <- This is a command that fix ID number of the MBR disk when correct disk and partition is selected. Do not do this if a GPT disk is in use, as it will not work with a GPT disk. This only works with an MBR disk.

 

DiskPart successfully set the partition ID.

 

DISKPART>exit

 

C:\WINDOWS\system32>reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Information:

Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition3\Recovery\WindowsRE
Boot Configuration Data (BCD) identifier: d66960a7-4bb6-11eb-bde1-d046185bc8ce
Recovery image location:
Recovery image index: 0
Custom image location:
Custom image index: 0

REAGENTC.EXE: Operation Successful.


C:\WINDOWS\system32>reagentc /disable
REAGENTC.EXE: Operation Successful.


C:\WINDOWS\system32>reagentc /enable
REAGENTC.EXE: Operation Successful.


C:\WINDOWS\system32>reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Information:

Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition3\Recovery\WindowsRE
Boot Configuration Data (BCD) identifier: 192e780d-d480-11ee-beaa-485b395dfa49
Recovery image location:
Recovery image index: 0
Custom image location:
Custom image index: 0

REAGENTC.EXE: Operation Successful.


C:\WINDOWS\system32>exit

 

Boot Configuration Data (BCD) identifier changes if a change is made to the revovery partition. I didn't even change the place. I disabled and enabled and got a new ID number.

Actually what is missing in https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-t...
if no recovery partition is there, then need to create one and if no winre path displayed by reagentc then need to assign one by creating a new winre.wim from source( ISO) and lastly deleting the software distribution folder from windows directory before resuming update
https://www.windowslatest.com/2024/01/15/windows-10-kb5034441-fails-with-a-0x80070643-error-but-ther...

@Susan Bradley I have a WRE of 509MB and still get this error. Plus the fixes here are beyond the scope of most users.

@Susan Bradley Hi, this tutorial helped me :): https://youtu.be/2mw6IA9Wfis

HOW TO FIX ANY WINDOWS UPDATE ERROR CODE / Ako OPRAVIŤ CHYBY vo Windows Update / Thank you for the SUBSCRIBE https://www.youtube.com/@dominik.kozmali, it helps motivate me to create and move on :) LINK mentioned in the video: https://www.microsoft.com/software-download/windows10 If the given ...

@PRSGroupIT 

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.