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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"...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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

However, since Microsoft had *not* updated the image in my WinRE
partition for over 2 years, why bother with this crap now?

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!

Why? I've never needed the WinRE (Recovery) partition, anyway. I go
through all the effort of wiping the disk, lay down a fresh install of
Windows, redo all the config and tweaks I've done to my old Windows
install, reinstall all the apps, an restore my user data back to the new
C: partition -- all just to get the WinRE partition as the last one
before the unallocated space at the end. Never used the WinRE
partition, Microsoft hasn't updated it as you claim, so I do a ton of
work, risk my setup, for no benefit at all.

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.

That's not the severe problem. Losing 250 MB of 190 GB of unallocated
space is a non-issue. It's Microsoft instructions that would move the
WinRE partition from being 1st to being 4th (last before unallocated
space). I still remember there are programs, including Windows, that
rely on the physical numbering of disks and partitions to find them.
Walking down the 2nd to 4th partitions into the trailing unallocated
space, and enlarging the WinRE partition still positioned where it was (partition #1), seems more safe than jumbling the partitions around each
other.

My point is that Microsoft's instructions can be dangerous, especially
if you don't have the partition layout they assume, but which the old
ISO install images didn't obey regarding "proper" GPT partition layout.
Even when the partition layout is as expect AFTER some version of the
ISO image created by MCT, all the work to increase the WinRE partition
can still fail. Read online to see how many users following Microsoft's instructions only to run "reagentc /enable" to have it fail, and now
they don't have a usable WinRE partition at all. A huge change to
accomodate got tiny amout of code delta to fix a Bitlocker
vulnerability, even for users not using Bitlocker.

And, no, I don't see the WinRE has been updated in over 2 years despite
you say it gets updated often. Maybe all those delta updates of WinRE
is more typical on Pro or server editions of Windows.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"...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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"...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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"...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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/7/2024 3:40 AM, ...w¡ñ§±¤ñ 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

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.

https://www.techpowerup.com/ssd-specs/samsung-870-evo-1-tb.d3

Overprovisioning: 92.7 GB / 10.0 %

https://www.techpowerup.com/ssd-specs/samsung-870-evo-4-tb.d5

Overprovisioning: 370.7 GB / 10.0 %

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul <nospam@needed.invalid> wrote:

https://www.techpowerup.com/ssd-specs/samsung-870-evo-1-tb.d3

Overprovisioning: 92.7 GB / 10.0 %

https://www.techpowerup.com/ssd-specs/samsung-870-evo-4-tb.d5

Overprovisioning: 370.7 GB / 10.0 %

I'd like to know where they got the OP spec. Can't find it mentioned at Samsung's site:

https://semiconductor.samsung.com/us/consumer-storage/internal-ssd/870evo/

Nor in the linked docs (datasheet, brochure). Samsung has their data
center SSD doc at:

http://semiconductor.samsung.com/resources/white-paper/S190311-SAMSUNG-Memory-Over-Provisioning-White-paper.pdf

What is OP (over-provisioning)?
Typically, Samsung DC SSDs are set to provide 6.7% of capacity for OP
by default, but the user can manually adjust the size of the space if
he or she requires additional OP depending on the user environment.

I guess you could figure out the factory OP space by computing the
difference between rated capacity and actual usable capacity (without
any partitioning, just what you could define in the usable space), as
mentioned in the "How do I calculate the OP ratio?" section.

The article also mentions how having more OP space will provide a
performance boost to SSDs to allow for faster garbage collection, and
show a graph under the "What are the advantages of increasing OP?"
section, along with increased longevity with more OP space.

The article is for data center (DC) SSDs. I thought the drive makers
allocated more factory OP for those, like 20% OP space (and 6.7% to 10%
for consumer SSDs) to accomodate the expectation by their enterprise
customers of longer longevity and longer performance maintenance, but
not per Samsung's article. The folks I know as sysadmins increase OP
space to reduce failure rate, and try to maintain new-disk performance.
The SSDs are far more than big enough to afford losing a bit of space in
the OS/boot partition to accomodate for more OP space (as unallocated
space on the disk).

I suspect the TechPowerUp articles are just assuming what is the typical factory/inherent OP space instead of actually somehow measuring it. You
can always find out how much unallocated space there is on an SSD just
by using Disk Management (diskmgmt.msc), a 3rd-party partition manager,
or maybe even with diskpart, but those won't show the factory OP space
of which you will never have access. If they have a means of
interrogating the SSD's firmware to get at how big is the factory OP
space, I'd sure love to know what tool to use to find that out.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/7/2024 1:53 PM, VanguardLH wrote:

Paul <nospam@needed.invalid> wrote:

https://www.techpowerup.com/ssd-specs/samsung-870-evo-1-tb.d3

Overprovisioning: 92.7 GB / 10.0 %

https://www.techpowerup.com/ssd-specs/samsung-870-evo-4-tb.d5

Overprovisioning: 370.7 GB / 10.0 %

I'd like to know where they got the OP spec. Can't find it mentioned at Samsung's site:

https://semiconductor.samsung.com/us/consumer-storage/internal-ssd/870evo/

Nor in the linked docs (datasheet, brochure). Samsung has their data
center SSD doc at:

http://semiconductor.samsung.com/resources/white-paper/S190311-SAMSUNG-Memory-Over-Provisioning-White-paper.pdf

What is OP (over-provisioning)?
Typically, Samsung DC SSDs are set to provide 6.7% of capacity for OP
by default, but the user can manually adjust the size of the space if
he or she requires additional OP depending on the user environment.

I guess you could figure out the factory OP space by computing the
difference between rated capacity and actual usable capacity (without
any partitioning, just what you could define in the usable space), as mentioned in the "How do I calculate the OP ratio?" section.

The article also mentions how having more OP space will provide a
performance boost to SSDs to allow for faster garbage collection, and
show a graph under the "What are the advantages of increasing OP?"
section, along with increased longevity with more OP space.

The article is for data center (DC) SSDs. I thought the drive makers allocated more factory OP for those, like 20% OP space (and 6.7% to 10%
for consumer SSDs) to accomodate the expectation by their enterprise customers of longer longevity and longer performance maintenance, but
not per Samsung's article. The folks I know as sysadmins increase OP
space to reduce failure rate, and try to maintain new-disk performance.
The SSDs are far more than big enough to afford losing a bit of space in
the OS/boot partition to accomodate for more OP space (as unallocated
space on the disk).

I suspect the TechPowerUp articles are just assuming what is the typical factory/inherent OP space instead of actually somehow measuring it. You
can always find out how much unallocated space there is on an SSD just
by using Disk Management (diskmgmt.msc), a 3rd-party partition manager,
or maybe even with diskpart, but those won't show the factory OP space
of which you will never have access. If they have a means of
interrogating the SSD's firmware to get at how big is the factory OP
space, I'd sure love to know what tool to use to find that out.

I tried to find a spec for the flash chip, but there was no match in Google.

Generally, Techpowerup are pretty good about traceability on specs.
They have specs for video cards too.

Quite frequently, review articles contain more information than is
on the manufacturer web page, and this is because they've talked to technical/promoter types at a company, when a product comes out. That
is mainly where extra information comes from. While a tool from the manufacturer may have the info, it's no more trustworthy than if
Crystal gave it in a readout.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <MPG.404d5d2d6d5bf740989aaf@news.eternal-september.org>, 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!

Sorry about the lack of acknowledgement for these valuable responses. I've been really quite unwell. I'll get back to this when I'm recovered, which might be a good few days yet.

--

Phil, London

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/8/2024 1:10 PM, Philip Herlihy wrote:

Sorry about the lack of acknowledgement for these valuable responses. I've been really quite unwell. I'll get back to this when I'm recovered, which might be a good few days yet.

I'm sure everybody understands and hopes you get better soon!


--
Stand With Israel!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <usg34o$1ubue$1@dont-email.me>, sticks wrote...

On 3/8/2024 1:10 PM, Philip Herlihy wrote:

Sorry about the lack of acknowledgement for these valuable responses. I've been really quite unwell. I'll get back to this when I'm recovered, which might be a good few days yet.

I'm sure everybody understands and hopes you get better soon!

Thanks so much. Starting to go through all these most helpful replies now. (After a fairly grim few days!)

--

Phil, London

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/13/2024 7:12 PM, Philip Herlihy wrote:

In article <us19va$2d26r$1@dont-email.me>, Paul wrote...

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

Thanks Paul - and everyone who's contributed.

Notwithstanding the excursions about WinRE (95% of which went over my head) I think I've got the gist of this now.

The machine is a Dell XPS 13. Partitions (in Disk Management) are (rounded): 500MB EFI System partition
225GB OS
852MB now Unallocated after my meddling
10GB Recovery Partition
1GB Recovery Partition

I've used manage-bde to list the Bitlocker Key (and ID) and I have a copy on another machine. There are two accounts on the laptop, both Local, and the Key/ID come out the same in both (just a sanity check!). A TPM ID is also listed, but that presumably is a constant for this machine.

I need to resize the partitions and re-create the WinRE partition in the Unallocated space. To do this, I can suspend (not disable) Bitlocker using the
manage-bde command with -disable and -enable arguments, I understand.

Any gotchas in that? And should I delete the other two Recovery Partitions before recreating the WinRE partition (same things, right?).

Phew! I'm getting to old for this s***, especially after a couple of weeks of
fever...

You should be doing these things in "priority order" :-)
Playing with garbage partitions, risks upsetting the
partition numbering. Which would not normally be an issue.
However, the reagentc info the OS has, currently has a partition
number specifying it, and that's what you're trying to
match with your re-creation session. As it is, I don't see
a reason why the partition map has not had the "hole removed".
I've had that happen before -- partition map renumbered in some
clever way, and me has to figure it out.

