I'm trying to fix a 'stuck' Windows Update on a friend's (otherwise fully
updated) Windows 10 laptop. It's the KB5034441. On my own machine I found I
could fix this by manually resizing the WinRE partition (something I know
little about!) as described in KB5028997.

On my friend's laptop, it allowed me to delete the WinRE partition but wouldn't
allow me to recreate it. I understand that's because Bitlocker is running, and
that the operation should (!) succeed if it's suspended.

But the instructions I've found suggested to use a GUI Bitlocker console, and
that doesn't seem to offer the "suspend" option. I'm getting nervous, so I
tried to back up the key. However, the printed output of that process invites
me to compare the "following identifier" with the one displayed on my PC. (Er,
where?) So I tracked down a Device ID for the computer (different) and I can't
find any property for the disk (including using Disk Management) which matches.

I'm astonished that in this day and age MS makes us chase down these rabbit-
holes. For now, I'm left with anallocated space where the WinRE partion was
and the update still won't install. Should i just wait for the next major
update version? Any advice welcome!

--

Phil, London

Philip Herlihy wrote on 3/2/24 8:59 AM:
> I'm trying to fix a 'stuck' Windows Update on a friend's (otherwise fully
> updated) Windows 10 laptop. It's the KB5034441. On my own machine I found I
> could fix this by manually resizing the WinRE partition (something I know
> little about!) as described in KB5028997.
>
> On my friend's laptop, it allowed me to delete the WinRE partition but wouldn't
> allow me to recreate it. I understand that's because Bitlocker is running, and
> that the operation should (!) succeed if it's suspended.
>
> But the instructions I've found suggested to use a GUI Bitlocker console, and
> that doesn't seem to offer the "suspend" option. I'm getting nervous, so I
> tried to back up the key. However, the printed output of that process invites
> me to compare the "following identifier" with the one displayed on my PC. (Er,
> where?) So I tracked down a Device ID for the computer (different) and I can't
> find any property for the disk (including using Disk Management) which matches.
>
> I'm astonished that in this day and age MS makes us chase down these rabbit-
> holes. For now, I'm left with anallocated space where the WinRE partion was
> and the update still won't install. Should i just wait for the next major
> update version? Any advice welcome!
>
>

You will have to sort out the BitLocker issue.

The 'friend' would have the BitLocker key stored in his online Microsoft
account under Devices>Info and support>Bitlocker data protection
- i.e. sign in to their MSFT account on their or another device.
Note: Accessing the Bitlocker content will(typically) require an
additional security step post sign-on to that account(e.g. one
method/request is to enter the Pin aka Passkey that logs on to Windows)

If unable to locate the BL recovery key, and can't revert to an earlier
configuration(i.e. 3rd party created image with the required
partitions(System, MSR, Windows, Recovery) and created before the
Recovery partition was deleted) you may need to Reset the device(reset
will remove all files)
Catch-22 => Reset normally requires entering the Bitlocker key. Lacing
the BL key and resetting to bare metal requires bootable media(use media
for the current installed Windows version - that installed version will
be digitaly licensed negating the need to enter a product key to validate
an activate).

Fyi...the update(KB 5034441 and its included SafeOS update) updates the
winre.wim and its Service pack number, thus needs to see the Recovery
partition(which contains winre.wim) as Active.
i.e.
--
....w¡ñ§±¤ñ

Philip Herlihy wrote:

> the instructions I've found suggested to use a GUI Bitlocker console, and
> that doesn't seem to offer the "suspend" option.

Try a command line method? In a cmd.exe window, started using the "as
administrator" option, see if you can display the recovery key using

manage-bde -protectors -get C:

or suspend with

manage-bde -protectors -disable C:

