Downtown Doug Brown

I was recently browsing around on YouTube and stumbled upon this video: Microsoft Confirms it will NOT Fix KB5034441 Error 0x80070643 on Windows 10. The video title got my attention so I figured I’d see what was going on. KB5034441 is a security update for the Windows Recovery Environment to fix a vulnerability that could allow bypassing BitLocker encryption, and some people have been noticing that the update fails to install.

I decided to check my Windows Update history, and sure enough, my computer was affected:

The truth is that I’m not using BitLocker, so the update doesn’t really matter for me. I hadn’t even noticed that it was failing repeatedly. Apparently it had also failed to install on January 11th. Knowing that my computer would continue over and over failing at installing this update bothered me though. It just felt wrong.

Microsoft has already stated they won’t be automatically fixing this issue in a future update. The underlying issue that causes this installation error is that the WinRE partition doesn’t have enough free space for the update. Why a security update needs a bunch of extra disk space, I do not know. And why they would not figure out a way to automatically work around this problem for an issue as serious as bypassing BitLocker, I also do not know. But I won’t pretend to be an expert on that — obviously they know best. They certainly must have their reasons. Resizing partitions can be dangerous — maybe that’s why — the benefit doesn’t outweigh the risk?

Helpfully, Microsoft did provide a couple of solutions fixing this issue: manual Command Prompt instructions, or a script you can run instead. Both of these solutions end up increasing the size of your WinRE partition by an additional 250 MB to make room for the update, by shrinking your system partition by that same amount.

I decided to try the manual instructions — I’m too paranoid to let a script run. Now, am I actually adding any value on top of the instructions that Microsoft already provided by writing this post? At least right now, I think so. You’ll see later. Additionally, I thought my post could be instructive because my setup is a little weirder than what you might see on a stock computer. When I opened diskmgmt.msc by typing that in the Start menu and clicking Create and format hard disk partitions, here’s what it looked like:

I have several internal drives. The first one isn’t actually my system disk. Also, I have two recovery partitions and my 100 MB EFI System Partition is near the end of the disk because my Windows install was originally MBR-based for a legacy boot and I converted it to GPT later. I think my computer is a good example for sharing how I followed Microsoft’s instructions to make my recovery partition bigger. Let’s walk step-by-step through the process together.

I started by opening an admin Command Prompt by typing “cmd” with the start menu up, right-clicking on it, and choosing Run as Administrator.

Next I ran “reagentc /info” to get the current WinRE status:

This told me two things: it confirmed that WinRE is enabled, and it let me know that the actual recovery partition is partition 3 of disk 1, which kind of makes sense. It’s the bigger 554 MB one directly after the system partition in my Disk Management screenshot above. So that 471 MB recovery partition at the very end of the drive is old. Maybe it’s the recovery partition I had before I converted to GPT?

Microsoft’s steps now say to disable the WinRE because we will need to delete it temporarily in order to create a bigger one. To disable it, you type “reagentc /disable”.

With WinRE disabled, now I could go in and mess with partitions using the diskpart utility. I typed “diskpart” in that same admin Command Prompt window, and then followed the instructions, starting with typing “list disk” inside of it.

Yeah, I have a fair amount of disks here. I didn’t know which disk to use off the top of my head, but luckily the output from “reagentc /info” earlier told me that I would need Disk 1. That’s because the Windows RE location contained “harddisk1”. Also, the Disk Management GUI was useful for seeing which disk was which. I chose Disk 1 by typing “sel disk 1”. I feel like I should add that Microsoft’s instructions have a mistake:

There needs to be a space between “disk” and the disk index. The command is “sel disk 1”, not “sel disk1”. Someone with a lot of experience in diskpart would already know that, but I’m sure there are a lot of people out there who don’t. Hopefully someone who might be confused by that will stumble upon my post to resolve any confusion.

I selected Disk 1 and then ran the “list part” command to see the partitions:

Like I said earlier, I have two recovery partitions. It was nice to have the output from reagentc confirming to me that my actual recovery partition was Partition 3. Just to be 100% clear, the reason I knew this was because after harddisk1 in the Windows RE location, the next path element was “partition3”.

Right now though, I’m looking for whatever partition is directly before the recovery partition. That’s the one I needed to shrink in order to make more space. I think in most cases, this is going to be the OS partition. On my computer, this is Partition 2 and it shows up as my C drive.

Following along with Microsoft’s instructions, I selected the OS partition with “sel part 2”. Once again, Microsoft’s instructions are omitting the space between part and 2, so I was sure to add a space.

