Windows 10 22h2 security update [KB5034441] fails to install with code: 0x80070643

Thank you - at the risk of appearing a little dense - are you confirming that the OS partition is the one which is listed as Primary, and not the EFI partition listed as System - just need to be absolutely clear.

Also if this is the case would it not be more straightforward to simply shrink partition 3 ( Primary ) and then extend partition 4 (Recovery) using Disk Manager - I just get very nervous using command line editing!

For a tech company whose annual worldwide revenue hit 211.92 billion USD according to Statista and the company's own annual report for the 2023 fiscal year, I find it baffling that this security update made it past quality assurance before live deployment. Not only does this issue just stick out and build unnecessary logs in eventvwr.msc every time it fails, it resolves a critical vulnerability for people who use BitLocker on their machines, and they cannot even install it.

Here is the support article for the broken KB5034441 update:

"KB5034441: Windows Recovery Environment update for Windows 10, version 21H2 and 22H2: January 9, 2024"

If you read through this article and follow the instructions page link it provides, you will find that the solution is to resize the recovery partition on your machine. And that involves shrinking your boot C:\ volume, deleting your recovery partition, and reinstating a new one with more byte space. Like your everyday, casual Windows user is going to understand what all of that means and is going to risk breaking their operating system running a list of shell commands they do not understand.

As someone with very little experience with disk management and PowerShell, I was hesitant following the partition resize instructions out of concern I might break or accidentally remove a partition my system needs to run correctly. But I took the time to research what the commands outlined in the instructions did, and how disk management worked, so that I can comfortably resolve the issue knowing what was happening.

Not every Windows user is going to do that. So you end up forcing thousands who use your OS to encounter this issue and wait for some fix that might come Soon™, for an update you rushed out knowing it had some problem with a solution your software engineers are paid to fix. It is not the community's job to fix problems you are aware of. That is frustrating.

I used PowerShell 5.1 for the above screenshot. The partition that is for the system/EFI is tagged with "System" under category Type. "Primary" is the tag of your operating system's data partition - the one you use for storage, boot, page dump, crash dump, memory dump, and other storage needs.

When you are shrinking your partition, you are shrinking the one with the "Primary" Type tag. It has been suggested throughout this thread to shrink your OS partition past 250 MB, going for 750 MB instead.

So instead of running [shrink desired=250 minimum=250], run [shrink desired=750 minimum=750]. The more byte space your WinRE partition has, the better, but my guess is you do not need too much.

Then follow the rest of the instructions for reinstating a new recovery partition, which should end up being larger than what it was before.

You are on track. My issue is that my EFI partition (partition 3) is to the right of the OS partition due to MBR to GPT conversion a while back. Having this 100MB EFI partition between the OS and Recovery partitions makes it difficult. I got it all working now and Recovery partition is 750MB, but the old Recovery partition of 500MB is just sitting as unallocated space at the end of my disk now...

Dito.. facing this issue this morning on over 500 devices.....