Is this Home or Pro? (contrary to what is said, Home *can* use BitLocker
if it's an OEM factory install, if you were to totally disable it, you
probably couldn't re-enable it again)

Philip Herlihy <PhillipHerlihy@SlashDevNull.invalid> wrote:

> I'm trying to fix a 'stuck' Windows Update on a friend's (otherwise fully
> updated) Windows 10 laptop. It's the KB5034441. On my own machine I found I
> could fix this by manually resizing the WinRE partition (something I know
> little about!) as described in KB5028997.
>
> On my friend's laptop, it allowed me to delete the WinRE partition but wouldn't
> allow me to recreate it. I understand that's because Bitlocker is running, and
> that the operation should (!) succeed if it's suspended.
>
> But the instructions I've found suggested to use a GUI Bitlocker console, and
> that doesn't seem to offer the "suspend" option. I'm getting nervous, so I
> tried to back up the key. However, the printed output of that process invites
> me to compare the "following identifier" with the one displayed on my PC. (Er,
> where?) So I tracked down a Device ID for the computer (different) and I can't
> find any property for the disk (including using Disk Management) which matches.
>
> I'm astonished that in this day and age MS makes us chase down these rabbit-
> holes. For now, I'm left with anallocated space where the WinRE partion was
> and the update still won't install. Should i just wait for the next major
> update version? Any advice welcome!

That update installs a new WinPE image in the Recovery partition.
However, in the majority of cases, the Recovery partition is not large
enough to hold the larger WinPE image, so you have to move or change
partition sizes. For me, the Recovery partition is the 1st one on the
disk, not the last one. Most instructions figure the Recovery partition
is at the end, so they have you shrink the partition before it (likely
the OS partition) to make room to enlarge the Recovery partition by and
additional 250 MB. Alas, with my Recovery partition the 1st one, I
would have to move the OS/boot (3rd) partition down into unallocated
space at the end by 250 MB (change the start and end of the partition),
then move the 2nd partition (Reserved, with some Other file system) down
250 MB, then move the EFI partition (2nd) down by 250 MB, and finally
enlarge the Recovery (1st) partitioninto the newly unallocated space
after it.

KB5034441: Windows Recovery Environment update for Windows 10, version 21H2 and 22H2: January 9, 2024
https://support.microsoft.com/en-us/topic/kb5034441-windows-recovery-environment-update-for-windows-10-version-21h2-and-22h2-january-9-2024-62c04204-aaa5-4fee-a02a-2fdea17075a8

Read the article for the "Instructions to manually resize your partition
to install the WinRE update" which points to:

https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf

Yeah, like common users are expected to do all that techy shit. Does
that look easy to you? Many users report that when then get down to
step 8 that the "reagentc /enable" program errors, so they cannot
activate (identify to the OS by drive ID) the newly created and larger
Recovery partition. You go through all those harry steps manipulating
partitions which can be dangerous to end up with a larger Recovery
partition that is unusable. Probably much easier to use a 3rd-party
partition manager that will let you move and resize partitions.

Microsoft's excuse in enlarging the WinPE partition (Recovery) is code
got added to address some vulnerability. "address a security
vulnerability that could allow attackers to bypass BitLocker encryption
by using WinRE." I don't use BitLocker, so no vulnerability to me! The
WinPE (Recovery) partition gives you an instance of Windows that is
factory default to assist in recovery of your normal Windows partition.
WinPE is not required. It is an recovery assistant.

I use Macrium Reflect which also uses WinPE to provide a bootable rescue
image (with Reflect added). It does not occupy a partition on your
disk. Instead it creates a .dat file within which is the WinPE image,
and added to Windows dual-boot (actually multi-boot) manager that
appears on startup, plus you can save the rescue image to a CD to boot
from there. WinPE is used by Reflect to restore the OS/boot partitions,
but while those partitions are quiescent. The normal OS is inactive
during the reimage, so a different OS (WinPE) gets used. If the .dat
image is unabled, like the disk failed and had to get replaced, the CD
rescue disk is used.

Rather than worry about this larger WinPE image Microsoft wants to push
at us into a partition that we have to enlarge for some vulnerability
(only with Bitlocker), I just enable Windows Update to get some updates,
and then disable it again for many months during which Microsoft might
get around to addressing their horrendous "fix" that requires resizing
the Recovery partition where the WinPE image is stored. I don't leave
WU enabled all the time. I'll decide when I have the initiative, time,
and prepare (save a full image backup of all partitions on the OS disk),
before I reenable WU to get whatever they're pushing for the last few
months. I run Belarc Advisor
(https://www.belarc.com/products/belarc-advisor) to get an idea of how
many updates were missed while WU was disabled. It will report some
missing updates the WU won't get, like updates to the VC++ 2005 and 2008
runtime libs which I had to get from the Windows Update Catalog site
instead of using WU.

There is no need to use Bitlocker to protect programs. Anyone can get
those just like your friend got them. You don't need to protect
Windows, MS Word, CCleaner, some anti-virus/malware program, or any
other program unless your friend is a programmer and has highly
sensitive company-specific programs on his computer, like they sell
enterprise software, and your friend has a copy. You only need to
protect the data. You can use encrypted containers for that which get
mounted as a drive letter, like using Veracrypt. Bitlocker is overkill.

https://en.wikipedia.org/wiki/Windows_Preinstallation_Environment

As to whether or not I need the new WinPE is iffy. I've never used the
Windows recovery image to recover from a problem. Instead I restore
from my periodically scheduled full/differential/incremental image
backups. Some folks just use System Restore, but that does not restore
a partition back to its exact state as before a problem.

For now, decide if you really need the update. If not, wait until
Microsoft comes up with a far safer means of providing a new WinPE
image, like code it within the limits of the old Recovery partition, or
provides their own program that safely moves and resizes the partitions
regardless of which order they are present on the disk (yeah, right,
like that'll happen).

Even with Bitlocker enabled, how your friend handles the computer really
determines the safety of the data files on it. After he logs in, how
does he secure his computer to prevent someone from grabbing his files?
Users are often the very weak link in security. Toss in all the
security you want, but users thwart its protection with bad practices.

The Bitlocker vulnerability within the old WinPE image is described at:

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-20666

The instructions I found (kb5028997) are console-mode commands (reagentc
and diskpart), and no "Bitlocker GUI" is mentioned. Where did you find
instructions having you use some GUI tool? This one maybe:

https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/operations-guide?tabs=powershell#bitlocker-control-panel-applet

From an article at:

https://4sysops.com/archives/check-the-bitlocker-status-of-all-pcs-in-the-network/

the 2nd image there shows "Suspend protection"; see a bigger image at:

https://4sysops.com/wp-content/uploads/2023/06/Check-the-BitLocker-status-in-the-Control-Panel-applet.png

You don't see the "Suspend protection" option there?

VanguardLH wrote on 3/2/24 12:15 PM:

> Microsoft's excuse in enlarging the WinPE partition (Recovery) is code
> got added to address some vulnerability. "address a security
> vulnerability that could allow attackers to bypass BitLocker encryption
> by using WinRE." I don't use BitLocker, so no vulnerability to me!

Fyi....it's WinRE (not PE)

You're a bit behind in on the chronolgoy of updating the WinRe partition.
KB5034441 is the latest, but for Win10 22H2 and 22H1, it's the third
WinRE update this year.
- for those same two versions and others dating back to 2004, WinRE has
been auto-updated(and resized larger when necessary by shrinking C:).
=> The only difference for Win10 22H2/22H1 - updating the WinRE is
now(and has been since June 2023) included in the monthly cumulative
update rather than automatically and independently by Windows Update

> WinPE (Recovery) partition gives you an instance of Windows that is
> factory default to assist in recovery of your normal Windows partition.
> WinPE is not required. It is an recovery assistant.

WinRE when updated for the installed version or or updated via a Feature
update recovers to the current installed version.
For OEM devices that have a separate Factory default OEM created Recovery
partition in addition to the WinRE partition - resetting or recovering
the device ignores the reset to factory(this was changed as of Win10
2004), thus to reset to factory, the OEM included tools to return to
factory are almost always necessary.
- There are exceptions with clean installs using media(Media or mounted
ISO current build) where factory condition results rather than version of
current media on devices that were originally 8.0/8.1 with the system
product key on firmware. In these cases, an extra step is necessary to
yield the latest installed version...running setup.exe(not booting the
media) with current media and validate/activation handled by the digital
license.

--
....w¡ñ§±¤ñ

"...w¡ñ§±¤ñ " <winstonmvp@gmail.com> wrote:

> VanguardLH wrote on 3/2/24 12:15 PM:
>
>> Microsoft's excuse in enlarging the WinPE partition (Recovery) is code
>> got added to address some vulnerability. "address a security
>> vulnerability that could allow attackers to bypass BitLocker encryption
>> by using WinRE." I don't use BitLocker, so no vulnerability to me!
>
> Fyi....it's WinRE (not PE)

What's the diff? In WinRE smaller than WinPE? Despite the claim WinPE
is a lightweight version of Windows not intended for troubleshooting or
recovery, that is how I mostly see it used. I think the interpretation
is based on WinPE as part of the Windows Assessment and Deployment Kit
(ADK), but that's not I've seen WinPE employed; however, it may be used
that way in a corporate environment for workstation setups.

Repair, backup, and other utilities to modify the OS use WinPE (or
another OS), so they can run while the OS partition is quiescent. For
WinRE, there still has to be a boot loader and OS to run its tools (they
aren't written in instruction code) just like the tools that use WinPE
or some Linux distro.

My WinRE partition is currently 519 MB in size of which 106 MB is free,
so WinRE only occupies 413 MB. Microsoft wants users to add another 250
MB, so the new WinRE might be up to 663 MB in size. That's a big jump.
When I have Reflect create the WinPE image file to add to the boot menu,
a 600 GB boot.wim file gets created. That's bigger than the used space
for WinRE in the Recovery partition, but the boot.wim image file also
contains the Reflect backup program. WinPE+Reflect is still smaller
than the new WinRE image. Seems Microsoft severely bloated the size of
the new WinRE for the latest version that has KB5034441 failing for
everyone attempting to install the update.

> You're a bit behind in on the chronolgoy of updating the WinRe partition.
> KB5034441 is the latest, but for Win10 22H2 and 22H1, it's the third
> WinRE update this year.
> - for those same two versions and others dating back to 2004, WinRE has
> been auto-updated(and resized larger when necessary by shrinking C:).

That would require the Recovery partition be after the OS partition:
shrink the OS partition to make room to enlarge the Recovery partition.
However, the order of my partitions is:

Recovery
EFI
Reserved
Windows (boot & OS)
unallocated (gets used for SSD overprovisioning)

Reducing the size of unallocated space means less space for
overprovisioning for the SSD drives, but then 250 MB is a tiny loss.
Moving my Recovery partition to after the OS partition, and then moving
all them up to eliminate unallocated space at the beginning would
probably run afoul of the partition numbering which is used when booting
to address each partition by its physical identification. If I
eventually give a gnat's fart about enlarging the Recovery partition to
get Microsoft new overbloated WinRE installed, I'll have to move down
the 2nd, 3rd, and 4th partitions by encroaching on the unallocated
space. That would add unallocated space after the Recovery partition
for me to then enlarge it. In all the years I've used various versions
and editions of Windows, I've never needed to use WinRE. Instead I rely
on an image backup of all partitions on the disk to get me back to a
prior state rather than try to repair whatever got farked up (by
Microsoft, me, or some software).

At some point when I figure to risk the stability and usability of my
desktop PC, I'll go through all the crap of having to move down the
partitions to make unallocated space after the Recovery partition to
enlarge it, and then apply the KB5034441 update. However, since the
update is about a vulnerability with Bitlocker, and since I don't use
Bitlocker (and instead use Veracrypt containers to secure sensitive data
since none of the programs need to be protected because they can be
obtain elsewhere, so just a bit of my data needs protecting), I'll
probably procrastinate on this update until Windows 12 shows up. I
don't really need an update to WinRE that never gets used, anyway.

Microsoft's instructions on resizing (enlarging) the Recovery partition
won't work for many users, because it does not address when the Recovery
partition is not the last partition. It also doesn't address the
unallocated space on the disk which is needed for SSD overprovisioning
(https://www.minitool.com/partition-disk/ssd-over-provisioning.html).
Typical consumer SSDs come with some overprovisioning (6% to 10% of the
disk's space remains unallocated). I upped that to 20% to match the
recommendation for workstations, and longer endurance.

But thanks for the correction that it's WinRE, not WinPE, that KB5034441
is updating. Alas, I've read about many users that follow Microsoft's
instructions only to get to the "reagentc /enable" command that fails,
so they end up with no accessible WinRE after all their work and risk.

VanguardLH wrote on 3/2/24 6:07 PM:
> "...w¡ñ§±¤ñ " <winstonmvp@gmail.com> wrote:
>
>> VanguardLH wrote on 3/2/24 12:15 PM:
>>
>>> Microsoft's excuse in enlarging the WinPE partition (Recovery) is code
>>> got added to address some vulnerability. "address a security
>>> vulnerability that could allow attackers to bypass BitLocker encryption
>>> by using WinRE." I don't use BitLocker, so no vulnerability to me!
>>
>> Fyi....it's WinRE (not PE)
>
> What's the diff In WinRE smaller than WinPE? Despite the claim WinPE

Just so I'm clear...WinRE is the Recovery partition. WinPE is not a partition
=> WinRe partition is enlarged
=> WinPE is not enlarged. WinPE is included in Windows and used to
repair, install or deploy an operating system. WinPE can be on or added
to bootable media.
i.e. your statement 'enlarging the WinPE partition' is incorrect or
let's chalk it up to a typo 6 keys to the left (P to R) :)

> is a lightweight version of Windows not intended for troubleshooting or
> recovery, that is how I mostly see it used. I think the interpretation
> is based on WinPE as part of the Windows Assessment and Deployment Kit
> (ADK), but that's not I've seen WinPE employed; however, it may be used
> that way in a corporate environment for workstation setups.
>
> Repair, backup, and other utilities to modify the OS use WinPE (or
> another OS), so they can run while the OS partition is quiescent. For
> WinRE, there still has to be a boot loader and OS to run its tools (they
> aren't written in instruction code) just like the tools that use WinPE
> or some Linux distro.
>
> My WinRE partition is currently 519 MB in size of which 106 MB is free,
> so WinRE only occupies 413 MB. Microsoft wants users to add another 250
> MB, so the new WinRE might be up to 663 MB in size. That's a big jump.

On a 128 GB disk enlarging from 413 to 663 MB occupies 0.52%. An increase
of 0.19%.

> When I have Reflect create the WinPE image file to add to the boot menu,
> a 600 GB boot.wim file gets created. That's bigger than the used space
> for WinRE in the Recovery partition, but the boot.wim image file also
> contains the Reflect backup program. WinPE+Reflect is still smaller
> than the new WinRE image. Seems Microsoft severely bloated the size of
> the new WinRE for the latest version that has KB5034441 failing for
> everyone attempting to install the update.

KB5034441's contribution to the increase in size of the WinRE partition
is ~20-30 MB.
- the 250 MB increase covers all possible devices(over 500 million Win
11 and up to the remaining Windows 10 devices - 1 Billion[or more] less
those upgraded or replaced with Win11)
i.e. A number(size increase) large enough to cover every single device
in existence, not the actual space used for the update process but a free
space bogey number that can be checked as a minimum size free space to
perform and ensure a successful update on every single device, not the
actual size of free space physically necessary.
- It's quite common to incorrectly look at that 250 MB number from the
wrong perspective. Especially because it also does not mean that future
WinRE updates also need 250 MB free space(doing so would be incorrect, too).

>
>> You're a bit behind in on the chronolgoy of updating the WinRe partition.
>> KB5034441 is the latest, but for Win10 22H2 and 22H1, it's the third
>> WinRE update this year.
>> - for those same two versions and others dating back to 2004, WinRE has
>> been auto-updated(and resized larger when necessary by shrinking C:).
>
> That would require the Recovery partition be after the OS partition:
> shrink the OS partition to make room to enlarge the Recovery partition.
> However, the order of my partitions is:
>
> Recovery
> EFI
> Reserved
> Windows (boot & OS)
> unallocated (gets used for SSD overprovisioning)

Your device - either by the OEM, System Builder, or someone when Windows
was installed chose to ignore GPT partition layout guidelines order.
System(EFI), MSR, Windows, Recovery
=> that GPT guideline has been in place at least, since
2007-2008(release of 64 bit Win7 beta editions) and July 2009 for Win7
RTM consumer, enterprise, edu editons)..but GPT, iirc first appeared,
years earlier than Win7, for Windows 2003 SP1.

> Microsoft's instructions on resizing (enlarging) the Recovery partition
> won't work for many users, because it does not address when the Recovery
> partition is not the last partition. It also doesn't address the
> unallocated space on the disk which is needed for SSD overprovisioning
> (https://www.minitool.com/partition-disk/ssd-over-provisioning.html).
> Typical consumer SSDs come with some overprovisioning (6% to 10% of the
> disk's space remains unallocated). I upped that to 20% to match the
> recommendation for workstations, and longer endurance.

Maybe you didn't realize that if you follow the directions and disable
the Recovery partition, then select the disk # where the os resides,
shrink Windows(C:\ usually), the create a new WinRE partition on the same
disk #(e.g. 1 GB which would be more than sufficient for WinRE files and
all future Win10 WinRE partition updates until Win10 EOL) using the
directions Set ID, attribute and format variables, the enable WinRE the
end result will WinRE partition in the design intent GPT location(after
Windows)
=> Correct, it would not address that first partition(now old, useless
Recovery) which as you noted, you wouldn't address until a later point in
time(possibly b/f Win10 EOL).
-optionially, one could select that 1st partition, delete it, an still
create the WinRE after Windows by checking for and selecting the Windows
partition(shrink, create WinRE etc.) - the only difference would be the
space at the front would be unallocated, not much different that a
useless partition.
>
> But thanks for the correction that it's WinRE, not WinPE, that KB5034441
> is updating.

You're welcome.

--
....w¡ñ§±¤ñ

winston <winstonmvp@gmail.com> wrote:

> On a 128 GB disk enlarging from 413 to 663 MB occupies 0.52%. An increase
> of 0.19%.

413 MB to 663 MB, or a 250 MB increase from 413 MB, is a 60% increase in
size of the WinRE partition. Doesn't matter what the total size is of
the disk since since that's not relevant to the needed increase in the
WinRE *partition*. You could use a 500 GB, 1 TB, or 8 TB hard disk
trying to minimalize the 60% increase in the WinRE partition. You could
use the total capacity of all HDDs and SSDs possible in a setup to
further minimize the WinRE's partition size increase. None of that is
relevant, just the change in the size of the WinRE partition itself, and
that's a 60% increase. Citing the total size of the disk is a diversion
from how much the WinRE *partition* increased in size.

However, my WinRE's total partition size is 519 MB. The 413 MB was an
estimate based on the slack/unused space in the WinRE partition. Even
if WinRE occupied the entire 519 MB partition (no slack space), a 250 MB
jump is a 48% jump in size, not the puny percentages you cited.

> KB5034441's contribution to the increase in size of the WinRE partition
> is ~20-30 MB.
> - the 250 MB increase covers all possible devices(over 500 million Win
> 11 and up to the remaining Windows 10 devices - 1 Billion[or more] less
> those upgraded or replaced with Win11)
> i.e. A number(size increase) large enough to cover every single device
> in existence, not the actual space used for the update process but a free
> space bogey number that can be checked as a minimum size free space to
> perform and ensure a successful update on every single device, not the
> actual size of free space physically necessary.
> - It's quite common to incorrectly look at that 250 MB number from the
> wrong perspective. Especially because it also does not mean that future
> WinRE updates also need 250 MB free space(doing so would be incorrect, too).

The WinRE partition uses NTFS. Users don't get to choose some other
formatting scheme nor do they get to choose the size of clusters. No
matter what HDDs or SSDs are used in those 500 million computers,
they're still all using an NTFS formatted partition with the default
cluster size (4096 bytes/sector). Does anyone have a WinRE partition
that is not NTFS formatted, or uses huge cluster sizes?

Even the instructions for KB5028997 say to run:

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

Everyone one of those 500 million computers have the same partition
format and the default cluster size. If only 20-30 MB is the increase
for the new WinRE image, the 250 MB increase is severe bloat.

The only way I can see such a bloated space requirement is the old WinRE
image is untouched during the update (to allow recovery to the old
recovery image), another copy of the WinRE image is modified or
installed, and then the old WinRE image deleted, so twice the space is
required to do the update.

>>> You're a bit behind in on the chronolgoy of updating the WinRe partition.
>>> KB5034441 is the latest, but for Win10 22H2 and 22H1, it's the third
>>> WinRE update this year.
>>> - for those same two versions and others dating back to 2004, WinRE has
>>> been auto-updated(and resized larger when necessary by shrinking C:).
>>
>> That would require the Recovery partition be after the OS partition:
>> shrink the OS partition to make room to enlarge the Recovery partition.
>> However, the order of my partitions is:
>>
>> Recovery
>> EFI
>> Reserved
>> Windows (boot & OS)
>> unallocated (gets used for SSD overprovisioning)
>
> Your device - either by the OEM, System Builder, or someone when Windows
> was installed chose to ignore GPT partition layout guidelines order.
> System(EFI), MSR, Windows, Recovery

I did a fresh install of Windows 10. Windows chose the layout, not me.
I don't do upgrades from a prior version of Windows, nor was there ever
any multi-booting involved with OSes in different partitions.

Even Macrium Reflect with its use of WinPE on boot creates a .wim file
the boot manager uses to load WinPE and Reflect, or creates a bootable
CD with WinPE+Reflect, or I can create bot, so the OS partition is
quiescent during a restore, but Reflect using WinPE does not occupy a
partition on the disk with the OS partition.

> => that GPT guideline has been in place at least, since
> 2007-2008(release of 64 bit Win7 beta editions) and July 2009 for Win7
> RTM consumer, enterprise, edu editons)..but GPT, iirc first appeared,
> years earlier than Win7, for Windows 2003 SP1.

Guess Microsoft doesn't obey those recommendations for all fresh
installs.

> Maybe you didn't realize that if you follow the directions and disable
> the Recovery partition, then select the disk # where the os resides,
> shrink Windows(C:\ usually), the create a new WinRE partition on the
> same disk #(e.g. 1 GB which would be more than sufficient for WinRE
> files and all future Win10 WinRE partition updates until Win10 EOL)
> using the directions Set ID, attribute and format variables, the
> enable WinRE the end result will WinRE partition in the design intent
> GPT location(after Windows) => Correct, it would not address that
> first partition(now old, useless Recovery) which as you noted, you
> wouldn't address until a later point in time(possibly b/f Win10 EOL).
> -optionially, one could select that 1st partition, delete it, an
> still create the WinRE after Windows by checking for and selecting
> the Windows partition(shrink, create WinRE etc.) - the only
> difference would be the space at the front would be unallocated, not
> much different that a useless partition.

So, the instructions would result in creating a new WinRE partition
after the OS partition, and the space for the old WinRE partition gets
wasted (or turned into more unallocated space).

The instructions do say to run, in diskpart:

delete partition override

However, a following command runs:

create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
gpt attributes =0x8000000000000001

Does not specify size, so why wouldn't the "new" partition get created
where was the deleted partition? You'd have to specify a partition size
that wouldn't fit inside the now unallocated space for the old
partition. You're assuming diskpart's 'create' will add the partition
after the existing partitions per your GPT intent claim. Maybe it does,
but now the increase in the WinRE partition is not 60%, but

519 MB old partition (delete, becomes unallocated)
519 MB + 250 MB new partition
Total = 519 MB + 519 MB + 250 MB. A 250% increase to create the new
partition.

Oh, yes, the OS partition gets shrunk by 250 MB, but that applies only
to the OS partition. In the instructions, the size for the 'create'
command for a new partition for WinRE does not specify size. The
assumption is there was no slack (unallocated) space after the OS
partition, so shrinking the OS partition adds unallocated space at the
end that presumably wasn't there before to insert a new partition using
the newly made unallocated space at the end.

By the way, in those GPT intents you mention, just where is unallocated
space supposed to exist to use for SSD overprovisioning? Where those
intents supposed to have unallocated space at the start of the disk?

On 3/2/2024 10:59 AM, Philip Herlihy wrote:
> I'm trying to fix a 'stuck' Windows Update on a friend's (otherwise fully
> updated) Windows 10 laptop. It's the KB5034441. On my own machine I found I
> could fix this by manually resizing the WinRE partition (something I know
> little about!) as described in KB5028997.
>
> On my friend's laptop, it allowed me to delete the WinRE partition but wouldn't
> allow me to recreate it. I understand that's because Bitlocker is running, and
> that the operation should (!) succeed if it's suspended.
>
> But the instructions I've found suggested to use a GUI Bitlocker console, and
> that doesn't seem to offer the "suspend" option. I'm getting nervous, so I
> tried to back up the key. However, the printed output of that process invites
> me to compare the "following identifier" with the one displayed on my PC. (Er,
> where?) So I tracked down a Device ID for the computer (different) and I can't
> find any property for the disk (including using Disk Management) which matches.
>
> I'm astonished that in this day and age MS makes us chase down these rabbit-
> holes. For now, I'm left with anallocated space where the WinRE partion was
> and the update still won't install. Should i just wait for the next major
> update version? Any advice welcome!

If you're still having trouble, provide:

Make and model of hardware, and whether drive is an original image
Picture of Disk Management partitions
Version of OS (winver.exe is a start, but not very thorough as an identifier)

You can hand-draw ascii-art disk management info if you want.
If doesn't have to be a screenshot with snippingtool.exe .

Paul

VanguardLH wrote on 3/3/24 12:36 AM:
> winston <winstonmvp@gmail.com> wrote:
>
>> On a 128 GB disk enlarging from 413 to 663 MB occupies 0.52%. An increase
>> of 0.19%.
>
> 413 MB to 663 MB, or a 250 MB increase from 413 MB, is a 60% increase in
> size of the WinRE partition. Doesn't matter what the total size is of
> the disk since since that's not relevant to the needed increase in the
> WinRE *partition*. You could use a 500 GB, 1 TB, or 8 TB hard disk
> trying to minimalize the 60% increase in the WinRE partition. You could
> use the total capacity of all HDDs and SSDs possible in a setup to
> further minimize the WinRE's partition size increase. None of that is
> relevant, just the change in the size of the WinRE partition itself, and
> that's a 60% increase. Citing the total size of the disk is a diversion
> from how much the WinRE *partition* increased in size.

It's been increasing in size for over 7 yrs.
- unlikely you'll ever need or use that 250 MB loss on your C:\drive
partition.

>
> However, my WinRE's total partition size is 519 MB. The 413 MB was an
> estimate based on the slack/unused space in the WinRE partition. Even
> if WinRE occupied the entire 519 MB partition (no slack space), a 250 MB
> jump is a 48% jump in size, not the puny percentages you cited.

See above.

>
> I did a fresh install of Windows 10. Windows chose the layout, not me.
> I don't do upgrades from a prior version of Windows, nor was there ever
> any multi-booting involved with OSes in different partitions.

Which indicates you used 2004 or earlier Win10 Media Creation Tool usb or
dvd media, instead of the separate optional downloadable ISO(later using
3rd party tools to create bootable usb/dvd media).
The separate ISO download was removed(no longer available for Win10[un
when the MCT created media was updated to create the Recovery partition
after Windows.

>
> Even Macrium Reflect with its use of WinPE on boot creates a .wim file
> the boot manager uses to load WinPE and Reflect, or creates a bootable
> CD with WinPE+Reflect, or I can create bot, so the OS partition is
> quiescent during a restore, but Reflect using WinPE does not occupy a
> partition on the disk with the OS partition.

You really should check the date and Service Pack level of your current
winre.wim on that first partition.
For Win10 it should have a Service Pack Build of 3920.

reagentc /info
- will verify if the WinRe status is enabled
- will provide the WinRE location path

Then look at the ‘Location’ path and create the DISM line with the
correct disk# and partition# number shown.
=> or just copy the line below and replace the # with the correct numbers
DISM /Get-ImageInfo
/ImageFile:\\?\GLOBALROOT\device\harddisk#\partition#\Recovery\WindowsRE\winre.wim
/index:1
- the result will shown the Service Pack Level and date

If the Service Pack Number is not 3920, then your WinRE is outdated and
possibly also Macrium's WinPE tools.
=> Macrium's WinPE depends on the the source the user chooses for the
base WIM - multiple options - WinRE(the current on the device) or one
from Msft's WADK version 10 or 5 or 4.
- 4 supports 8.0 and earlier, 5 supports up to 8.1
- 10 supports Win10 but uses Win10 2004
i.e. best to update the devices recovery partition with a successful
install of 5034441, then use updated and latest Win10 22H2-WinRE 3920 ti
build your Macrium PE media

>
> Guess Microsoft doesn't obey those recommendations for all fresh
> installs.

See above, they fixed it along time ago.
>
>> Maybe you didn't realize that if you follow the directions and disable
>> the Recovery partition, then select the disk # where the os resides,
>> shrink Windows(C:\ usually), the create a new WinRE partition on the
>> same disk #(e.g. 1 GB which would be more than sufficient for WinRE
>> files and all future Win10 WinRE partition updates until Win10 EOL)
>> using the directions Set ID, attribute and format variables, the
>> enable WinRE the end result will WinRE partition in the design intent
>> GPT location(after Windows) => Correct, it would not address that
>> first partition(now old, useless Recovery) which as you noted, you
>> wouldn't address until a later point in time(possibly b/f Win10 EOL).
>> -optionially, one could select that 1st partition, delete it, an
>> still create the WinRE after Windows by checking for and selecting
>> the Windows partition(shrink, create WinRE etc.) - the only
>> difference would be the space at the front would be unallocated, not
>> much different that a useless partition.
>
> So, the instructions would result in creating a new WinRE partition
> after the OS partition, and the space for the old WinRE partition gets
> wasted (or turned into more unallocated space).
>
> The instructions do say to run, in diskpart:
>
> delete partition override
>
> However, a following command runs:
>
> create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
> gpt attributes =0x8000000000000001
>
> Does not specify size, so why wouldn't the "new" partition get created
> where was the deleted partition? You'd have to specify a partition size
> that wouldn't fit inside the now unallocated space for the old
> partition. You're assuming diskpart's 'create' will add the partition
> after the existing partitions per your GPT intent claim. Maybe it does

No, one would not use the old partition location or if deleted it's
unallocated space. WinRE belongs after C:
- Why? eventually MSFT will permanently fix that issue negating the
need for kb5028997 manual instructions, with the already existing
included code in Windows and Windows 10 updates...which means your
partition 1 will become an inactive WinRE and a new one will be created
by shrinking C, and creating one after C:
- i.e. why I commented on the sequence to select the same disk # as the
o/s to create a new adequate size WinRE partition(after C: partition) to
ensure all future cumulative monthly updates(which now include latest
WinRE code...and also ensure when creating Macrium's PE use a current an
updated 22H2 WIM instead and outdated current WIM or Macrium's Win10 2004
era ADK.
>
> By the way, in those GPT intents you mention, just where is unallocated
> space supposed to exist to use for SSD overprovisioning? Where those
> intents supposed to have unallocated space at the start of the disk?
>
If not adopting overprovisioning already included and already built-in by
the SSD manufacture and choosing the DIY route, it by design must be to
the furthest right partition on the SSD(i.e. the last, and yes after
WinRE(after C:) *and* after any GPT data partitions.

If I were you and had a WinRE as the first GPT partition, I would have
wiped that drive to bare metal way back when 21H1 was released[May 2021]
- 21H1, 21H2, 22H2 have the same core o/s files and setup the
partitioning properly!

I've given you sufficient information, whether you take it or not, is
your choice. Take it or complain to someone else about losing a scant
amount of space that you'll unlikely ever need or use on your device.
- especially since shrinking C to enlarge and create WinRE after the C
partition has been in place, known and the norm for over 3 yrs.

--
....w¡ñ§±¤ñ

winston <winstonmvp@gmail.com> wrote:

> VanguardLH wrote on 3/3/24 12:36 AM:
>
>> I did a fresh install of Windows 10. Windows chose the layout, not
>> me. I don't do upgrades from a prior version of Windows, nor was
>> there ever any multi-booting involved with OSes in different
>> partitions.
>
> Which indicates you used 2004 or earlier Win10 Media Creation Tool usb
> or dvd media, instead of the separate optional downloadable ISO(later
> using 3rd party tools to create bootable usb/dvd media).

Yep, like lots of users, I used the MCT to create the Win10 install ISO.
From my Downloads folder, looks like I used the MCT for the 1903 build.
You say the GPT guideline for partition layout was established back in
Windows 7 about 2007-2008. That is more than a decade past the 1903
build provided by MCT around May 2019.

>> Even Macrium Reflect with its use of WinPE on boot creates a .wim file
>> the boot manager uses to load WinPE and Reflect, or creates a bootable
>> CD with WinPE+Reflect, or I can create bot, so the OS partition is
>> quiescent during a restore, but Reflect using WinPE does not occupy a
>> partition on the disk with the OS partition.
>
> You really should check the date and Service Pack level of your current
> winre.wim on that first partition.
> For Win10 it should have a Service Pack Build of 3920.
>
> reagentc /info
> - will verify if the WinRe status is enabled
> - will provide the WinRE location path

Shows WinRE is enabled. Copied the WinRE path to winre.wim from that
output.

> Then look at the ‘Location’ path and create the DISM line with the
> correct disk# and partition# number shown.
> => or just copy the line below and replace the # with the correct numbers
> DISM /Get-ImageInfo
> /ImageFile:\\?\GLOBALROOT\device\harddisk#\partition#\Recovery\WindowsRE\winre.wim
> /index:1
> - the result will shown the Service Pack Level and date

The DISM output is:

Deployment Image Servicing and Management tool
Version: 10.0.19041.3636

Details for image :
\\?\GLOBALROOT\device\harddisk2\partition1\Recovery\WindowsRE\winre.wim

Index : 1
Name : Microsoft Windows Recovery Environment (x64)
Description : Microsoft Windows Recovery Environment (x64)
Size : 2,320,898,360 bytes <--- Only 2.16 GB in a 519 GB partition!
WIM Bootable : No If just the file size, perhaps WIM
Architecture : x64 extraction occupies much more space.
Hal : <undefined>
Version : 10.0.19041
ServicePack Build : 1
ServicePack Level : 0
Edition : WindowsPE
Installation : WindowsPE
ProductType : WinNT
ProductSuite :
System Root : WINDOWS
Directories : 3602
Files : 17513
Created : 12/7/2019 - 1:11:48 AM
Modified : 10/20/2020 - 11:48:59 PM
Languages :
en-US (Default)
The operation completed successfully.

No Service Pack info shown. Only the DISM version is listed.

Per:

https://learn.microsoft.com/en-us/windows/release-health/release-information

the 19041 build was within the Win 10 2004 level (c. 2020-05-27 to
2021-12-14 since DISM doesn't report the sub-build number). Unlike you
say, Microsoft hasn't pushed a new version of WinRE to my Recovery
partition in about 3 years.

> If the Service Pack Number is not 3920, then your WinRE is outdated and
> possibly also Macrium's WinPE tools.

Macrium Reflect does not touch the WinRE partition. Its boot.wim file
does not occupy any partition. The most it touches is to add its
boot.wim to the OS (C:) partition, and update the BCD to add its
boot.wim to the boot menu on Windows startup. That's why, in case of
disk failure, I also save their image to a bootable rescue CD.

> => Macrium's WinPE depends on the the source the user chooses for the
> base WIM - multiple options - WinRE(the current on the device) or one
> from Msft's WADK version 10 or 5 or 4.
> - 4 supports 8.0 and earlier, 5 supports up to 8.1
> - 10 supports Win10 but uses Win10 2004
> i.e. best to update the devices recovery partition with a successful
> install of 5034441, then use updated and latest Win10 22H2-WinRE 3920 ti
> build your Macrium PE media

Reflect is configured to use the following when creatings its WIM file:

Windows RE 10 version 2004 (64-bit)

Remember that Reflect is *not* touching the Recovery (WinRE) partition.
It creates a boot.wim file to add to the Windows startup boot menu, or
burns to a rescue CD, or writes an image to a USB drive, or creates an
ISO file.

>> Guess Microsoft doesn't obey those recommendations for all fresh
>> installs.
>
> See above, they fixed it along time ago.

The partition layout I got was from MCT 2004. Since Windows 10 got
installed, I've not had to use MCT again to see what it now uses. Looks
like Microsoft didn't obey those GPT partition layout rules until after
some MCT that creates a later ISO of Windows 10.

> No, one would not use the old partition location or if deleted it's
> unallocated space. WinRE belongs after C:

Perhaps at some point in time when the ISO image created by MCT was
modified to use the recommended layout. They "fixed" it after the MCT I
used to get an ISO to install Windows 10. That doesn't alter that NOW
the partition layout is not what their instructions expect.

If I delete the current WinRE (Recovery) partition, and to prevent any
screwup on anything expecting the same disk and partition numbering
(disks are indexed starting at 0, partitions are indexed starting at 1),
I would have to create a dummy or placeholder partition in the
unallocated space created by deleting the old WinRE partition. That's
why moving down the partitions risks a problem with disk/partition
numbering getting used by anything. Delete the current WinRE partition
at the beginning of the partition layout, create a dummy partition
there, reduce the size at the end of the Windows partitions, and use
unallocated space after the Windows partition to create a new Recovery
partition, and then get WinRE installed in there.

Since the new WinRE partition would be partition 4 instead of the old
partition 1, you sure that anything that calls the WinRE partition won't
get confused because its physical numbering has changed?

>> By the way, in those GPT intents you mention, just where is unallocated
>> space supposed to exist to use for SSD overprovisioning? Where those
>> intents supposed to have unallocated space at the start of the disk?
>
> If not adopting overprovisioning already included and already
> built-in by the SSD manufacture and choosing the DIY route, it by
> design must be to the furthest right partition on the SSD(i.e. the
> last, and yes after WinRE(after C:) *and* after any GPT data
> partitions.

That's where the unallocated space now resides: last partition.

Randomized writes are not overprovisioning. Those are to alleviate
write amplication. Overprovisioning (OP) means allocating some
unallocated space on the same SSD drive.

https://www.minitool.com/partition-disk/ssd-over-provisioning.html
https://www.techtarget.com/searchstorage/definition/overprovisioning-SSD-overprovisioning

All the vendor OP tools to is facilitate managing the unallocated space
on the disk. The SSD makers simply leave some unallocated space on
their SSD disks which is a percentage of the disks' usable capacity, so
that's probably what you think is built-in OP. That the unallocated
space is invisible, so it doesn't show up File Explorer, is expected:
there is no partition there to contain a file system to mount as a
drive. You can, though, see it in diskmgmt.msc, or any 3rd-party
partition manager. You cannot change the inherent or vendor-configured
OP space on the disk. You can only add more unallocated space to
increase the effective size of the OP areas on the disk. The disk will
not report the inherent or vendor OP space to the host OS to prevent
users from accidentially deleting the "buried" OP space.

Consumer disks are usually configured to use 6 to 10% of total capacity
to the inherent or vendor OP space. You can't change this using
end-user tools. However, admins usually add another 10%, for a total of
about 20%, on workstations to lengthen longevity of the SSD.

If you want to rely on the consumer-level OP defaults, go ahead. I want
more OP space which means having unallocated space (besides the
unallocated space the disk will not report to the OS). I can certainly
consume a meager 250 MB from the end of the partition layout where is
the unallocated space for a new WinRE partition, but then that
partition's number would change from 1 to 4. Seems safer I move the OS
partition down into unallocated space, move the other partitions (EFI
and Reserved) down, too, which leaves unallocated space behind the 1st
partition (Recovery), and then enlarge the 1st partition into the newly
created unallocated space after the 1st partition. That way, I get a
larger WinRE (Recovery) partition, but is physical layout number does
not change.

VanguardLH wrote on 3/3/24 10:19 PM:

> Yep, like lots of users, I used the MCT to create the Win10 install ISO.
> From my Downloads folder, looks like I used the MCT for the 1903 build.
> You say the GPT guideline for partition layout was established back in
> Windows 7 about 2007-2008. That is more than a decade past the 1903
> build provided by MCT around May 2019.
Yes, quite old. The disconnect 1st partition vs. guidelines(4th
partition) happened with the ceasing of plastic media provided to OEM's.
OEM's being the majority of built/sold pcs routinely placed the Recovery
first to deliniate from the factory-reset(last partition) to the
as-shipped Windows and all pre-installed software and apps. - thus the
earlier MCT was released to accommodate them for MCT created USB/ISO
media and optionally the stand-alone ISO download(available from the same
Win10 Software download site) which created the Recovery in the correct,
design intent location(after Windows). Contractually, no way to force
OEM's until renegotiation of OEM contracts for end of servicing Windows
1903/1904 in 2020 for the updated Win10 required specs with an agreed
upon date applicable for OEM Windows 2004 sales and its release in May 2004.
=> Windows 10 MCT 2004/20H2 created media was finally updated and
stand-alone ISO removed..the latter no longer necessary b/c MCT ISO
handled partitioning properly like the stand-alone ISO.

>
>>> Even Macrium Reflect with its use of WinPE on boot creates a .wim file
>>> the boot manager uses to load WinPE and Reflect, or creates a bootable
>>> CD with WinPE+Reflect, or I can create bot, so the OS partition is
>>> quiescent during a restore, but Reflect using WinPE does not occupy a
>>> partition on the disk with the OS partition.
Never stated it did. Only that it uses old 2004.
- to not use 2004 when creating Macrium media is to get Windows updated
with KB5034441, then let Macrium 'build' it with current WinRE used its
advance options to choose WinRE instead of Win10 PE ADK(that uses 2004)
>>
>> You really should check the date and Service Pack level of your current
>> winre.wim on that first partition.
>> For Win10 it should have a Service Pack Build of 3920.
>>
>> reagentc /info
>> - will verify if the WinRe status is enabled
>> - will provide the WinRE location path
>
> Shows WinRE is enabled. Copied the WinRE path to winre.wim from that
> output.
>
>> Then look at the ‘Location’ path and create the DISM line with the
>> correct disk# and partition# number shown.
>> => or just copy the line below and replace the # with the correct numbers
>> DISM /Get-ImageInfo
>> /ImageFile:\\?\GLOBALROOT\device\harddisk#\partition#\Recovery\WindowsRE\winre.wim
>> /index:1
>> - the result will shown the Service Pack Level and date
>
> The DISM output is:
>
> Deployment Image Servicing and Management tool
> Version: 10.0.19041.3636
>
> Details for image :
> \\?\GLOBALROOT\device\harddisk2\partition1\Recovery\WindowsRE\winre.wim
>
> Index : 1
> Name : Microsoft Windows Recovery Environment (x64)
> Description : Microsoft Windows Recovery Environment (x64)
> Size : 2,320,898,360 bytes <--- Only 2.16 GB in a 519 GB partition!
> WIM Bootable : No If just the file size, perhaps WIM
> Architecture : x64 extraction occupies much more space.

You're partition is 519 MB
The size shown above is the entire Windows o/s system image :)

> Version : 10.0.19041
> ServicePack Build : 1
> ServicePack Level : 0
> Created : 12/7/2019 - 1:11:48 AM
> Modified : 10/20/2020 - 11:48:59 PM
Yes, never updated. No longer supported either.

> Reflect is configured to use the following when creatings its WIM file:
>
> Windows RE 10 version 2004 (64-bit)

Answered above.

> If I delete the current WinRE (Recovery) partition, and to prevent any
> screwup on anything expecting the same disk and partition numbering
> (disks are indexed starting at 0, partitions are indexed starting at 1),
> I would have to create a dummy or placeholder partition in the
> unallocated space created by deleting the old WinRE partition. That's
> why moving down the partitions risks a problem with disk/partition
> numbering getting used by anything. Delete the current WinRE partition
> at the beginning of the partition layout, create a dummy partition
> there, reduce the size at the end of the Windows partitions, and use
> unallocated space after the Windows partition to create a new Recovery
> partition, and then get WinRE installed in there.

Already explained the options you have.

--
....w¡ñ§±¤ñ

winston <winstonmvp@gmail.com> wrote:

> VanguardLH wrote:
>
>> Deployment Image Servicing and Management tool
>> Version: 10.0.19041.3636
>>
>> Details for image :
>> \\?\GLOBALROOT\device\harddisk2\partition1\Recovery\WindowsRE\winre.wim
>>
>> Index : 1
>> Name : Microsoft Windows Recovery Environment (x64)
>> Description : Microsoft Windows Recovery Environment (x64)
>> Size : 2,320,898,360 bytes <--- Only 2.16 GB in a 519 GB partition!
>> WIM Bootable : No If just the file size, perhaps WIM
>> Architecture : x64 extraction occupies much more space.
>
> You're partition is 519 MB
> The size shown above is the entire Windows o/s system image :)
>
>> Version : 10.0.19041
>> ServicePack Build : 1
>> ServicePack Level : 0
>> Created : 12/7/2019 - 1:11:48 AM
>> Modified : 10/20/2020 - 11:48:59 PM
>
> Yes, never updated. No longer supported either.

This is the first time the Recovery (WinRE) partition had to be enlarged
to accomodate a larger image. Windows never offered me a prior update
to WinRE. That it didn't get updated was Microsoft's choice not to
offer prior WinRE update for my Win10 Home x64 setup. Now WU can't
update WinRE because of the requirement for a larger Recovery partition.

If I ever get around to deleting the WinRE partition, create a new dummy
one in its place (so physical partition enumeration doesn't change for
the other partitions), the KB5034441 update should then succeed.

A lot of work and risk for something I've never had to use. My image
backup includes all partitions on the disk. When a severe problem
arises that cannot be addressed through diagnosis, troubleshooting, and
correction, I just revert to a prior image backup of the entire disk
(well, all the partitions on it, not the unallocated space at the end).
I have backups scheduled to run each day with a retention of a year:
monthly full, weekly differential, daily incremental. I have had to
restore maybe a couple times, but due to my own screwups -- like
partition manipulation to get a newer and bigger WinRE for a
vulnerability that cannot exist on my setup (I don't use Bitlocker).

Thanks for the info. It's been educational.

VanguardLH wrote on 3/4/24 4:50 PM:
> winston <winstonmvp@gmail.com> wrote:
>
>> VanguardLH wrote:
>>
>>> Deployment Image Servicing and Management tool
>>> Version: 10.0.19041.3636
>>>
>>> Details for image :
>>> \\?\GLOBALROOT\device\harddisk2\partition1\Recovery\WindowsRE\winre.wim
>>>
>>> Index : 1
>>> Name : Microsoft Windows Recovery Environment (x64)
>>> Description : Microsoft Windows Recovery Environment (x64)
>>> Size : 2,320,898,360 bytes <--- Only 2.16 GB in a 519 GB partition!
>>> WIM Bootable : No If just the file size, perhaps WIM
>>> Architecture : x64 extraction occupies much more space.
>>
>> You're partition is 519 MB
>> The size shown above is the entire Windows o/s system image :)
>>
>>> Version : 10.0.19041
>>> ServicePack Build : 1
>>> ServicePack Level : 0
>>> Created : 12/7/2019 - 1:11:48 AM
>>> Modified : 10/20/2020 - 11:48:59 PM
>>
>> Yes, never updated. No longer supported either.
>
> This is the first time the Recovery (WinRE) partition had to be enlarged
> to accomodate a larger image.

=> Your WinRE version, on the partition is no longer supported.
In hindsight, if we had this same discussion in June 2023(when the first
WinRE partition update was included in monthly cumulative updates), the
answer would be same.
- To resolve - disable the current, shrink C and create a new after
Windows and one larger than the original(e.g. 1024 MB).

Your issue is not than uncommon.

--
....w¡ñ§±¤ñ

On 3/4/2024 11:45 PM, ...w¡ñ§±¤ñ wrote:
> VanguardLH wrote on 3/4/24 4:50 PM:
>> winston <winstonmvp@gmail.com> wrote:
>>
>>> VanguardLH wrote:
>>>
>>>> Deployment Image Servicing and Management tool
>>>> Version: 10.0.19041.3636
>>>>
>>>> Details for image :
>>>> \\?\GLOBALROOT\device\harddisk2\partition1\Recovery\WindowsRE\winre.wim
>>>>
>>>> Index : 1
>>>> Name : Microsoft Windows Recovery Environment (x64)
>>>> Description : Microsoft Windows Recovery Environment (x64)
>>>> Size : 2,320,898,360 bytes   <--- Only 2.16 GB in a 519 GB partition!
>>>> WIM Bootable : No                 If just the file size, perhaps WIM
>>>> Architecture : x64                extraction occupies much more space.
>>>
>>> You're partition is 519 MB
>>> The size shown above is the entire Windows o/s system image :)
>>>
>>>> Version : 10.0.19041
>>>> ServicePack Build : 1
>>>> ServicePack Level : 0
>>>> Created : 12/7/2019 - 1:11:48 AM
>>>> Modified : 10/20/2020 - 11:48:59 PM
>>>
>>> Yes, never updated. No longer supported either.
>>
>> This is the first time the Recovery (WinRE) partition had to be enlarged
>> to accomodate a larger image.
>
>  => Your WinRE version, on the partition is no longer supported.
> In hindsight, if we had this same discussion in June 2023(when the first
> WinRE partition update was included in monthly cumulative updates), the
> answer would be same.
>  - To resolve - disable the current, shrink C and create a new after
> Windows and one larger than the original(e.g. 1024 MB).
>
> Your issue is not than uncommon.

I can vouch for that. Exactly the same problem I had with the last one
I fixed this on. When I went back and checked the version of the winre
after Winston's suggestion after I thought I had it all, it still wasn't
updated. I deleted the .wim file in the recovery directory and
re-enabled and finally got it all done properly.

--
Stand With Israel!

From the DISM output:

Version : 10.0.19041
ServicePack Build : 1
ServicePack Level : 0
Edition : WindowsPE <---------- WinRE isn't just a reduced WinPE?
Created : 12/7/2019 - 1:11:48 AM <--- Over 4 years ago.
Modified : 10/20/2020 - 11:48:59 PM <--- Over 3 years ago.

If there have been WinRE updates since then (without the need for
enlarging the Recovery partition), why didn't WU get them? I've not had
any failed updates until KB5034441 which requires enlarging the Recovery
partition.

You say my version of WinRE is no longer supported. That means there
were subsequent versions of WinRE to replace mine. Obviously WU never
found one until KB5034441.

You: - To resolve - disable the current, shrink C and create a new after
Windows and one larger than the original(e.g. 1024 MB).

I've got plenty of unallocated space after the OS partition (the last
partition) to consume in creating a Recovery partition for WinRE. Don't
need to shrink the OS partition.

The potential problem is deleting the existing Recovery partition (the
first partition) leaving it as unallocated space. Partition enumeration
would then change on the remaining partitions:

Old Recovery partition 1 ---> unallocated (no partition)
EFI partition 2 ---> partition 1
Reserved partition 3 ---> partition 2
OS/bot partition 4 ---> partition 3
New Recovery unallocated ---> partition 4

All the partition enumerations get shifted. That could be hazardous or
even corruptive. Before Windows used the BCD database, the boot config
specified a target by disk and partition enumeration. Does anything
still use that old device enumeration by disk and partition number?

The instructions say to disable AND DELETE the Recovery partition, and
to create a new Recovery partition. They don't say to disable, delete,
and, if the WinRE partition was not at the end, to create a dummy
partition in place of the old WinRE partition. The instruction are for
a particular permutation of partition layout, not any others, and users
may have other permutations.

Your instruction is to just disable the old WinRE partition, but not to
delete it (but conflicts with Microsoft's instructions in KB5028997).
Seems I'd end up with 2 Recovery partitions: one disabled, and one
enabled. That could be confusing later. My way of deleting the old
WinRE partition, and creating a new one in its place (but not bothering
to format) might make it clear later that the old partition is a
placeholder or dummy partition. I can't see a need for a meager 519 MB
partition, so it'll sit there using space for no purpose.

Seems you and I are agree: the WinRE partition should be created at the
end whether by shrinking the OS partition assumed to be at the end of
the partition layout and butting against the end of the disk, or by
using unallocated space after it. The old WinRE partition at the
beginning gets disabled but its partition is retained (resulting in 2
Recovery partitions after creating a new one at the end), or delete the
old WinRE partition and create a new dummy partition in its place.
Either method retains the partition enumeration in the existing layout.

Doesn't take much online reading to find users that are getting fucked
over by Microsoft's instructions. Even with the expected partition
layout, they get to the "reagentc /enable" command, it fails, and they
don't have a usable WinRE partition.

For Microsoft to fix KB5034441 means they'll have to come up with a
script that handles all permutations of partition layouts, and without
screwing up the existing partition enumeration in the result -- unless
partition enumeration is no longer implemented in any part of the OS or
boot loader.

sticks <wolverine01@charter.net> wrote:

> When I went back and checked the version of the winre after Winston's
> suggestion after I thought I had it all, it still wasn't updated. I
> deleted the .wim file in the recovery directory and re-enabled and
> finally got it all done properly.

Is that a .wim file somewhere in the Recovery /partition/? If so, did
you mount the Recovery partition to get a drive letter assigned to get
at the file system to delete a winre.wim file in the Recovery partition?

Or was it a .wim file in the C:\Recovery directory (aka folder)?

I didn't find a .wim file under C:\Recovery, but I found a winre.wim
file under C:\$WinREAgent\Backup and an update.wim file under
C:\$WinREAgent\Scratch.

https://www.majorgeeks.com/content/page/what_is_the_winreagent_folder_and_can_i_delete_it.html

Seems C:\$WinREAgent is a temp folder that got left behind after a
failed WinRE update, possibly for KB5034441. That I don't have a
winre.wim file under C:\Recovery doesn't seem a problem, either. I
thought the C:\Recovery folder (along with Windows.old) was to let you
revert back to a prior version of Windows after an upgrade. I don't do
Windows upgrades. I always do fresh Windows installs. There are just a
couple files in my C:\Recovery folder, and no winre.wim file, either.
From some reading, the winre.wim file under C:\Recovery is there if
there is no Recovery partition for it.

C:\Recovery
| ReAgentOld.xml
|__ OEM
AfterImageApply_BDB0C1E8-6951-46C4-AB7F-C07B29F462FD.cmd
ResetConfig.xml

The .cmd file is a batch script that looks to delete the window.old
folder. Probably got scheduled to run 30 days after a Windows update
since you have 30 days from an update to revert using windows.old.

The ReAgentOld.xml refers to a C:\Recovery\WindowsRE folder. I don't
have one, but the path is relative, so maybe its in the file system on
the Recovery partition.

On 3/5/2024 12:05 PM, VanguardLH wrote:
> sticks <wolverine01@charter.net> wrote:
>
>> When I went back and checked the version of the winre after Winston's
>> suggestion after I thought I had it all, it still wasn't updated. I
>> deleted the .wim file in the recovery directory and re-enabled and
>> finally got it all done properly.
>
> Is that a .wim file somewhere in the Recovery /partition/? If so, did
> you mount the Recovery partition to get a drive letter assigned to get
> at the file system to delete a winre.wim file in the Recovery partition?
>
> Or was it a .wim file in the C:\Recovery directory (aka folder)?

I have misspoke. I believe the file I renamed/deleted was ReAgent.xml
located in Windows\System32\Recovery directory. First I disabled
(reagentc /disable), then renamed the file, then enabled.

> I didn't find a .wim file under C:\Recovery, but I found a winre.wim
> file under C:\$WinREAgent\Backup and an update.wim file under
> C:\$WinREAgent\Scratch.
>
> https://www.majorgeeks.com/content/page/what_is_the_winreagent_folder_and_can_i_delete_it.html
>
> Seems C:\$WinREAgent is a temp folder that got left behind after a
> failed WinRE update, possibly for KB5034441. That I don't have a
> winre.wim file under C:\Recovery doesn't seem a problem, either. I
> thought the C:\Recovery folder (along with Windows.old) was to let you
> revert back to a prior version of Windows after an upgrade. I don't do
> Windows upgrades. I always do fresh Windows installs. There are just a
> couple files in my C:\Recovery folder, and no winre.wim file, either.
> From some reading, the winre.wim file under C:\Recovery is there if
> there is no Recovery partition for it.

Sorry for the confusion on the wim file. On my system, I had the mess
of partitions like you had. I decided to do a fresh install in the end
following Winston's steps since all I needed to install was TBird and
Firefox as well as a few small programs. I had no data to worry about.
First I got rid of the unwanted partitions like the Recovery partition I
had in the wrong place and a 20 GB Restore partition that was at the
end, as well as Microsoft's newly installed Recovery partition that was
in between my two data partitions ( I didn't like that setup at all).
Before the install, I created a Recovery partition at the end of the
disk using the MS instructions you've most likely seen. I think I opted
for 1500MB. I then did the Windows full install. After finishing up
all looked well, or so I thought. Upon checking the versions as
Winston suggested, I still didn't have a working up to date ReAgent,
though it was enabled. The error I made was "Refreshing" that Recovery
partition instead of formatting it as Winston said to do before the
fresh install of Windows. That is when I deleted the ReAgent.xml file
and upon enabling it again it finally gave a new version of everything.
It found the winre.wim file on it's own and successfully updated the
Recovery partition and it took the 441 update immediately.

---snip---

--
Stand With Israel!

VanguardLH wrote on 3/5/24 11:05 AM:
> sticks <wolverine01@charter.net> wrote:
>
>> When I went back and checked the version of the winre after Winston's
>> suggestion after I thought I had it all, it still wasn't updated. I
>> deleted the .wim file in the recovery directory and re-enabled and
>> finally got it all done properly.
>
> Is that a .wim file somewhere in the Recovery /partition/? If so, did
> you mount the Recovery partition to get a drive letter assigned to get
> at the file system to delete a winre.wim file in the Recovery partition?

Windows source files on installation media includes install.wim or
install.esd
- the MCT created USB/DVD media has install.esd
- the ISO file has install.wim

During installation, the winre.wim is extracted from the respective above
install.* file
- Winre.wim is initially placed into the C:\Windows\System32\Recovery
folder
During the installation process to empty media the required GPT
partitions are created
=> System(EFI), MSR, Windows, WinRE(aka or named Recovery)
During installation, the installer eanbles the WinRE partition and in
doing so, moves(not copies) the winre.wim to the WinRE partition

Post installation and after a Windows admin logon, the logged on user can
open a Command.com or Powershell in admin mode and issue the following
command
reagentc /info
- to see the status of the WinRE
=> it will show the status (e.g. Enabled and the location, etc.)
=> if one issues the reagentc /disable command
- winre.wim is moved back(not copied) to the
C:\Windows\System32\Recovery folder. To see the file in this folder,
File Explorer needs to be configured to 'Show hidden files, folders' and
uncheck ' Hide protected operating system files)

Note: Looking at winre.wim's properties in the
C:\Windows\System32\Recovery isn't going to show the version or Service
Pack #.
=> You see that with the DISM command, the same command you used earlier
to report the info about your WinRE partition
DISM /Get-ImageInfo
/ImageFile:\\?\GLOBALROOT\device\harddisk#\partition#\Recovery\WindowsRE\winre.wim
/index:1
=> which you modified with the correct harddisk # and partition # that
you found when issuing the reagentc /info command.

--
....w¡ñ§±¤ñ

"...w¡ñ§±¤ñ " <winstonmvp@gmail.com> wrote:

> VanguardLH wrote on 3/5/24 11:05 AM:
>> sticks <wolverine01@charter.net> wrote:
>>
>>> When I went back and checked the version of the winre after Winston's
>>> suggestion after I thought I had it all, it still wasn't updated. I
>>> deleted the .wim file in the recovery directory and re-enabled and
>>> finally got it all done properly.
>>
>> Is that a .wim file somewhere in the Recovery /partition/? If so, did
>> you mount the Recovery partition to get a drive letter assigned to get
>> at the file system to delete a winre.wim file in the Recovery partition?
>
> Windows source files on installation media includes install.wim or
> install.esd
> - the MCT created USB/DVD media has install.esd
> - the ISO file has install.wim
>
> During installation, the winre.wim is extracted from the respective above
> install.* file
> - Winre.wim is initially placed into the C:\Windows\System32\Recovery
> folder
> During the installation process to empty media the required GPT
> partitions are created
> => System(EFI), MSR, Windows, WinRE(aka or named Recovery)
> During installation, the installer eanbles the WinRE partition and in
> doing so, moves(not copies) the winre.wim to the WinRE partition
>
> Post installation and after a Windows admin logon, the logged on user can
> open a Command.com or Powershell in admin mode and issue the following
> command
> reagentc /info
> - to see the status of the WinRE
> => it will show the status (e.g. Enabled and the location, etc.)
> => if one issues the reagentc /disable command
> - winre.wim is moved back(not copied) to the
> C:\Windows\System32\Recovery folder. To see the file in this folder,
> File Explorer needs to be configured to 'Show hidden files, folders' and
> uncheck ' Hide protected operating system files)
>
> Note: Looking at winre.wim's properties in the
> C:\Windows\System32\Recovery isn't going to show the version or Service
> Pack #.
> => You see that with the DISM command, the same command you used earlier
> to report the info about your WinRE partition
> DISM /Get-ImageInfo
> /ImageFile:\\?\GLOBALROOT\device\harddisk#\partition#\Recovery\WindowsRE\winre.wim
> /index:1
> => which you modified with the correct harddisk # and partition # that
> you found when issuing the reagentc /info command.

At this point, and to reduce risk, seems easier for me to save an image
backup of the disk (all partitions), save duplicate backups of just the
data (in .zip files, not backup files), delete all partitions on the
disk, and use the MediaCreationTool22H2.exe tool to create an install
ISO used to lay a fresh install of Windows on the disk with whatever
partition layout it assumes.

Hopefully it will use the recommended GPT layout winston mentioned. If
the install ISO wants to use up all disk space for the partitions, I'll
use a 3rd party partition manager to shrink the OS partition enough to:
- Allow enlarging the WinRE partition up to 1 GB (so later WinRE updates
that want more room will have some).
- 10 GB of unallocated space at the end (after the Recovery partition)
to up the drive maker's default unassignable space (6-10%) for SSD
overprovisioning to provide a total of 16-20%.
- Reinstall all the software again.
- Recover all the data.

Or wait until Windows 12 comes out sometime in 2025 (perhaps around or
just before Oct 2025 when Win10 support ends), and start with a fresh
install of Win12 on a wiped disk. Then install the software, recover
the data, and go forward with whatever partition layout the Win12 ISO
puts on the disk. I prefer fresh installs, so nothing unwanted migrates
from the old OS. I can do a lot of work now to fix something I don't
use, or wait 20 months to do the same effort, but with a new OS version.
Well, it might be 2 years plus 20 months from now since I wait a couple
years for a new version of Windows to come out to iron out all the bugs
before I start using it.

In the meantime, Microsoft could address the Bitlocker vulnerability
with a smaller WinRE image that'll fit inside the old Recovery
partition. Won't have to do anything with partition management to get
the fixed WinRE.

On 3/5/2024 2:39 PM, VanguardLH wrote:
> At this point, and to reduce risk, seems easier for me to save an image
> backup of the disk (all partitions), save duplicate backups of just the
> data (in .zip files, not backup files), delete all partitions on the
> disk, and use the MediaCreationTool22H2.exe tool to create an install
> ISO used to lay a fresh install of Windows on the disk with whatever
> partition layout it assumes.

I saved this from the thread he was helping me on.
---------

When clean installing Windows by booting the media I use the Advanced
options mode allowing me command line control and access to Diskpart for
running a Diskpart script(*.txt file). The script(while in Diskpart)
isn't necessary since all commands can be entered/typed manually, but
using the script ensures no errors(typing), streamlines the process and
it's faster.
- Here's an example script of all the steps for a device with a single
256 GB SSD as Disk 0.
**************
rem DISKPART script
rem Disk 0 with a single 256 GB SSD
rem Creates GPT(EFI MSR Windows with 2 GB Recovery)
rem Disk 0 OpSy Windows10 Pro 22H2
rem Select Disk, wipe it empty, convert to GPT
select disk 0
clean
convert gpt
create partition efi size=100
format quick fs=fat32 label="System"
create partition msr size=16
create partition primary
shrink minimum=2048
format quick fs=ntfs label="Windows10Pro"
assign letter="W"
create partition primary size=2048
format quick fs=ntfs label="WinRE"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
rem Exit Diskpart
rem written by winston
exit
******************

Once done(diskpart exited), all that remains is to continue clean
installing Win10 22H2 to the Windows partition.

--
Stand With Israel!

VanguardLH wrote on 3/5/24 1:39 PM:
> At this point, and to reduce risk, seems easier for me to save an image
> backup of the disk (all partitions), save duplicate backups of just the
> data (in .zip files, not backup files), delete all partitions on the
> disk, and use the MediaCreationTool22H2.exe tool to create an install
> ISO used to lay a fresh install of Windows on the disk with whatever
> partition layout it assumes.
>
> Hopefully it will use the recommended GPT layout winston mentioned. If
> the install ISO wants to use up all disk space for the partitions, I'll
> use a 3rd party partition manager to shrink the OS partition enough to:
> - Allow enlarging the WinRE partition up to 1 GB (so later WinRE updates
> that want more room will have some).
> - 10 GB of unallocated space at the end (after the Recovery partition)
> to up the drive maker's default unassignable space (6-10%) for SSD
> overprovisioning to provide a total of 16-20%.
> - Reinstall all the software again.
> - Recover all the data.
>

When wiping and clean installing Win10 22H2...why not just use the
Advanced option and use Diskpart to create and format(where necessary all
the partitions to you desired size) rather than tweak it later with 3rd
party software.

An example could be provided if your desired partitioning sizes were
provided for the Windows, any data partitions, and whatever you'd like to
have for unallocated(apparently overprovisioning[1])

[1] very few admins in the Enterprise community would overprovision.
Why? B/c they would already have considered, and well in advance, to
never install a piece of hardware(SSD) with a size that would run out of
space(the primary reason to overprovision)
- if no chance of running out of space on the SSD, overprovisioning,
imo, is a waste.

Here's(see below) an example Diskpart script for a 1TB SSD that creates
the 4 required GPT partitions in the correct order(System, MSR, Windows,
WinRE) and a Data Partition.
In the example script:
- the Windows partition is given the label 'W10P'(abbrev. for Win10 Pro)
- the WinRE partition label is 'WinRE'
- the Data partition label is 'Files'
Note: The labels are examples, one can label them to their own preference
e.g. W10P22H2, Recovery, Data
- NTFS has a 32 character label limit (I like to keep it 8 or less)

rem DISKPART script 1TB single SSD os w data partition
rem Creates GPT(EFI MSR Windows Recovery and Files)
rem OpSy: Windows10P 22H2 250 GB
rem Data: Files Partition 750 GB or balance
rem ---------------------------------------------------
rem Select Disk, wipe it empty, convert to GPT
rem
select disk 0
clean
convert gpt
rem
rem ---------------------------------------------------
rem Create & format 100 MB EFI System partition
rem
create partition efi size=100
format quick fs=fat32 label="System"
rem
rem ---------------------------------------------------
rem Create 16 MB MSR partition (will not be formatted)
rem
create partition msr size=16
rem
rem ---------------------------------------------------
rem Create a 250 GB (256,000 MB) partition primary OS
rem Diskpart uses MB units 250x1024=256000 MB
create partition primary size=256000
rem
rem ---------------------------------------------------
rem Format OS partition, label it, assign drive letter
rem
format quick fs=ntfs label="W10P"
assign letter="W"
rem
rem ---------------------------------------------------
rem Create & format a 1 GB recovery partition.
rem Notice that ID must be set exactly as shown!
rem
rem Create 1 GB WinRE partition
create partition primary size=1024
format quick fs=ntfs label="WinRE"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
rem
rem ---------------------------------------------------
rem Create partition for Data using all free space
rem
create partition primary
rem
rem ---------------------------------------------------
rem Format 2nd partition, label it, assign drive letter
rem
format quick fs=ntfs label="Files"
assign letter="Z"
rem
rem ---------------------------------------------------
rem Exit Diskpart
rem
rem written by winston
exit

The script file(*.txt) can be placed on bootable USB media and run as a
diskpart command from an admin command prompt using the Advanced options
provided by the boot media installation options. The script, not
necessary, i.e. those commands can be entered(typed in manually) in diskpart.

The script(or manually entered) commands could easily be modified, for a
different size SSD(e.g 2 TB) to specify a size for the Data partition and
leave unallocated space at the end of disk.

Fyi...shout of to 'sticks', his post Mar 5 2024 3:24 PM(my time zone)
provided an example for a 256 GB disk.

--
....w¡ñ§±¤ñ

"...w¡ñ§±¤ñ " <winstonmvp@gmail.com> wrote:

> VanguardLH wrote on 3/5/24 1:39 PM:
>> At this point, and to reduce risk, seems easier for me to save an image
>> backup of the disk (all partitions), save duplicate backups of just the
>> data (in .zip files, not backup files), delete all partitions on the
>> disk, and use the MediaCreationTool22H2.exe tool to create an install
>> ISO used to lay a fresh install of Windows on the disk with whatever
>> partition layout it assumes.
>>
>> Hopefully it will use the recommended GPT layout winston mentioned. If
>> the install ISO wants to use up all disk space for the partitions, I'll
>> use a 3rd party partition manager to shrink the OS partition enough to:
>> - Allow enlarging the WinRE partition up to 1 GB (so later WinRE updates
>> that want more room will have some).
>> - 10 GB of unallocated space at the end (after the Recovery partition)
>> to up the drive maker's default unassignable space (6-10%) for SSD
>> overprovisioning to provide a total of 16-20%.
>> - Reinstall all the software again.
>> - Recover all the data.
>>
>
> When wiping and clean installing Win10 22H2...why not just use the
> Advanced option and use Diskpart to create and format(where necessary all
> the partitions to you desired size) rather than tweak it later with 3rd
> party software.

Could do that, too.

> [1] very few admins in the Enterprise community would overprovision.
> Why? B/c they would already have considered, and well in advance, to
> never install a piece of hardware(SSD) with a size that would run out of
> space(the primary reason to overprovision)
> - if no chance of running out of space on the SSD, overprovisioning,
> imo, is a waste.

Overprovisioning isn't about have spare space available for later. It's
about increasing the longevity of the drive.

VanguardLH wrote on 3/6/24 3:43 PM:
>
> Overprovisioning isn't about have spare space available for later. It's
> about increasing the longevity of the drive.
>

My hardware and security colleagues advise that it offers no additional
value when the SSD has sufficient free spacce(iirc the general rule -
same imapact/effect with 10-15% free unused space) on the Windows and if
present Data partitions

Additionally all reputable SSD manufacturer's have over provisioning
built in.

It tweaking for the sake of being able to tweak, micromanaging an
unnecessary variable.

--
....w¡ñ§±¤ñ

"...w¡ñ§±¤ñ " <winstonmvp@gmail.com> wrote:

> VanguardLH wrote on 3/6/24 3:43 PM:
>>
>> Overprovisioning isn't about have spare space available for later. It's
>> about increasing the longevity of the drive.
>>
>
> My hardware and security colleagues advise that it offers no
> additional value when the SSD has sufficient free spacce(iirc the
> general rule - same imapact/effect with 10-15% free unused space) on
> the Windows and if present Data partitions

But "free space" is unallocated space which is what gets used for
overprovisioning.

> Additionally all reputable SSD manufacturer's have over provisioning
> built in.

SSDs come with some amount already for overprovisioning which can never
be assigned to a partition nor left for unallocated (free) space. The
value I've seen mentioned is 6 to 10% of the capacity of the disk. I've
already mentioned this.

> It tweaking for the sake of being able to tweak, micromanaging an
> unnecessary variable.

If you want MORE than what the disk maker already allocated for
unassigned free space for overprovisioning, you leave more unallocated
space on the disk. You don't need to add more unless you want more to
lengthen the longevity of your SSD.

The larger the volume of writes to the SSD, the larger you want
overprovisioning. I already gave this link:

https://www.minitool.com/partition-disk/ssd-over-provisioning.html
More benefits of SSD over-provisioning:

- Reduce time for Garbage Collection: As previously stated, GC creates
free blocks to temporarily store data while erasing blocks of invalid
data. In this case, OP gives controllers extra free space needed to move
data and results in faster execution.
- Reduce power consumption: Thanks to OP, SSD controllers can operate
quickly, resulting in less power from devices to complete tasks.
- Boost SSD performance: OP offers the flash controller extra buffer
space for managing P/E cycles and ensuring a write operation will have
immediate access to a pre-erased block. So, overprovisioning increases
SSD performance and even maintains SSD performance over time.
- Increase SSD lifespan: OP can make SSDs work more smartly, so wear and
tear will be minimized on SSDs.

Not difficult to find more articles on "SSD overprovisioning", and why
you might want more than what the drive maker provided. Here are some
others:

https://www.techtarget.com/searchstorage/definition/overprovisioning-SSD-overprovisioning
https://www.seagate.com/blog/ssd-over-provisioning-benefits-master-ti/
https://blog.westerndigital.com/why-overprovision-an-ssd/

Better performance by reducing time for GC and reduced power consumption
are not why *I* add more overprovisioning beyond in inbuilt amount from
the drive maker. A boost in performance is nice, but not super
critical. It's the increased longevity that I'm tweaking for, by
reducing write amplification. I didn't pull this out of the air, or get
convinced by the first article of someone mentioning how to increase
overprovisioning, or why. Not only did I read articles from
well-regarded sites, but also from the disk makers own sites.

Don't know who you're talking to for admins of workstation setups.
Consumer-grade disks have about 6-10% OP built in, and that space can
never be assigned nor is it accessible unallocated space. Server-grade
disks have 20%, or more, OP pre-assigned, because they get more write
volume than workstations. If longevity is upped for SSD server-grade
disks then it's good for me, too.

It's also a reason that the SSD makers supply their own overprovisioning
tool which cannot touch the in-built OP space, but can modify
partitioning to increase unallocated space in the assignable space.

Most users don't know anything about overprovisioning. They don't want
to know than they must to use the disk. They don't even do any
partitioning, and would never touch diskpart. That is not the audience
here. Even armed with the information, most users will just go with how
the disk was delivered to them, and not bother with educating themselves
on OP nor bother to add more.

You don't need to defrag your HDD, either. That's a tweak to improve
performance, but does it really affect load times of your everyday
software, like a word processor, or file writes you do? Yes, you can
run benchmarks, but that's not why you bought the computer. Many users
never defrag their HDDs, but they don't realize there is a scheduled
event that does it for them. Some users employ 3rd-party defraggers
that think they know a better layout, but MS defrag will undo to use its
own, so the users wonder why everytime they run a defragger that it has
lots to defrag - a battle of layouts between multiple defraggers. There
are lots of tweaks you can do, but you don't HAVE to do any of them.
Overprovisioning beyond the inbuilt unassignable OP space already on the
disk is another tweak. If users didn't want to do tweaks, we wouldn't
be using general-purpose operating systems, like Windows.