1) Suspend bitlocker.
2) Try the WinRE creation script.

It's perhaps the request to generate a partition with
a certain partition ID type, that causes diskpart to
think "this should really be placed to the right of C: "
and that's how it managed to auto-magically get the
partition number correct during this sequence. Otherwise,
deleting a partition, a newly created partition
would end up somewhere on the right. Note that, diskpart
does not feel inclined to always put partition numbers
in monotonic order (starting with LBA0). It is perfectly
happy to have partition 13, partition 1, partition 2 and so on.

But the thing is, the deleted partition, when it is
recreated, it's not in the "suspend" state. It's in
the unencrypted state when diskpart creates it.

I would think some other attack sequence is needed,
that meshes better with the proposed sub-sequence
(the original WinRE "script").

Another way to do this, would be with
Macrium, a restore of the missing partition.
Assuming a backup is/was available.

Remember that you have two objectives:

1) Achieve WinRE enabled again (a kind of proof that
maybe it might work when called upon).
2) Leave partition state such that, future Microsoft
badly written updates, behave in a predictable way.
This means the bitlocker has to be repaired so it
matches how it was previously. Whatever state it was in
(FDE or whatever).

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/13/2024 7:12 PM, Philip Herlihy wrote:

In article <us19va$2d26r$1@dont-email.me>, Paul wrote...

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