Now for the scary part: I needed to shrink this partition by 250 MB so that I would have more room to increase the size of the WinRE partition after it. This is done with the following command given by Microsoft:

shrink desired=250 minimum=250

I might have been a little afraid of running that command if I didn’t have a backup available. Maybe that’s why Microsoft doesn’t want to fix this issue automatically. I’m not sure. If the system was powered down during this part of an update, it could spell disaster, at least I think. Unless Microsoft’s partition shrinking code is super duper safe. Maybe someone can chime in and let me know more about that. Anyway, I ran the command.

It took about 20 seconds to complete. I had left Disk Management open in the background, and it automatically updated itself and made it super obvious that the shrinking succeeded:

Now, how do we expand that recovery partition 250 MB to the left? Resizing to the left is a little complicated because you have to move the partition to the left first and then expand it to the right. I’m assuming something like GNU Parted could do it if you booted from a live Linux USB stick, but I stuck with Microsoft’s instructions.

It turns out diskpart can’t move partitions like that. Microsoft instructs you to delete your recovery partition and make a new one filling up all the space instead. So because I had earlier determined my recovery partition was Partition 3, I typed “sel part 3” to choose the WinRE partition, and then deleted it. I know I’m beating a dead horse at this point, but the command is “sel part 3” and not “sel part3” as Microsoft says.

After selecting partition 3, and double checking to make sure it was indeed my recovery partition, I deleted it with “delete partition override”.

Again, Disk Management updated in the background to show I now had 805 MB of contiguous space after my C partition:

Here’s where the instructions differ based on whether you have an MBR disk or a GPT disk. In my case, my disk used to be MBR but I had already converted it to be GPT. As Microsoft says, you can verify this in the “list disk” output by looking for an asterisk next to your disk under the “Gpt” column. So I followed the GPT instructions and ran the following two commands:

create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac

gpt attributes =0x8000000000000001

It might be best to copy and paste these commands one at a time (right-click in the command prompt to paste a command), but if you are going to type it out, there are 14 zeros between the 8 and the 1.

Disk Management’s GUI view of the drive looked great at this point too:

Nerdy details: the first command marks it as a recovery partition. The next command sets the partition attribute flags to mostly zero, but it sets bits 0 and 63. According to Wikipedia, bit 0 means it’s required for the computer to function properly and bit 63 means it shouldn’t have a drive letter assigned.

Next, Microsoft’s instructions told me to format the newly-created partition with the following command:

format quick fs=ntfs label="Windows RE tools"

I feel like I should mention that Microsoft’s page is showing the quotes around Windows RE tools as both being “smart” closing quotes, at least when copying the command out of Chrome and pasting into Notepad. It looks like Command Prompt will correctly convert them to normal quotes when you paste it though. I was scared and typed the command by hand instead, especially after observing Microsoft’s mistakes with the missing spaces earlier.

I was on the home stretch at this point. I ran “list vol” as they suggested and it showed up at the bottom of the list.

The final step was to exit out of diskpart, re-enable WinRE with “reagentc /enable”, and then re-check with “reagentc /info” to make sure it picked the correct recovery partition.

The output of all of those commands looked great. I was slightly worried that it would pick my old recovery partition at the end of the disk instead, but it seemed to know it should pick the new empty Partition 3 that was right after the C partition.

I probably should have rebooted first, but I jumped directly into Windows Update and told it to retry installing the update.

Sure enough, it seemed to install with no problems. I crossed my fingers, rebooted, and went back into Windows Update’s history. All is well now.

I do feel kind of funny essentially just repeating Microsoft’s instructions verbatim on my blog, but I thought the screenshots of the process would be useful for people, and also it’s pretty bad that their instructions are missing spaces. Anybody know how to get ahold of the right folks to fix the spacing issues on Microsoft’s instructions? I submitted feedback on the page at least…

I’m still not sure how I feel about the overall problem here. If it wasn’t a security issue I would care a lot less about it, but it seems bad to me that a security issue allowing a bypass of BitLocker potentially won’t install correctly on a lot of users’ machines. On the other hand, the vulnerability does require physical access so I guess it’s not as dire as other potential security issues out there.

Do any other Windows updates slightly shrink the C drive to make room for another partition? If so, I feel like Microsoft should have done the same thing with this update. Even if they don’t want to destroy the existing WinRE partition contents in order to make more room, couldn’t they dump it to a temporary file on the system drive, delete the partition, make a new bigger one, and then restore the contents of the dump? Anything seems better than just letting the update sit in limbo forever. There must be more to this that I don’t understand. I know from my experience as a software developer that sometimes things which sound easy end up being not so easy in reality.

I hope this post is useful for someone out there!