KB5034441 – I ran MS’s script

Topic

New Reply

[Susan Bradley]

I don’t know if the following is of any value to anyone, but following are the results of my running MS’s script

I was very interested in this update because I wasn’t sure my Recovery Environment was quite right after migrating my OS from a spinner to a SSD. So, I was hoping MS would come along with an update to fix anything that was wrong. So I backed everything up, took a deep breath, and ran a couple scripts. The images below will probably be hard to read here, but feel free to save them if you want to enlarge and examine them.

First I ran Action1’s ‘Data Gathering’ script which reports a little information about the RE partition.. (Did I read about Action1 here?) Anyway, here is the scripts output:

Oh–I had dropped a few imagies in here. Can we not include images?

Action1 also has a script to resize the partition, but I decided to go with MS’s script. (Yeah, I know. To my potential detriment. LOL)

Next, MS’s script. First you have to d/l a .cab file for your OS version. The script will ask you to provide the location of that file on your computer.

When yu launch Powershell you must select ‘Run as Administrator’ even if you are logged in with administrator rights, otherwise the run will fail.

It took a few minutes for the script to complete. I noted in the output that the script seemed to determine that my O/S vs was 2004 which is incorrect as I am on 22H2. Maybe they only care about “min” vs 2004? Or maybe it meant that the last RE update was done by vs 2004? [shrug] It said it the operation completed successfully, so I guess it did what it was supposed to do. (It left a log in C:\Windows\Logs\DISM\dism.log.) Below is o/p of the script:

I used MiniTool to then explore the partition. The original file ‘Modified’ dates in the RE partition varied anywhere from 2012 to 2022. The later dates seem to coincide with past Feature Updates. After executing the script I see that some of them are now dated 2024, so apparently it did update some things.

What is curious, though, is that the script did not resize the partition. It was originally 639Mb and it still is, with about 77Mb free. All I can figure is, between the OS partition and the RE partition there is 46Gb of “Unallocated” space which I’m pretty sure is SSD overprovisioning space. So, maybe the script conluded that any upcoming updates can just expand into that space as needed. (I haven’t taken the time to reverse engineer their script.)

Any thoughts are welcome.

 

Moderator Edit: to remove remove garbage from pictures improperly inserted. Pictures must be added as “Attachments” (see screenshot below) and are limiter to 1MB.

• This topic was modified 1 year, 3 months ago by Susan Bradley.
• This topic was modified 1 year, 3 months ago by Rob Kay.
• This topic was modified 1 year, 3 months ago by Bob99.
• This topic was modified 1 year, 3 months ago by PKCano.
• This topic was modified 1 year, 3 months ago by PKCano.

Reply | Quote

Replies

Reply | Quote

Rob Kay wrote:

46Gb of “Unallocated” space

Unallocated is not over provisioning, it’s a potential mistake in the original installation of Windows.
Did you install Windows or did come like that?

An SSD needs partitions aligned on a boundary so it is not uncommon to see a small (a few hundred MB) amount wasted, but that is too much.
You can move and expand the partition with the free Minitool Partition Wizard.

cheers, Paul

Reply | Quote

I feel pretty confident that the space was created by Samsung Magician as overprovisioning space. The partition was not there before. The partition size is right there at 10%. Note that the image shown in the clip is from ‘Help’, not from my machine.

From Samsung Magician ‘Help’ (see pic)

Reply | Quote

OP shows as reduced disk capacity, not unused space.
Unused space is space you can actually do something with, OP is reserved for internal disk use and is never available.

BTW, over provisioning is a waste of disk space on a consumer disk unless you regularly fill it up with new data – in which case you need a bigger disk. SSDs do NOT have short lives.

cheers, Paul

1 user thanked author for this post.

TechTango

Reply | Quote

I have two Samsung SSD drives with 10% over provisioning.  MiniTool Patrician Wizard show exactly the same amount as unallocated.  One of them is nearly empty, so I changed the amount of OP to 15%.  MiniTool Patrician Wizard now shows the exact 15% as unallocated.  Whether it is a bug or a feature in one program or another, the OP is showing as being reported as unallocated.

1 user thanked author for this post.

Paul T

Reply | Quote

It may be leftover from a manufacturer recovery partition – one with the original Windows files to allow a complete rebuild.

cheers, Paul

Reply | Quote

Rob Kay wrote:

What is curious, though, is that the script did not resize the partition.

Unlike the KB update, which uses the recovery partition itself as it’s “scratch space” to store everything while applying the update, the script uses Window’s default temp folder (normally C:\Windows\Temp) as it’s “scratch space”.

Since the update only increases the used space on the recovery partition by ~28 MB, the script can apply the update without needing to increase the size of the existing partition.

What I really don’t understand is, since Microsoft obviously now knows exactly how to apply this fix without having to resize the recovery partition, why haven’t they issued an updated KB that uses this method?!?!

1 user thanked author for this post.

WCHS

Reply | Quote