Thanks Paul - and everyone who's contributed.

Notwithstanding the excursions about WinRE (95% of which went over my head) I think I've got the gist of this now.

The machine is a Dell XPS 13. Partitions (in Disk Management) are (rounded): 500MB EFI System partition
225GB OS
852MB now Unallocated after my meddling
10GB Recovery Partition
1GB Recovery Partition

I've used manage-bde to list the Bitlocker Key (and ID) and I have a copy on another machine. There are two accounts on the laptop, both Local, and the Key/ID come out the same in both (just a sanity check!). A TPM ID is also listed, but that presumably is a constant for this machine.

I need to resize the partitions and re-create the WinRE partition in the Unallocated space. To do this, I can suspend (not disable) Bitlocker using the
manage-bde command with -disable and -enable arguments, I understand.

Any gotchas in that? And should I delete the other two Recovery Partitions before recreating the WinRE partition (same things, right?).

Phew! I'm getting to old for this s***, especially after a couple of weeks of
fever...

https://marcus.handte.org/2018/09/15/installing-the-windows-recovery-environment-for-bitlocker/

"When activating the BitLocker for my system drive, BitLocker detected that the
Recovery Environment was not working and rightfully decided to shrink the
main system partition to add another partition with 868MB at the end of the disk.

However, this new recovery disk was also non-functional. As a result,
BitLocker reported that my Surface Pro "does not support entering a
BitLocker recovery password during startup" and that I should ask my
"administrator to configure Windows Recovery Environment so that
you can use BitLocker"
"

You would want to try that, use Bitlocker as a formatting tool :-)
There are steps there for copying the materials back.

I would try that with "reagentc /disable". As Bitlocker, in whatever disguise it is appearing in, feels the need to have a recovery procedure at boot time. And that works best, if the Recovery partition is doing the booting,
at the time it happens.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ustvec$1e302$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...

Philip Herlihy wrote on 3/13/24 4:12 PM:

The machine is a Dell XPS 13. Partitions (in Disk Management) are (rounded):
500MB EFI System partition
225GB OS
852MB now Unallocated after my meddling
10GB Recovery Partition
1GB Recovery Partition

I need to resize the partitions and re-create the WinRE partition in the Unallocated space. To do this, I can suspend (not disable) Bitlocker using the
manage-bde command with -disable and -enable arguments, I understand.

Any gotchas in that? And should I delete the other two Recovery Partitions before recreating the WinRE partition (same things, right?).

Phew! I'm getting to old for this s***, especially after a couple of weeks of
fever...

Without knowing which Recovery partition you changed..let's back up
Did you use an admin Command or Powershell console to run/execute:
1. reagentc /info
- to determine the active WinRE partition
2. reagentc /disable
- to disable the active recovery partition
3. Is the unallocated space after the o/s partition previously the active then later disabled before deleting the recovery partition?

If the unallocated space was the old, no longer present active recovery partition, the shrink C by 172 MB then create WinRE as a 1024 MB partition.
- use Diskpart for the above
- in advance, ensure you know the o/s harddisk # because you need to
select the correct disk to shrink c and create the new WinRE partition on
the same disk in that unallocated space(after the o/s partition)

If you need the steps to do so reply for more detailed help.

I'm ready to tackle this now, using the steps listed here: https://bit.ly/3TCu9Y8

I've successfully backed-up all the data on the machine, and copied it to a new machine (the present machine had been regarded as "broken" until I fixed it!). If anything goes wrong, I should be able to reset or even reload it, and I won't hesitate to do that if needed.

Previously I'd tried the 'shrink' command but that didn't succeed (presumably because of Bitlocker). I did go on to delete the WinRE partition, which is the one immediately following the OS partition, but didn't get any further. Now I'm confident I have the correct Bitlocker key (saved elsewhere!) and a copy of all the data, so I think the worst that can happen is that I have to reload Windows from scratch.


--

Phil, London

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ut2of9$2hmc1$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...

Philip Herlihy wrote on 3/15/24 11:05 AM:

In article <ustvec$1e302$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...

Philip Herlihy wrote on 3/13/24 4:12 PM:

The machine is a Dell XPS 13. Partitions (in Disk Management) are (rounded):
500MB EFI System partition
225GB OS
852MB now Unallocated after my meddling
10GB Recovery Partition
1GB Recovery Partition

...

I've now completed all the steps in https://bit.ly/3TCu9Y8, disabling and re- enabling Bitlocker on either side. Everything seemed to work, and all commands gave positive status. The 'stuck' update is now safely installed. Thanks to everyone for help with this.

Did you disable the the WinRE partition before deleting the WinRE partition?
- reagentc /disable
Did you verify the harddisk# and partition# of the WinRE recovery
partition before deleting the WinRE partition?
- reagentc /info

YES

