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

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.

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

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

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!

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

In article <gd7th6h4dm2w.dlg@v.nguard.lh>, VanguardLH wrote...
>
> 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!
>
....

> 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
>
>
Thanks for this - most helpful.

Yes - I'd found that, and used it on one of my own machines.

> Yeah, like common users are expected to do all that techy shit. Does
> that look easy to you?
....

>
> For now, decide if you really need the update.
....

I think it is needed - it's an update to the security system "Windows
Security" so it's probably more sensitive than most.
>
>
....
>
> 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?

No, that's not an option. The account is a machine administrator, though I've
finally twigged it's a Local account - even though the user has a Microsoft
account using the same identifier. So the option of looking up the key in the
online account isn't there.

--

Phil, London

In article <l4h5tfF7qn5U2@mid.individual.net>, Andy Burns wrote...
>
> 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)

Home, and it's very unlikely this lady would know what Bitlocker is, let alone
have installed it herself. I have to say I hadn't realised this was configured
by default on machines of this generation (pre-TPM).

--

Phil, London

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

--

Phil, London

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

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.

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

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

Paul wrote on 3/13/24 9:45 PM:
> On 3/13/2024 7:12 PM, Philip Herlihy wrote:
>>>> holes. For now, I'm left with anallocated space where the WinRE partion was
>> 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.
>
> You should be doing these things in "priority order" :-)
> 1) Suspend bitlocker.
> 2) Try the WinRE creation script.

Agreed and necessary!

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

Diskpart when using the script or manual steps to resize-shrink C/delete
WinRE partition/recreate WinRE/format/label/set ID/ ***relies*** on the
selection of the o/s disk to ensure that WinRE partition is created in
the right-adjacent-to-C: unallocated space(generated by the shrink C and
delete WinRE commands)
- no magic, the partition # is the o/s partition #+1
>

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

Good idea
- especially if the WinRE partition was deleted/wiped before running
reagentc /info and reagentc /disable
=> The former information only to ensure the location(disk and partition
numbers of the o/s and WinRE partition) are known in advance to ensure
the correct disk is selected.
=> The latter, especially important since the 'disable' ensures Winre.wim
is moved to C:\Windows\Recovery.
Why: If not disabled and Winre.wim moved, then Winre.wim must be
obtained from some other place(ISO, backup)
- reagentc /enable needs to move winre.wim to the created partition

Which in the op's case...bitlocker issues aside, it's important to know
when and also the sequence and/or method the original undersized WinRE
partition was *deleted'

>
> Remember that you have two objectives:
>
> 1) Achieve WinRE enabled again (a kind of proof that
> maybe it might work when called upon).

See above :)

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

....w¡ñ§±¤ñ wrote on 3/14/24 10:00 AM:
> => The latter, especially important since the 'disable' ensures Winre.wim
> is moved to **C:\Windows\Recovery**
>  Why: If not disabled and **Winre.wim moved**, then Winre.wim must be
> obtained from some other place(ISO, backup)
>   - reagentc /enable needs to move winre.wim to the created partition

Corrections:
**C:\Windows\System32\Recovery
**Winre.wim 'not moved'

Note: The location of Winre.wim can be different
In a clean install, it is located in the install.wim(or install.esd) on
the installation media source. In Windows, it's on the WinRE Recovery
partition.

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

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

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

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

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'

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?

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

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

In article <MPG.405e9e5633ff3813989ab5@news.eternal-september.org>, Philip
Herlihy wrote...
>
> 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
> > >
....

There's another glitch with this machine. The user (not content with
transporting the machine with the power plug inserted and banging hell out of
the power socket - repaird) has evidently left it plugged in 24/7 (when not
bouncing it off door-frames). So the battery has about 90s life in it from an
indicated 100% charge.

I've realised that unless it's left "on charge" for many minutes then when it's
logged-in the "Critical Power" event kicks in (at 2%) and hibernates the thing.
I turned that off, but then decided it was safer to leave that mechanism in
place to avoid possible corruption. But I'd like to increase the 'Critical'
level from 2% to (maybe?) 7%. I find the Control Panel applet simply ignores
attempted changes, and I have to use powercfg with some GUID weirdness to
achieve this. As I said, I'm getting too old for this s***...

--

Phil, London

On 3/16/2024 6:24 AM, Philip Herlihy wrote:
> In article <MPG.405e9e5633ff3813989ab5@news.eternal-september.org>, Philip
> Herlihy wrote...
>>
>> 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
>>>>
> ...
>
> There's another glitch with this machine. The user (not content with
> transporting the machine with the power plug inserted and banging hell out of
> the power socket - repaird) has evidently left it plugged in 24/7 (when not
> bouncing it off door-frames). So the battery has about 90s life in it from an
> indicated 100% charge.
>
> I've realised that unless it's left "on charge" for many minutes then when it's
> logged-in the "Critical Power" event kicks in (at 2%) and hibernates the thing.
> I turned that off, but then decided it was safer to leave that mechanism in
> place to avoid possible corruption. But I'd like to increase the 'Critical'
> level from 2% to (maybe?) 7%. I find the Control Panel applet simply ignores
> attempted changes, and I have to use powercfg with some GUID weirdness to
> achieve this. As I said, I'm getting too old for this s***...
>

There is mention here, that the schema can be reset, and maybe
after that you could try again to set it.

https://superuser.com/questions/1341383/how-to-stop-computer-from-entering-sleep-under-critical-battery-trigger-met-mi

There is also a picture of the settings section, in the article.
Since the field can be set to weird values, it almost implies
somehow that this is adaptive ? And adjusts itself ? Otherwise,
how would one individual report his was set to 86%.

https://i.stack.imgur.com/I93RH.png