Very interesting, nOads. So, did you determing that from reading the script? I haven’t had a chance to analyze it yet, but it would be a good exercise. I haven’t done any scripting since back in the days when I worked on a HP-UX system. I’m retired–now I just use batch files for things I need to do. I did enjoy writing scripts, though. Saved me a lot of time updating source code!

Reply | Quote

It’s shown in the “Usage table” on Microsoft’s KB5025175: Updating the WinRE partition on deployed devices to address security vulnerabilities in CVE-2022-41099 page where you get the script itself.

1 user thanked author for this post.

Rob Kay

Reply | Quote

Thank you Moderator!

So attached are the pics cited, in order, from my original post.

1 user thanked author for this post.

Bob99

Reply | Quote

Rob Kay wrote:

maybe it meant that the last RE update was done by vs 2004?

I believe this to be the case. The latest RE available to me in the latest/last version of Macrium Reflect free is from 2004, a Feature update I skipped entirely. See attached screenshot. I rely on bootable USB media for any Windows RE needs I may have.

1 user thanked author for this post.

Rob Kay

Reply | Quote

Rob Kay wrote:

I noted in the output that the script seemed to determine that my O/S vs was 2004 which is incorrect as I am on 22H2.

Windows 10 20H2 (19042), 21H1 (19043), 21H2 (19044) & 22H2 (19045) all use the 2004 (19041) base which includes winre.wim version 10.0.19041, ServicePack 1.

The WinRE update script showed it was updating 2004 because it updated winre.wim version 10.0.19041, ServicePack 1 to 10.0.19041, ServicePack 3920.

2 users thanked author for this post.

Rob Kay, PL1

Reply | Quote

FYI, this might be where I found out about the Action1 scripts I mentioned in the original posts:

https://www.bleepingcomputer.com/news/microsoft/microsoft-shares-script-to-update-windows-10-winre-with-bitlocker-fixes/

Reply | Quote

So, today I went through this on my wife’s Dell Vostro notebook running W10 22H2 also.

Now, in this case, the RE partition on her machine had plenty of free space so I decided to try not running the MS script and just letting Windows Update rip. KB5034441 failed. So, I had to run MS’s script and it completed successfully.

Now, on her machine, with stock OEM partitioning, there are 6 partitions and the RE is on partition 4. Action1 comments that their ‘Data Gathering’ script will fail if the RE partition is not the last partition on the drive as, if it is not the last partition, it is not expandable. I don’t know if that’s necessarily true, but KB5034441 did fail.

Reply | Quote

Rob Kay wrote:

if it is not the last partition, it is not expandable.

Not true if recovery partition is right after C: partition. In that case it can be expanded.

Reply | Quote

I suspect it’s a qualified “not expandable”. All partitions are expandable, at the expense of shrinking / moving other partition(s). “Before C:” makes no difference.

cheers, Paul

1 user thanked author for this post.

PL1

Reply | Quote

Yeah, I don’t know why Action1 would say that.

“The first script is designed to check if WinRE is enabled, determine if it is the last partition on the target drive, and ascertain its current size. Note: This script will not work if the WinRE partition is not the last partition, as it cannot be resized in that configuration.”

https://www.action1.com/fixing-winre-update-issues-for-cve-2024-20666-and-kb5034441/

I know MS’s guidance is to place the RE partition after the OS partition. Then, if a data partition is desireable, place that after the RE partition.

https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions?view=windows-10

Reply | Quote

Paul T wrote:

“Before C:” makes no difference.

Yes, it does.

On my Windows 10 Pro (clean install by OEM) recovery partition is number 1. EFI partition is number 2. Reserve partition number 3. C: partition number 4.

Expanding recovery partition require formatting and rebuilding partitions on the drive.

* If I remember correctly the last time I moved partitions was on a XP PC

Reply | Quote

Rob Kay wrote:

Yeah, I don’t know why Action1 would say that.

Action1 is right. You can’t write a script to move partitions around.

Reply | Quote

Alex5723 wrote:

Expanding recovery partition require formatting and rebuilding partitions on the drive.

Not if you use MiniTool Partition Wizard or similar. It will shuffle your partitions and data without any rebuilding. It is not fast (hours), but it is much faster than rebuilding.

cheers, Paul

1 user thanked author for this post.

Alex5723

Reply | Quote

Out of curiosity, Paul T, if you use MiniTool Partition Wizard or similar (AOMEI, etc.), would it be advisable to first (i.e., pre-changes) disable ( > reagentc /disable ) – and then later (i.e., post-changes) re-enable ( > reagentc /enable ) – the active recovery partition?

Or is this simply unnecessary? Or possibly a bad idea?

Thanks.

Reply | Quote

Any of the partition tools will resize without affecting anything else so you don’t need to worry.

We always recommend you make an image backup first – it’s ’cause we’re paranoid (experienced)!

cheers, Paul

Reply | Quote

The Microsoft script that allows the WinRE Security Update to be installed without resizing the recovery partition disables recovery mode before updating winre.wim (reagentc /disable) and then re-enables it once it’s done (reagentc /enable).

It’d probably be a good idea to follow their lead.

 

Reply | Quote