If you disabled the WinRE partition before deletion, the necessaryt
winre.wim file will be located in C:\Windows\System32\Recovery
- you will need to configure File Explorer to see the file's presence
in the above folder
File Explorer/Options/View
- Enable 'Show hidden files, folders, and drives
- Uncheck 'Hide extensions of known file types'
- Uncheck 'Hide protected operating system files'

Well, it's not there now, though I have completed all the steps, including reagentc /enable, so from what you say winre.wim should have been moved to the newly re-created Recovery partition.

If the file is not present, it would seem to indicate you didn't disable
the WinRE partition prior to deleting the WinRE partition or something
else is/was in play.
- i.e. the file is important, because once a new Recovery partition is created, the reagentc /enable command will look for that file in C:\Windows\System32\Recovery and move it back(not copy) to the newly
created WinRE partition.

Do you have a backup image of the WinRE recovery partiton, e.g. Macrium Reflect?

No, but all the user data was copied off to another machine first, and I'd have been content to reinstall the machine if needed.

Please answer the questions(and advance thanks for doing so)

Least I could do after your help.

My knowledge on how the Recovery partition works is sketchy at best. I recognise winre.wim (I think?) as a possible source for system files when doing a DISM /online /RestoreHealth. Is there a concise *introductory* article you could recommend for getting my head round all this?

--

Phil, London

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <MPG.40600faf8bed89c6989ab7@news.eternal-september.org>, Philip Herlihy wrote...

In article <ut2of9$2hmc1$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...

Philip Herlihy wrote on 3/15/24 11:05 AM:

In article <ustvec$1e302$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...

Philip Herlihy wrote on 3/13/24 4:12 PM:

The machine is a Dell XPS 13. Partitions (in Disk Management) are (rounded):
500MB EFI System partition
225GB OS
852MB now Unallocated after my meddling
10GB Recovery Partition
1GB Recovery Partition

...

I've now completed all the steps in https://bit.ly/3TCu9Y8, disabling and re- enabling Bitlocker on either side. Everything seemed to work, and all commands
gave positive status. The 'stuck' update is now safely installed. Thanks to everyone for help with this.

Did you disable the the WinRE partition before deleting the WinRE partition?
- reagentc /disable
Did you verify the harddisk# and partition# of the WinRE recovery
partition before deleting the WinRE partition?
- reagentc /info

YES

If you disabled the WinRE partition before deletion, the necessaryt winre.wim file will be located in C:\Windows\System32\Recovery
- you will need to configure File Explorer to see the file's presence
in the above folder
File Explorer/Options/View
- Enable 'Show hidden files, folders, and drives
- Uncheck 'Hide extensions of known file types'
- Uncheck 'Hide protected operating system files'

Well, it's not there now, though I have completed all the steps, including reagentc /enable, so from what you say winre.wim should have been moved to the
newly re-created Recovery partition.

If the file is not present, it would seem to indicate you didn't disable the WinRE partition prior to deleting the WinRE partition or something
else is/was in play.
- i.e. the file is important, because once a new Recovery partition is created, the reagentc /enable command will look for that file in C:\Windows\System32\Recovery and move it back(not copy) to the newly created WinRE partition.

Do you have a backup image of the WinRE recovery partiton, e.g. Macrium Reflect?

No, but all the user data was copied off to another machine first, and I'd have
been content to reinstall the machine if needed.

Please answer the questions(and advance thanks for doing so)

Least I could do after your help.

My knowledge on how the Recovery partition works is sketchy at best. I recognise winre.wim (I think?) as a possible source for system files when doing
a DISM /online /RestoreHealth. Is there a concise *introductory* article you could recommend for getting my head round all this?

Reagentc /info gives the Recovery partition as partition 6, which Disk Management shows as immediately following the OS partition. After partition 6 there are two other Recovery partitions, presumably redundant. Can I delete them?


--

Phil, London

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/16/2024 5:53 PM, Philip Herlihy wrote:

In article <MPG.40600faf8bed89c6989ab7@news.eternal-september.org>, Philip Herlihy wrote...

In article <ut2of9$2hmc1$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...

Philip Herlihy wrote on 3/15/24 11:05 AM:

In article <ustvec$1e302$1@dont-email.me>, ...w¡ñ§±¤ñ wrote... >>>>>

Philip Herlihy wrote on 3/13/24 4:12 PM:

The machine is a Dell XPS 13. Partitions (in Disk Management) are (rounded):
500MB EFI System partition
225GB OS
852MB now Unallocated after my meddling
10GB Recovery Partition
1GB Recovery Partition

...

I've now completed all the steps in https://bit.ly/3TCu9Y8, disabling and re-
enabling Bitlocker on either side. Everything seemed to work, and all commands
gave positive status. The 'stuck' update is now safely installed. Thanks to
everyone for help with this.

Did you disable the the WinRE partition before deleting the WinRE partition?
- reagentc /disable
Did you verify the harddisk# and partition# of the WinRE recovery
partition before deleting the WinRE partition?
- reagentc /info

YES

If you disabled the WinRE partition before deletion, the necessaryt
winre.wim file will be located in C:\Windows\System32\Recovery
- you will need to configure File Explorer to see the file's presence
in the above folder
File Explorer/Options/View
- Enable 'Show hidden files, folders, and drives
- Uncheck 'Hide extensions of known file types'
- Uncheck 'Hide protected operating system files'