There is a chip inside the battery pack, which at a minimum
contains a tiny flash memory. And the charge history of the
pack is recorded in there. The OS reads the chip when the
OS boots, and it keeps the table in RAM, and writes it back
out at some point. And since the chip has a "serial number",
this allows the battery pack itself, to carry a summary
of its life history. One of the parameters, is how many
charge cycles it has gone through.

Some laptops, have a charge controller (chip on laptop mobo)
that can be set to "only charge to 80%" and this significantly
reduces the impact on the battery from the "user plugs in
24/7" case. That hasn't always been there, so not all laptops
have that. The setting may be in a separate application,
added to the C: drive.

What it's doing, is removing Phase 2 from the
battery charge process. The charger only does CC to get
to 80%, instead of the CC-CV to get to 100%. The CV or
Constant Voltage phase is known as "topping up" and squeezes
the last bit of charge into the battery, from 80% to 100%.
The time spent at 100% charge (or 4.2V per cell), is what
damages the pack. Once at 100% and the charger has switched
off, the battery starts to relax at that point, and drops
back to 3.7V on its own. Car batteries behave a bit like
that too. In terms of relaxing. One difference is, you
can "float" a car battery at 13.5V instead of allowing it
to relax to 12.6V or so, whereas you cannot float a Lithium
cell. When a lithium cell is full, it's full.

The lithium cell would have to drop significantly, before
another charge cycle starts. The charger cannot start at
3.7V, because the pack is still full at that point. It
would need a bit of hysteresis and maybe start charging
again at 3.5V or so. Even if sleeping, it should not
be "on-charge" constantly, and it should be taking
a break once in a while. But the number of charge cycles,
if left plugged in, it still probably quite high.

Paul

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

In article <ut44iv$2t8ii$1@dont-email.me>, Paul wrote...
>
> On 3/16/2024 6:24 AM, Philip Herlihy wrote:
> > In article <MPG.405e9e5633ff3813989ab5@news.eternal-september.org>, Philip
> > Herlihy wrote...
> >>
> >> 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
> >>>>
> > ...
> >
> > There's another glitch with this machine. The user (not content with
> > transporting the machine with the power plug inserted and banging hell out of
> > the power socket - repaird) has evidently left it plugged in 24/7 (when not
> > bouncing it off door-frames). So the battery has about 90s life in it from an
> > indicated 100% charge.
> >
> > I've realised that unless it's left "on charge" for many minutes then when it's
> > logged-in the "Critical Power" event kicks in (at 2%) and hibernates the thing.
> > I turned that off, but then decided it was safer to leave that mechanism in
> > place to avoid possible corruption. But I'd like to increase the 'Critical'
> > level from 2% to (maybe?) 7%. I find the Control Panel applet simply ignores
> > attempted changes, and I have to use powercfg with some GUID weirdness to
> > achieve this. As I said, I'm getting too old for this s***...
> >
>
> There is mention here, that the schema can be reset, and maybe
> after that you could try again to set it.
>
> https://superuser.com/questions/1341383/how-to-stop-computer-from-entering-sleep-under-critical-battery-trigger-met-mi
>
> There is also a picture of the settings section, in the article.
> Since the field can be set to weird values, it almost implies
> somehow that this is adaptive ? And adjusts itself ? Otherwise,
> how would one individual report his was set to 86%.
>
> https://i.stack.imgur.com/I93RH.png
>
> There is a chip inside the battery pack, which at a minimum
> contains a tiny flash memory. And the charge history of the
> pack is recorded in there. The OS reads the chip when the
> OS boots, and it keeps the table in RAM, and writes it back
> out at some point. And since the chip has a "serial number",
> this allows the battery pack itself, to carry a summary
> of its life history. One of the parameters, is how many
> charge cycles it has gone through.
>
> Some laptops, have a charge controller (chip on laptop mobo)
> that can be set to "only charge to 80%" and this significantly
> reduces the impact on the battery from the "user plugs in
> 24/7" case. That hasn't always been there, so not all laptops
> have that. The setting may be in a separate application,
> added to the C: drive.
>
> What it's doing, is removing Phase 2 from the
> battery charge process. The charger only does CC to get
> to 80%, instead of the CC-CV to get to 100%. The CV or
> Constant Voltage phase is known as "topping up" and squeezes
> the last bit of charge into the battery, from 80% to 100%.
> The time spent at 100% charge (or 4.2V per cell), is what
> damages the pack. Once at 100% and the charger has switched
> off, the battery starts to relax at that point, and drops
> back to 3.7V on its own. Car batteries behave a bit like
> that too. In terms of relaxing. One difference is, you
> can "float" a car battery at 13.5V instead of allowing it
> to relax to 12.6V or so, whereas you cannot float a Lithium
> cell. When a lithium cell is full, it's full.
>
> The lithium cell would have to drop significantly, before
> another charge cycle starts. The charger cannot start at
> 3.7V, because the pack is still full at that point. It
> would need a bit of hysteresis and maybe start charging
> again at 3.5V or so. Even if sleeping, it should not
> be "on-charge" constantly, and it should be taking
> a break once in a while. But the number of charge cycles,
> if left plugged in, it still probably quite high.
>
> Paul

Thanks, Paul. The battery is utterly knackered, clearly. I've tried to
increase the Critical Battery Level as described in the article, but the
changes simply don't 'stick', reverting to 2%. There is an option to do this
using Powercfg.exe and some GUIDS (bizzarely) which I haven't tried at this
point. I think I'll leave it - if I increase the CBL then the hibernation
trigger may kick in more readily even when connected to power, and (based on
experimentation) turning on the power, booting but then waiting 5m before
logging in seems to avoid it. I just hope 2% of 90s run-time is enough to
hibernate and avoid corruption if the power is disturbed.

--

Phil, London

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

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

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.

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

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

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