Well, it's not there now, though I have completed all the steps, including >> reagentc /enable, so from what you say winre.wim should have been moved to the
newly re-created Recovery partition.

If the file is not present, it would seem to indicate you didn't disable >>> the WinRE partition prior to deleting the WinRE partition or something
else is/was in play.
- i.e. the file is important, because once a new Recovery partition is >>> created, the reagentc /enable command will look for that file in
C:\Windows\System32\Recovery and move it back(not copy) to the newly
created WinRE partition.

Do you have a backup image of the WinRE recovery partiton, e.g. Macrium
Reflect?

No, but all the user data was copied off to another machine first, and I'd have
been content to reinstall the machine if needed.

Please answer the questions(and advance thanks for doing so)

Least I could do after your help.

My knowledge on how the Recovery partition works is sketchy at best. I
recognise winre.wim (I think?) as a possible source for system files when doing
a DISM /online /RestoreHealth. Is there a concise *introductory* article you
could recommend for getting my head round all this?

Reagentc /info gives the Recovery partition as partition 6, which Disk Management shows as immediately following the OS partition. After partition 6
there are two other Recovery partitions, presumably redundant. Can I delete them?

Yes, as long as your knowledge of the numbering is flawless.

Remember that Disk Management does not show the tiny 16MB MSR, as
it does not have a file system. But the partition table uses up
a number, to define a space for it. It's still a partition, and
that's how the numbering does not make sense when counting from 1.

What you typically see in Disk Management, is 1 3 4 5 6...
And partition 2 is the MSR. Partition 3 could be C:
Partition 4 could be the one used by ReagentC. If
you had a Partition 5 and Partition 6, they could be
deleted (as left-over versions of a Partition 4).

Just make sure that anything to the right of the deletion,
does not rely upon a partition number for its operation.
For example, a Linux uses a partition number for the GRUB boot
sequence, even though "most of the time" Linux stuff relies on
UUID/blkid for identifiers, which tends to make Linux number-independent.
It's when GRUB is installed, that the jump from one phase of GRUB
to the next, happens to use a partition number. If you were dual
booting and screwed it up, the Linux "Boot Repair" package could fix it for you.

When I had three of the Recovery Partitions to the right of C: , I did
delete two of them, but that was not on a Bitlockered PC. And I have
screwed up Linux booting, by removing a partition to the left of
Windows C: partition. In your situation, I don't think the odds
of damage are that high. But then, I don't understand what
the Bitlocker on a Home setup is doing, either :-) No idea.
It's supposed to be FDE, but it does not seem to be that.
I always thought FDE encrypted the entire drive, every byte of it.
It does not seem to be doing that.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ut55o8$341m1$1@dont-email.me>, Paul wrote...

On 3/16/2024 5:53 PM, Philip Herlihy wrote:

In article <MPG.40600faf8bed89c6989ab7@news.eternal-september.org>, Philip Herlihy wrote...

In article <ut2of9$2hmc1$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...

Philip Herlihy wrote on 3/15/24 11:05 AM:

In article <ustvec$1e302$1@dont-email.me>, ...w¡ñ§±¤ñ wrote... >>>>>

Philip Herlihy wrote on 3/13/24 4:12 PM:

The machine is a Dell XPS 13. Partitions (in Disk Management) are (rounded):
500MB EFI System partition
225GB OS
852MB now Unallocated after my meddling
10GB Recovery Partition
1GB Recovery Partition

...

I've now completed all the steps in https://bit.ly/3TCu9Y8, disabling and re-
enabling Bitlocker on either side. Everything seemed to work, and all commands
gave positive status. The 'stuck' update is now safely installed. Thanks to
everyone for help with this.

Did you disable the the WinRE partition before deleting the WinRE partition?
- reagentc /disable
Did you verify the harddisk# and partition# of the WinRE recovery
partition before deleting the WinRE partition?
- reagentc /info

YES

If you disabled the WinRE partition before deletion, the necessaryt
winre.wim file will be located in C:\Windows\System32\Recovery
- you will need to configure File Explorer to see the file's presence >>> in the above folder
File Explorer/Options/View
- Enable 'Show hidden files, folders, and drives
- Uncheck 'Hide extensions of known file types'
- Uncheck 'Hide protected operating system files'

Well, it's not there now, though I have completed all the steps, including >> reagentc /enable, so from what you say winre.wim should have been moved to the
newly re-created Recovery partition.

If the file is not present, it would seem to indicate you didn't disable >>> the WinRE partition prior to deleting the WinRE partition or something >>> else is/was in play.
- i.e. the file is important, because once a new Recovery partition is >>> created, the reagentc /enable command will look for that file in
C:\Windows\System32\Recovery and move it back(not copy) to the newly
created WinRE partition.

Do you have a backup image of the WinRE recovery partiton, e.g. Macrium >>> Reflect?

No, but all the user data was copied off to another machine first, and I'd have
been content to reinstall the machine if needed.

Please answer the questions(and advance thanks for doing so)

Least I could do after your help.

My knowledge on how the Recovery partition works is sketchy at best. I
recognise winre.wim (I think?) as a possible source for system files when doing
a DISM /online /RestoreHealth. Is there a concise *introductory* article you
could recommend for getting my head round all this?

Reagentc /info gives the Recovery partition as partition 6, which Disk Management shows as immediately following the OS partition. After partition 6
there are two other Recovery partitions, presumably redundant. Can I delete
them?

Yes, as long as your knowledge of the numbering is flawless.

Remember that Disk Management does not show the tiny 16MB MSR, as
it does not have a file system. But the partition table uses up
a number, to define a space for it. It's still a partition, and
that's how the numbering does not make sense when counting from 1.

What you typically see in Disk Management, is 1 3 4 5 6...
And partition 2 is the MSR. Partition 3 could be C:
Partition 4 could be the one used by ReagentC. If
you had a Partition 5 and Partition 6, they could be
deleted (as left-over versions of a Partition 4).

Just make sure that anything to the right of the deletion,
does not rely upon a partition number for its operation.
For example, a Linux uses a partition number for the GRUB boot
sequence, even though "most of the time" Linux stuff relies on
UUID/blkid for identifiers, which tends to make Linux number-independent. It's when GRUB is installed, that the jump from one phase of GRUB
to the next, happens to use a partition number. If you were dual
booting and screwed it up, the Linux "Boot Repair" package could fix it for you.

When I had three of the Recovery Partitions to the right of C: , I did
delete two of them, but that was not on a Bitlockered PC. And I have
screwed up Linux booting, by removing a partition to the left of
Windows C: partition. In your situation, I don't think the odds
of damage are that high. But then, I don't understand what
the Bitlocker on a Home setup is doing, either :-) No idea.
It's supposed to be FDE, but it does not seem to be that.
I always thought FDE encrypted the entire drive, every byte of it.
It does not seem to be doing that.

Paul

Thanks, Paul,

Diskpart lists the disks in this order:


Microsoft DiskPart version 10.0.19041.3636

Copyright (C) Microsoft Corporation.
On computer: DESKTOP-4C4MNUB

Disk 0 is now the selected disk.

Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 500 MB 1024 KB
Partition 2 Reserved 128 MB 501 MB
Partition 3 Primary 225 GB 629 MB
Partition 6 Recovery 1101 MB 225 GB
Partition 4 Recovery 10 GB 226 GB
Partition 5 Recovery 1078 MB 237 GB

(Output obtained from diskpart /s temp.txt | clip)

Disk Management (graphic) shows them in the same order.


--

Phil, London

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ut6btt$3ekrs$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...

Philip Herlihy wrote on 3/16/24 1:22 PM:

In article <ut2of9$2hmc1$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...

Philip Herlihy wrote on 3/15/24 11:05 AM:

In article <ustvec$1e302$1@dont-email.me>, ...w¡ñ§±¤ñ wrote... >>>>

Philip Herlihy wrote on 3/13/24 4:12 PM:

The machine is a Dell XPS 13. Partitions (in Disk Management) are (rounded):
500MB EFI System partition
225GB OS
852MB now Unallocated after my meddling
10GB Recovery Partition
1GB Recovery Partition

...

I've now completed all the steps in https://bit.ly/3TCu9Y8, disabling and re-
enabling Bitlocker on either side. Everything seemed to work, and all commands
gave positive status. The 'stuck' update is now safely installed. Thanks to
everyone for help with this.

Did you disable the the WinRE partition before deleting the WinRE partition?
- reagentc /disable
Did you verify the harddisk# and partition# of the WinRE recovery
partition before deleting the WinRE partition?
- reagentc /info

YES

If you disabled the WinRE partition before deletion, the necessaryt
winre.wim file will be located in C:\Windows\System32\Recovery
- you will need to configure File Explorer to see the file's presence >> in the above folder
File Explorer/Options/View
- Enable 'Show hidden files, folders, and drives
- Uncheck 'Hide extensions of known file types'
- Uncheck 'Hide protected operating system files'

Well, it's not there now, though I have completed all the steps, including reagentc /enable, so from what you say winre.wim should have been moved to the
newly re-created Recovery partition.

Now would be a good time to verify it as present and determine the
current Service Pack Build number and last modified date

Run reagentc /info and look for the harddisk# and partition#, then
replace the number in the following Powershell command, once done enter
the full now edited(with your harddisk and parition #'s) command line in
a Powershell admin window

DISM /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk#\partition#\Recovery\WindowsRE\winre.wim
/index:1

Once done, report five items from the output
Version, Service Pack Build, Service Pack Level, Created date, Modified date.

Details for image : \\?\GLOBALROOT\device\harddisk0\partition6\Recovery \WindowsRE\winre.wim

Index : 1
Name : Microsoft Windows Recovery Environment (x64)
Description : Microsoft Windows Recovery Environment (x64)
Size : 2,851,512,365 bytes
WIM Bootable : No
Architecture : x64
Hal : <undefined>
Version : 10.0.19041
ServicePack Build : 3920
ServicePack Level : 0
Edition : WindowsPE
Installation : WindowsPE
ProductType : WinNT
ProductSuite :
System Root : WINDOWS
Directories : 3789
Files : 18630
Created : 07/12/2019 - 07:11:48
Modified : 15/03/2024 - 19:10:39
Languages :
en-US (Default)
The operation completed successfully.


--

Phil, London

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/17/2024 11:31 AM, Philip Herlihy wrote:

In article <ut55o8$341m1$1@dont-email.me>, Paul wrote...

On 3/16/2024 5:53 PM, Philip Herlihy wrote:

In article <MPG.40600faf8bed89c6989ab7@news.eternal-september.org>, Philip >>> Herlihy wrote...

In article <ut2of9$2hmc1$1@dont-email.me>, ...w¡ñ§±¤ñ wrote... >>>>>

Philip Herlihy wrote on 3/15/24 11:05 AM:

In article <ustvec$1e302$1@dont-email.me>, ...w¡ñ§±¤ñ wrote... >>>>>>>

Philip Herlihy wrote on 3/13/24 4:12 PM:

The machine is a Dell XPS 13. Partitions (in Disk Management) are (rounded):
500MB EFI System partition
225GB OS
852MB now Unallocated after my meddling
10GB Recovery Partition
1GB Recovery Partition

...

I've now completed all the steps in https://bit.ly/3TCu9Y8, disabling and re-
enabling Bitlocker on either side. Everything seemed to work, and all commands
gave positive status. The 'stuck' update is now safely installed. Thanks to
everyone for help with this.

Did you disable the the WinRE partition before deleting the WinRE partition?
- reagentc /disable
Did you verify the harddisk# and partition# of the WinRE recovery
partition before deleting the WinRE partition?
- reagentc /info

YES

If you disabled the WinRE partition before deletion, the necessaryt
winre.wim file will be located in C:\Windows\System32\Recovery
- you will need to configure File Explorer to see the file's presence >>>>> in the above folder
File Explorer/Options/View
- Enable 'Show hidden files, folders, and drives
- Uncheck 'Hide extensions of known file types'
- Uncheck 'Hide protected operating system files'

Well, it's not there now, though I have completed all the steps, including >>>> reagentc /enable, so from what you say winre.wim should have been moved to the
newly re-created Recovery partition.

If the file is not present, it would seem to indicate you didn't disable >>>>> the WinRE partition prior to deleting the WinRE partition or something >>>>> else is/was in play.
- i.e. the file is important, because once a new Recovery partition is >>>>> created, the reagentc /enable command will look for that file in
C:\Windows\System32\Recovery and move it back(not copy) to the newly >>>>> created WinRE partition.

Do you have a backup image of the WinRE recovery partiton, e.g. Macrium >>>>> Reflect?

No, but all the user data was copied off to another machine first, and I'd have
been content to reinstall the machine if needed.

Please answer the questions(and advance thanks for doing so)

Least I could do after your help.

My knowledge on how the Recovery partition works is sketchy at best. I >>>> recognise winre.wim (I think?) as a possible source for system files when doing
a DISM /online /RestoreHealth. Is there a concise *introductory* article you
could recommend for getting my head round all this?

Reagentc /info gives the Recovery partition as partition 6, which Disk
Management shows as immediately following the OS partition. After partition 6
there are two other Recovery partitions, presumably redundant. Can I delete
them?

Yes, as long as your knowledge of the numbering is flawless.

Remember that Disk Management does not show the tiny 16MB MSR, as
it does not have a file system. But the partition table uses up
a number, to define a space for it. It's still a partition, and
that's how the numbering does not make sense when counting from 1.

What you typically see in Disk Management, is 1 3 4 5 6...
And partition 2 is the MSR. Partition 3 could be C:
Partition 4 could be the one used by ReagentC. If
you had a Partition 5 and Partition 6, they could be
deleted (as left-over versions of a Partition 4).

Just make sure that anything to the right of the deletion,
does not rely upon a partition number for its operation.
For example, a Linux uses a partition number for the GRUB boot
sequence, even though "most of the time" Linux stuff relies on
UUID/blkid for identifiers, which tends to make Linux number-independent.
It's when GRUB is installed, that the jump from one phase of GRUB
to the next, happens to use a partition number. If you were dual
booting and screwed it up, the Linux "Boot Repair" package could fix it for you.

When I had three of the Recovery Partitions to the right of C: , I did
delete two of them, but that was not on a Bitlockered PC. And I have
screwed up Linux booting, by removing a partition to the left of
Windows C: partition. In your situation, I don't think the odds
of damage are that high. But then, I don't understand what
the Bitlocker on a Home setup is doing, either :-) No idea.
It's supposed to be FDE, but it does not seem to be that.
I always thought FDE encrypted the entire drive, every byte of it.
It does not seem to be doing that.

Paul

Thanks, Paul,

Diskpart lists the disks in this order:

Microsoft DiskPart version 10.0.19041.3636

Copyright (C) Microsoft Corporation.
On computer: DESKTOP-4C4MNUB

Disk 0 is now the selected disk.

Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 500 MB 1024 KB
Partition 2 Reserved 128 MB 501 MB
Partition 3 Primary 225 GB 629 MB
Partition 6 Recovery 1101 MB 225 GB
Partition 4 Recovery 10 GB 226 GB
Partition 5 Recovery 1078 MB 237 GB

(Output obtained from diskpart /s temp.txt | clip)

Disk Management (graphic) shows them in the same order.

<sigh> :-) Classic partition renumbering goodness.

So does that mean the sequence is

reagentc /info
reagentc /disable

(remove partition 5, screw up partition order, 6 becomes some other partition number)

reagentc /setreimage <insert_renumbered_path_specification_here>
reagentc /enable
reagentc /info

or something.

I take it the 10GB partition is for some kind of OEM hardware-level recovery ?

Be careful.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/17/2024 11:18 AM, Philip Herlihy wrote:

In article <ut6btt$3ekrs$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...

Philip Herlihy wrote on 3/16/24 1:22 PM:

In article <ut2of9$2hmc1$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...

Philip Herlihy wrote on 3/15/24 11:05 AM:

In article <ustvec$1e302$1@dont-email.me>, ...w¡ñ§±¤ñ wrote... >>>>>>

Philip Herlihy wrote on 3/13/24 4:12 PM:

The machine is a Dell XPS 13. Partitions (in Disk Management) are (rounded):
500MB EFI System partition
225GB OS
852MB now Unallocated after my meddling
10GB Recovery Partition
1GB Recovery Partition

...

I've now completed all the steps in https://bit.ly/3TCu9Y8, disabling and re-
enabling Bitlocker on either side. Everything seemed to work, and all commands
gave positive status. The 'stuck' update is now safely installed. Thanks to
everyone for help with this.

Did you disable the the WinRE partition before deleting the WinRE partition?
- reagentc /disable
Did you verify the harddisk# and partition# of the WinRE recovery
partition before deleting the WinRE partition?
- reagentc /info

YES

If you disabled the WinRE partition before deletion, the necessaryt
winre.wim file will be located in C:\Windows\System32\Recovery
- you will need to configure File Explorer to see the file's presence >>>> in the above folder
File Explorer/Options/View
- Enable 'Show hidden files, folders, and drives
- Uncheck 'Hide extensions of known file types'
- Uncheck 'Hide protected operating system files'

Well, it's not there now, though I have completed all the steps, including >>> reagentc /enable, so from what you say winre.wim should have been moved to the
newly re-created Recovery partition.

Now would be a good time to verify it as present and determine the
current Service Pack Build number and last modified date

Run reagentc /info and look for the harddisk# and partition#, then
replace the number in the following Powershell command, once done enter
the full now edited(with your harddisk and parition #'s) command line in
a Powershell admin window

DISM /Get-ImageInfo
/ImageFile:\\?\GLOBALROOT\device\harddisk#\partition#\Recovery\WindowsRE\winre.wim
/index:1

Once done, report five items from the output
Version, Service Pack Build, Service Pack Level, Created date, Modified
date.

Details for image : \\?\GLOBALROOT\device\harddisk0\partition6\Recovery \WindowsRE\winre.wim

Index : 1
Name : Microsoft Windows Recovery Environment (x64)
Description : Microsoft Windows Recovery Environment (x64)
Size : 2,851,512,365 bytes
WIM Bootable : No
Architecture : x64
Hal : <undefined>
Version : 10.0.19041
ServicePack Build : 3920
ServicePack Level : 0
Edition : WindowsPE
Installation : WindowsPE
ProductType : WinNT
ProductSuite :
System Root : WINDOWS
Directories : 3789
Files : 18630
Created : 07/12/2019 - 07:11:48
Modified : 15/03/2024 - 19:10:39
Languages :
en-US (Default)
The operation completed successfully.

This is what I got on my Win10 one ('4441 succeeded).

File size seems a bit different.

Whereas the one for Win11 is from the year 2022.

DISM /Get-ImageInfo /ImageFile:D:\win10-winre.wim /index:1

Deployment Image Servicing and Management tool
Version: 10.0.22621.2792 <=== I'm using Win11 to check the version info

Details for image : D:\win10-winre.wim

Index : 1
Name : Microsoft Windows Recovery Environment (x64)
Description : Microsoft Windows Recovery Environment (x64)
Size : 2,419,893,284 bytes
WIM Bootable : No
Architecture : x64
Hal : <undefined>
Version : 10.0.19041 <=== It's a win10 WIM
ServicePack Build : 3920
ServicePack Level : 0
Edition : WindowsPE
Installation : WindowsPE
ProductType : WinNT
ProductSuite :
System Root : WINDOWS
Directories : 3748
Files : 17355
Created : 12/7/2019 - 3:11:48 AM
Modified : 1/14/2024 - 1:55:47 PM
Languages :
en-US (Default)
The operation completed successfully.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ut76q1$3kb52$1@dont-email.me>, Paul wrote...

On 3/17/2024 11:31 AM, Philip Herlihy wrote:

In article <ut55o8$341m1$1@dont-email.me>, Paul wrote...

On 3/16/2024 5:53 PM, Philip Herlihy wrote:

In article <MPG.40600faf8bed89c6989ab7@news.eternal-september.org>, Philip
Herlihy wrote...

...

Diskpart lists the disks in this order:

Microsoft DiskPart version 10.0.19041.3636

Copyright (C) Microsoft Corporation.
On computer: DESKTOP-4C4MNUB

Disk 0 is now the selected disk.

Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 500 MB 1024 KB
Partition 2 Reserved 128 MB 501 MB
Partition 3 Primary 225 GB 629 MB
Partition 6 Recovery 1101 MB 225 GB
Partition 4 Recovery 10 GB 226 GB
Partition 5 Recovery 1078 MB 237 GB

(Output obtained from diskpart /s temp.txt | clip)

Disk Management (graphic) shows them in the same order.

<sigh> :-) Classic partition renumbering goodness.

So does that mean the sequence is

reagentc /info
reagentc /disable

(remove partition 5, screw up partition order, 6 becomes some other partition number)

reagentc /setreimage <insert_renumbered_path_specification_here>
reagentc /enable
reagentc /info

or something.

I take it the 10GB partition is for some kind of OEM hardware-level recovery ?

Be careful.

Paul

I think I'll leave well alone at this point!


--

Phil, London

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)