Paul wrote on 1/11/24 5:24 AM:
> On 1/11/2024 4:01 AM, John Hall wrote:
>> In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall <john_nospam@jhall.co.uk> writes
>> <snip>
>>> I think I'll just wait for Microsoft to fix things rather than try anything fancy.
>>
>> I'm glad I waited, as Microsoft now seem to have fixed it. Settings > Windows Update now tells me that I'm up to date. I wonder whether Christmas and New Year meant that this update received less testing than usual before it was released.
>
> That's also going to impact some backup programs.
>
> If you were perhaps running Incremental Forever,
> and the partition size changes.
>
> Paul
>
No different than June 2023 when security changes and WinRE was first
included in Cumulative Updates that indicated the need to:
=> Update Windows installation media to currently available(or optionally
obtain the latest ISO for mounting)using the MCT.
=> Reimage the device after updating ensure the System partition, Boot
partitions(Windows) and the WinRe partitions are included(i.e. not just
the Windows partition).
=> Recreate the USB Recovery drive after updating the device

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

ant@zimage.comANT (Ant) wrote:

>Others'
>(https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_january_9th_2024/kh32u6f/)
>and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download error - 0x80070643" with
>"2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in
>64-bit W10 Pro. right now. I already rebooted once from other today's updates:

[snip]

>Couldn't MS do this to its users automatically without having to do it manually for
>non-technical users? :/

Good news, folks. MS has released a PowerShell script to
automate the process.

Details, courtesy BleepingComputer:
https://www.bleepingcomputer.com/news/microsoft/microsoft-shares-script-to-update-windows-10-winre-with-bitlocker-fixes/
(mind the wrap)

The script: Article KB5034957
https://support.microsoft.com/en-us/topic/kb5034957-updating-the-winre-partition-on-deployed-devices-to-address-security-vulnerabilities-in-cve-2024-20666-0190331b-1ca3-42d8-8a55-7fc406910c10
(mind he wrap)

--
George Ruch
"Is there life in Clovis after Clovis Man?"

George <george.ruch74@gmail.com> wrote:
> ant@zimage.comANT (Ant) wrote:

> >Others'
> >(https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_january_9th_2024/kh32u6f/)
> >and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download error - 0x80070643" with
> >"2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in
> >64-bit W10 Pro. right now. I already rebooted once from other today's updates:

> [snip]

> >Couldn't MS do this to its users automatically without having to do it manually for
> >non-technical users? :/

> Good news, folks. MS has released a PowerShell script to
> automate the process.

> Details, courtesy BleepingComputer:
> https://www.bleepingcomputer.com/news/microsoft/microsoft-shares-script-to-update-windows-10-winre-with-bitlocker-fixes/
> (mind the wrap)

> The script: Article KB5034957
> https://support.microsoft.com/en-us/topic/kb5034957-updating-the-winre-partition-on-deployed-devices-to-address-security-vulnerabilities-in-cve-2024-20666-0190331b-1ca3-42d8-8a55-7fc406910c10
> (mind he wrap)

Has anyone tried it yet? Is it safe or buggy? :)
--
"My son, if sinners entice you, do not give in to them." --Proverbs 1:10. "My son, if sinners entice you, do not give in to them." --Proverbs 1:10. Dang cold winds and age.
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
/\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
/ /\ /\ \ Please nuke ANT if replying by e-mail.
| |o o| |
\ _ /
( )

Ant wrote on 1/11/24 7:51 PM:
> George <george.ruch74@gmail.com> wrote:
>> ant@zimage.comANT (Ant) wrote:
>
>>> Others'
>>> (https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_january_9th_2024/kh32u6f/)
>>> and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download error - 0x80070643" with
>>> "2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in
>>> 64-bit W10 Pro. right now. I already rebooted once from other today's updates:
>
>> [snip]
>
>>> Couldn't MS do this to its users automatically without having to do it manually for
>>> non-technical users? :/
>
>> Good news, folks. MS has released a PowerShell script to
>> automate the process.
>
>> Details, courtesy BleepingComputer:
>> https://www.bleepingcomputer.com/news/microsoft/microsoft-shares-script-to-update-windows-10-winre-with-bitlocker-fixes/
>> (mind the wrap)
>
>> The script: Article KB5034957
>> https://support.microsoft.com/en-us/topic/kb5034957-updating-the-winre-partition-on-deployed-devices-to-address-security-vulnerabilities-in-cve-2024-20666-0190331b-1ca3-42d8-8a55-7fc406910c10
>> (mind he wrap)
>
> Has anyone tried it yet? Is it safe or buggy? :)
>
Successful results from the Enterprise community(some of the Admins
responsible for 100,000+ devices still using Win10)

Same identical link for the Powershell script(s)I posted yesterday Jan
10, 2024.

Also note, in both the consumer and Enterprise community reports(earlier
today) have indicated that rerunning Windows Update to install the same
update are now yielding successful results.
i.e. MSFT has updated the code for the Jan. 2024 cumulative update.
- in this case the general understanding is they reverted to or
modified existing code, that updated the Windoes RE envirorment(and its
partition on disk) that was in use from June 2023 through Dec 2023(WinRE
has been included in Cumulative Updates since June 2023 without issues
encountered by the Jan. 2024 update)

In both of the above successful cases, do realize that there are
hundreds, thousands or more of different devices and not all operating
under the same conditions as one's own device.

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

On 1/11/2024 10:52 AM, sticks wrote:
> On 1/11/2024 3:01 AM, John Hall wrote:
>> In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall <john_nospam@jhall.co.uk> writes
>> <snip>
>>> I think I'll just wait for Microsoft to fix things rather than try anything fancy.
>>
>> I'm glad I waited, as Microsoft now seem to have fixed it. Settings > Windows Update now tells me that I'm up to date. I wonder whether Christmas and New Year meant that this update received less testing than usual before it was released.
>
> Still getting the same error here today.  Not fixed for me.
>

Is there something unique about your disk layout ?

You would think the revision of the release, would cause
a fresh download of it. So that it would not be using
just the old method and running into trouble.

Paul

John Hall <john_nospam@jhall.co.uk> wrote:
> In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall
> <john_nospam@jhall.co.uk> writes
> <snip>
> >I think I'll just wait for Microsoft to fix things rather than try
> >anything fancy.
>
> I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
> Windows Update now tells me that I'm up to date. I wonder whether
> Christmas and New Year meant that this update received less testing than
> usual before it was released.

Please check that it indeed has been fixed.

For example on my wife's Windows 10 system, Windows Update indeed says
"You're up to date", but in 'Update history' ('Quality Updates' section)
it says that KB5034441 failed to install and gives the 0x80070643 error
code.

So: "You're up to date", but install failure and the update is not
re-offered (nor has any other update been offered/installed).

And to answer Paul's question, yes this system has a 'special'
partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
partition which probably still contains the HP-proprietary recovery for
Windows 8):

From 'Disk Management':

[Partition type descriptions translated from Dutch:]

Partition 1: Recovery partition (400 MB)
Partition 2: EFI system partition (260 MB)
Partition : Windows (C:) partition (449.96 GB)
Partition 5: Recovery partition (605 MB)
Partition : RECOVERY (D:) partition ( 14.94 GB)

N.B. Partitions are listed in physical order (bottom pane). Disk
Management does not list the partition numbers for C: and D: and I don't
see how Disk Management can show the partition numbers of these
partitions.

In the top pane, the order in the 'Volume' column is different than
the physical order: Partition 1, partition 2, partition 5,
RECOVERY (D:), Windows (C:).

But most importantly, the question to Winston, Paul et al:

How can we *check* that the recovery partition was indeed correctly
'fixed'/updated?

Some posters (like John Hall) report no errors, but does that mean
their system is OK/'fixed'/updated?

Others (like 'sticks' and me) report errors, but does that mean their
system is *not* OK/'fixed'/updated?

On 1/12/2024 5:31 AM, Frank Slootweg wrote:
> John Hall <john_nospam@jhall.co.uk> wrote:
>> In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall
>> <john_nospam@jhall.co.uk> writes
>> <snip>
>>> I think I'll just wait for Microsoft to fix things rather than try
>>> anything fancy.
>>
>> I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
>> Windows Update now tells me that I'm up to date. I wonder whether
>> Christmas and New Year meant that this update received less testing than
>> usual before it was released.
>
> Please check that it indeed has been fixed.
>
> For example on my wife's Windows 10 system, Windows Update indeed says
> "You're up to date", but in 'Update history' ('Quality Updates' section)
> it says that KB5034441 failed to install and gives the 0x80070643 error
> code.
>
> So: "You're up to date", but install failure and the update is not
> re-offered (nor has any other update been offered/installed).

Checking today, mine showed 2 updates, downloaded and installed Defender
stuff, and now opens with "Error encountered". It didn't appear to
download a new file, or even try and reinstall. It went to the error fast.

> And to answer Paul's question, yes this system has a 'special'
> partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
> partition which probably still contains the HP-proprietary recovery for
> Windows 8):
>
> From 'Disk Management':
>
> [Partition type descriptions translated from Dutch:]
>
> Partition 1: Recovery partition (400 MB)
> Partition 2: EFI system partition (260 MB)
> Partition : Windows (C:) partition (449.96 GB)
> Partition 5: Recovery partition (605 MB)
> Partition : RECOVERY (D:) partition ( 14.94 GB)
>
> N.B. Partitions are listed in physical order (bottom pane). Disk
> Management does not list the partition numbers for C: and D: and I don't
> see how Disk Management can show the partition numbers of these
> partitions.
>
> In the top pane, the order in the 'Volume' column is different than
> the physical order: Partition 1, partition 2, partition 5,
> RECOVERY (D:), Windows (C:).

I have smaller:
System Reserved 100 MB 100% free
Main C 465.15 GB 76% free
Recovery 526 MB with 64% free

I'm guessing this recovery partition is too small and that's the
problem, so I have to run this script they have put out yesterday?

>
> But most importantly, the question to Winston, Paul et al:
>
> How can we *check* that the recovery partition was indeed correctly
> 'fixed'/updated?
>
> Some posters (like John Hall) report no errors, but does that mean
> their system is OK/'fixed'/updated?
>
> Others (like 'sticks' and me) report errors, but does that mean their
> system is *not* OK/'fixed'/updated?

Mine's certainly not updated. My question is do I have to do something
to get this update, or is it supposed to be fixed automatically? Kind
of seems like a crazy way to do things if that is true. I'm sure I
could get it done, but almost nobody else I know would be able to.

--
Stand With Israel!
NOTE: If you use Google Groups I don't see you,
unless you're whitelisted and that's doubtful.

In message <unrbe1.5jo.1@ID-201911.user.individual.net>, Frank Slootweg
<this@ddress.is.invalid> writes
>John Hall <john_nospam@jhall.co.uk> wrote:
>> In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall
>> <john_nospam@jhall.co.uk> writes
>> <snip>
>> >I think I'll just wait for Microsoft to fix things rather than try
>> >anything fancy.
>>
>> I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
>> Windows Update now tells me that I'm up to date. I wonder whether
>> Christmas and New Year meant that this update received less testing than
>> usual before it was released.
>
> Please check that it indeed has been fixed.
>
> For example on my wife's Windows 10 system, Windows Update indeed says
>"You're up to date", but in 'Update history' ('Quality Updates' section)
>it says that KB5034441 failed to install and gives the 0x80070643 error
>code.
>
> So: "You're up to date", but install failure and the update is not
>re-offered (nor has any other update been offered/installed).
<snip>

Yes, you're right. Presumably now that they know the update was faulty
they've stopped it from trying repeatedly to install itself, and are
still working on a fixed version which will be offered when it's ready.
--
John Hall
"Acting is merely the art of keeping a large group of people
from coughing."
Sir Ralph Richardson (1902-83)

....w¡ñ§±¤ñ <winstonmvp@gmail.com> wrote:
> Ant wrote on 1/11/24 7:51 PM:
> > George <george.ruch74@gmail.com> wrote:
> >> ant@zimage.comANT (Ant) wrote:
> >
> >>> Others'
> >>> (https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_january_9th_2024/kh32u6f/)
> >>> and my updated 64-bit W10 Pro. PC, I'm getting "Status: Download error - 0x80070643" with
> >>> "2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in
> >>> 64-bit W10 Pro. right now. I already rebooted once from other today's updates:
> >
> >> [snip]
> >
> >>> Couldn't MS do this to its users automatically without having to do it manually for
> >>> non-technical users? :/
> >
> >> Good news, folks. MS has released a PowerShell script to
> >> automate the process.
> >
> >> Details, courtesy BleepingComputer:
> >> https://www.bleepingcomputer.com/news/microsoft/microsoft-shares-script-to-update-windows-10-winre-with-bitlocker-fixes/
> >> (mind the wrap)
> >
> >> The script: Article KB5034957
> >> https://support.microsoft.com/en-us/topic/kb5034957-updating-the-winre-partition-on-deployed-devices-to-address-security-vulnerabilities-in-cve-2024-20666-0190331b-1ca3-42d8-8a55-7fc406910c10
> >> (mind he wrap)
> >
> > Has anyone tried it yet? Is it safe or buggy? :)
> >
> Successful results from the Enterprise community(some of the Admins
> responsible for 100,000+ devices still using Win10)

> Same identical link for the Powershell script(s)I posted yesterday Jan
> 10, 2024.

> Also note, in both the consumer and Enterprise community reports(earlier
> today) have indicated that rerunning Windows Update to install the same
> update are now yielding successful results.
> i.e. MSFT has updated the code for the Jan. 2024 cumulative update.
> - in this case the general understanding is they reverted to or
> modified existing code, that updated the Windoes RE envirorment(and its
> partition on disk) that was in use from June 2023 through Dec 2023(WinRE
> has been included in Cumulative Updates since June 2023 without issues
> encountered by the Jan. 2024 update)

> In both of the above successful cases, do realize that there are
> hundreds, thousands or more of different devices and not all operating
> under the same conditions as one's own device.

I reran WU, but it still failed for this update. :( Does this fixed WU include this script?
--
"Blessed is the man who perseveres under trial, because when he has stood the test, he will receive the crown of life that God has promised to those who love him." --James 1:12. Only lucky 8 remember it! TGIF?
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
/\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
/ /\ /\ \ Please nuke ANT if replying by e-mail.
| |o o| |
\ _ /
( )

Frank Slootweg wrote on 1/12/24 4:31 AM:
> And to answer Paul's question, yes this system has a 'special'
> partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
> partition which probably still contains the HP-proprietary recovery for
> Windows 8): The HP special Recovery is useless unless one desires to reset the
device back to Windows 8.....but that process has been known to fail
since some OEM return to factory mehtods rely on the o/s image current
active Windows Recovery. Some OEM's have accounted for this by wiping
the disk and including a diskpart script(text file form) that:
Runs the Clean and Convert GPT commands, followed by repartition the
entire disk 4 GPT partitions. Installing Windows using the image in the
OEM recovery partition(or requird USB or CD provided or available from
the OEM) and as-shipped Software and Apps. Activation occurs later and
automatically using the firmware based OEM Product Key)
- thus depending on the OEM approach, the special OEM Recovery
partition can be useful or useless.

>
> From 'Disk Management':
>
> [Partition type descriptions translated from Dutch:]
>
> Partition 1: Recovery partition (400 MB)
> Partition 2: EFI system partition (260 MB)
> Partition : Windows (C:) partition (449.96 GB)
> Partition 5: Recovery partition (605 MB)
> Partition : RECOVERY (D:) partition ( 14.94 GB)
>
> N.B. Partitions are listed in physical order (bottom pane). Disk
> Management does not list the partition numbers for C: and D: and I don't
> see how Disk Management can show the partition numbers of these
> partitions.
It does not, it has a drive label.
On your device
MSR(not shown) iw partition 3
C: is partition 4
D: is partition 6

>
> In the top pane, the order in the 'Volume' column is different than
> the physical order: Partition 1, partition 2, partition 5,
> RECOVERY (D:), Windows (C:).

You've variety of built-in tools to view partitions in an admin mode.
PowerShell's command Get-Volume
- shows about the same as Disk Management
Diskpart provides a little more depth
List Vol (all partitions/volumes with and without assigned drive labels)
Sel Disk (command to select the desired disk)
List Part (command to list and show the partitions and partition number
on the selected disk)
>
> But most importantly, the question to Winston, Paul et al:
>
> How can we *check* that the recovery partition was indeed correctly
> 'fixed'/updated?
This is where it gets tricky.
When WinRE(the Recovery partition is created and enabled, the winre.wim
file is moved, not copied from the o/s folder to the active WinRe
recovery partition(i.e. the winre.wim file that gets updated via Windows
Update and it's current date is not on the o/s drive).
To view winre.wim file date and size, one of the easier routes is to
use EaseUS Partition Master(aka EPM)
Open EPM, select the Windows RE partition, then use its 'Explore'
option which will show the folder/subfolder structure - drill down to the
Recovery\WindowsRE folder to see the size, date created, date modified.
If updated, the date should be the same or after the date the Jan. update
was installed
- why a later date ? - depending on what one has done on the device via
Windows Update, and when, the winre.wim file could have been updated
since installing the Jan. update.

>
> Some posters (like John Hall) report no errors, but does that mean
> their system is OK/'fixed'/updated?
Not enough info to accurately answer the question.
>
> Others (like 'sticks' and me) report errors, but does that mean their
> system is *not* OK/'fixed'/updated?
All I can answer without more info on winre.wim is possibly...since
winre.wim could be updated but other issues with the update's other
patching could be still present.

Also note, the change in size of the winre.wim file is only a few MB.
It's been reported in a variety of locations and depending upon the
user's device and their diagnosis to be less than 30 MB.
On my Win10 Pro and Win11 Pro device the change in size to winre.wim was
23 and 11 MB respectively.
- A user on askwoody reported the change in size of winre.wim on two
different devices(one GPT, the other MBR) as 29 MB and 27 MB respectively.
=> which appears to indicate it's not the size change in the winre.wim
file but the free space needed to accomplish the entire Windows Recovery
partition process and why MSFT suggested increasing the partition size by
250 MB which probably provides more free space than needed to accomplish
the entire process to update the Windows Recovery partiton.

As I've said before, including elsewhere...this whole scenario is like a
tornado(January 2024's updating the Windows Recovery partition) with a
pre-determined path to the trailer/mobile home park(Windows 10/11 devices)

One other comment...here's some more data to put the growth of the WinRE
partition size in perspective from one of my devices
Device was purchased in Oct 2017 with Win10 Pro and clean installed with
Win10 Pro shortly after first use, upgraded to Win11 Pro in March 2023.
The Windows Recovery Partition sizes were/are:
Win10 Pro Oct 2017 - 323 MB
Win 10 Pro March 2023 – 602 MB
Win 11 Pro March 2023 – 675 MB (a few days after upgrading from Win10
Pro to Win11 Pro)
Win11 Pro June 2023 – 729 MB (the month that MSFT started including
WinRE in cumulative updates)
Win 11 Pro Nov 2023 – 818 MB
Win 11 Pro Jan 2024 – 829 MB (after installing Jan. 2024 updates; an
increase of 11 MB since Nov. 2023)

>

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

On 11 Jan 2024, George <george.ruch74@gmail.com> wrote in
alt.comp.os.windows-10:

> Good news, folks. MS has released a PowerShell script to
> automate the process.
>
> Details, courtesy BleepingComputer:
> https://www.bleepingcomputer.com/news/microsoft/microsoft-shares-sc
> ript-to-update-windows-10-winre-with-bitlocker-fixes/ (mind the
> wrap)
>
> The script: Article KB5034957
> https://support.microsoft.com/en-us/topic/kb5034957-updating-the-wi
> nre-partition-on-deployed-devices-to-address-security-vulnerabiliti
> es-in-cve-2024-20666-0190331b-1ca3-42d8-8a55-7fc406910c10 (mind he
> wrap)

This confuses me. If I'm reading things right, the update failed
because the recovery partition is too small. The article says, "the
company now also provides a dedicated PowerShell script to help you
automate updating the WinRE partition (without having to resize it
first) and patching the CVE-2024-20666 BitLocker vulnerability." It's
not clear to me whether the script resizes the partition or not My
recovery partition on this desktop is 542 MB. If that was too small
before, is the script going to fix the basic problem?

Ideally, what size should the Recovery Partition be? I see on two of my
other computers, both of which took the update successfully, have
multiple (redundant?) recovery partitions, totaling about 15 GB.

Nil wrote on 1/12/24 4:07 PM:
>> The script: Article KB5034957
>> https://support.microsoft.com/en-us/topic/kb5034957-updating-the-wi
>> nre-partition-on-deployed-devices-to-address-security-vulnerabiliti
>> es-in-cve-2024-20666-0190331b-1ca3-42d8-8a55-7fc406910c10 (mind he
>> wrap)
>
> This confuses me. If I'm reading things right, the update failed
> because the recovery partition is too small. The article says, "the
> company now also provides a dedicated PowerShell script to help you
> automate updating the WinRE partition (without having to resize it
> first) and patching the CVE-2024-20666 BitLocker vulnerability." It's
> not clear to me whether the script resizes the partition or not My
> recovery partition on this desktop is 542 MB. If that was too small
> before, is the script going to fix the basic problem?
The script in the referenced support article does not resize the partition.
- This script only performs the installation, and only if you have
downloaded the Safe OS update package. It doesn't resize any partitions.
It also requires that the packages are actually available and have
already been downloaded.
The script does check for Bitlocker and disable and reenable WinRE if
it's enabled.

>
> Ideally, what size should the Recovery Partition be? I see on two of my
> other computers, both of which took the update successfully, have
> multiple (redundant?) recovery partitions, totaling about 15 GB.
Multiple recovery partitions?
How many?
Please specify the sizes of each one.

While one could have multiple Recovery partitions for Windows, one could
also have one active Recovery partition, and/or an inactive(useless) or
OEM 'Recovery partition'. The OEM Recovery partition are usually very
large(GB) and is not the active Recovery partition being
addressed/updated with the January 2024 update/patch.
- The OEM Recovery partition was placed on the device, as-shipped, by the
OEM to allow the end-user(purchaser) to reset the device to as-shipped
condition(i.e. it has no bearing on the Jan. 2024 update or updating the
active Windows Recovery partition
>

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

On 1/12/2024 6:31 AM, Frank Slootweg wrote:
> John Hall <john_nospam@jhall.co.uk> wrote:
>> In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall
>> <john_nospam@jhall.co.uk> writes
>> <snip>
>>> I think I'll just wait for Microsoft to fix things rather than try
>>> anything fancy.
>>
>> I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
>> Windows Update now tells me that I'm up to date. I wonder whether
>> Christmas and New Year meant that this update received less testing than
>> usual before it was released.
>
> Please check that it indeed has been fixed.
>
> For example on my wife's Windows 10 system, Windows Update indeed says
> "You're up to date", but in 'Update history' ('Quality Updates' section)
> it says that KB5034441 failed to install and gives the 0x80070643 error
> code.
>
> So: "You're up to date", but install failure and the update is not
> re-offered (nor has any other update been offered/installed).
>
> And to answer Paul's question, yes this system has a 'special'
> partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
> partition which probably still contains the HP-proprietary recovery for
> Windows 8):
>
> From 'Disk Management':
>
> [Partition type descriptions translated from Dutch:]
>
> Partition 1: Recovery partition (400 MB)
> Partition 2: EFI system partition (260 MB)
> Partition : Windows (C:) partition (449.96 GB)
> Partition 5: Recovery partition (605 MB)
> Partition : RECOVERY (D:) partition ( 14.94 GB)
>
> N.B. Partitions are listed in physical order (bottom pane). Disk
> Management does not list the partition numbers for C: and D: and I don't
> see how Disk Management can show the partition numbers of these
> partitions.
>
> In the top pane, the order in the 'Volume' column is different than
> the physical order: Partition 1, partition 2, partition 5,
> RECOVERY (D:), Windows (C:).
>
> But most importantly, the question to Winston, Paul et al:
>
> How can we *check* that the recovery partition was indeed correctly
> 'fixed'/updated?
>
> Some posters (like John Hall) report no errors, but does that mean
> their system is OK/'fixed'/updated?
>
> Others (like 'sticks' and me) report errors, but does that mean their
> system is *not* OK/'fixed'/updated?
>

This has certainly turned into a hobby :-)

[Picture]

https://i.postimg.cc/HnkmKP8X/4441-installed-OK-dates-filesize.gif

Paul

On 12 Jan 2024, =?UTF-8?B?Li4ud8Khw7HCp8KxwqTDsSA=?=
<winstonmvp@gmail.com> wrote in alt.comp.os.windows-10:

> Nil wrote on 1/12/24 4:07 PM:
>>> The script: Article KB5034957
>>> https://support.microsoft.com/en-us/topic/kb5034957-updating-the-winre-partition-on-deployed-devices-to-address-security-vulnerabilities-in-cve-2024-20666-0190331b-1ca3-42d8-8a55-7fc406910c10
>>> (mind he wrap)
>>
>> This confuses me. If I'm reading things right, the update failed
>> because the recovery partition is too small. The article says,
>> "the company now also provides a dedicated PowerShell script to
>> help you automate updating the WinRE partition (without having to
>> resize it first) and patching the CVE-2024-20666 BitLocker
>> vulnerability." It's not clear to me whether the script resizes
>> the partition or not My recovery partition on this desktop is 542
>> MB. If that was too small before, is the script going to fix the
>> basic problem?
>
> The script in the referenced support article does not resize the
> partition. - This script only performs the installation, and only
> if you have downloaded the Safe OS update package. It doesn't
> resize any partitions. It also requires that the packages are
> actually available and have already been downloaded.
> The script does check for Bitlocker and disable and reenable WinRE
> if it's enabled.

OK, that partly answers my question, but it skips the most important part:
is my current Recovery large enough? Is the script smart enough to check
if there's enough room and abort if not?

I'll get back to you about the multiple partitions issue. It's not very
important, but it would be nice to regain some of that disk space.

>> Ideally, what size should the Recovery Partition be? I see on two
>> of my other computers, both of which took the update
>> successfully, have multiple (redundant?) recovery partitions,
>> totaling about 15 GB.
> Multiple recovery partitions?
> How many?
> Please specify the sizes of each one.
>
> While one could have multiple Recovery partitions for Windows, one
> could also have one active Recovery partition, and/or an
> inactive(useless) or OEM 'Recovery partition'. The OEM Recovery
> partition are usually very large(GB) and is not the active
> Recovery partition being addressed/updated with the January 2024
> update/patch. - The OEM Recovery partition was placed on the
> device, as-shipped, by the OEM to allow the end-user(purchaser) to
> reset the device to as-shipped condition(i.e. it has no bearing on
> the Jan. 2024 update or updating the active Windows Recovery
> partition

Nil wrote on 1/12/24 7:19 PM:
>
> OK, that partly answers my question, but it skips the most important part:
> is my current Recovery large enough? Is the script smart enough to check
> if there's enough room and abort if not?
You earlier noted your Windows Recovery Partition was 542 MB

It's not the full size of the Recovery Partition, its the amount of free
space needed by the update's entire process in and on the Recovery
partition to update the necessary files in the Recovery Partition.

The increase in size of the the primary file being replaced is very
small(less than 30 MB) but the process to do so requires much more.

Even if the amount of free, unused space is known it is unlikely your
question can be answered.
1. there's no single answer, since not everyone has the exact same
condition as you
2. MSFT previously suggested increasing the size of the partition by
250 MB, but they've never indicated how much of that 250 MB would be
needed in addition to the free space already present and note, that 250
MB increase was intended for insufficient free space on millions(or more)
devices(et al make it enough larger to cover everyone having the problem)
- i.e. making it this much larger 'should' resolve any issues related
to needed space, not how much was actually needed.

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

On 1/12/24 09:14 PM, Paul wrote:
> On 1/12/2024 6:31 AM, Frank Slootweg wrote:
>> John Hall <john_nospam@jhall.co.uk> wrote:
>>> In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall
>>> <john_nospam@jhall.co.uk> writes
>>> <snip>
>>>> I think I'll just wait for Microsoft to fix things rather than try
>>>> anything fancy.
>>>
>>> I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
>>> Windows Update now tells me that I'm up to date. I wonder whether
>>> Christmas and New Year meant that this update received less testing than
>>> usual before it was released.
>>
>> Please check that it indeed has been fixed.
>>
>> For example on my wife's Windows 10 system, Windows Update indeed says
>> "You're up to date", but in 'Update history' ('Quality Updates' section)
>> it says that KB5034441 failed to install and gives the 0x80070643 error
>> code.
>>
>> So: "You're up to date", but install failure and the update is not
>> re-offered (nor has any other update been offered/installed).
>>
>> And to answer Paul's question, yes this system has a 'special'
>> partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
>> partition which probably still contains the HP-proprietary recovery for
>> Windows 8):
>>
>> From 'Disk Management':
>>
>> [Partition type descriptions translated from Dutch:]
>>
>> Partition 1: Recovery partition (400 MB)
>> Partition 2: EFI system partition (260 MB)
>> Partition : Windows (C:) partition (449.96 GB)
>> Partition 5: Recovery partition (605 MB)
>> Partition : RECOVERY (D:) partition ( 14.94 GB)
>>
>> N.B. Partitions are listed in physical order (bottom pane). Disk
>> Management does not list the partition numbers for C: and D: and I don't
>> see how Disk Management can show the partition numbers of these
>> partitions.
>>
>> In the top pane, the order in the 'Volume' column is different than
>> the physical order: Partition 1, partition 2, partition 5,
>> RECOVERY (D:), Windows (C:).
>>
>> But most importantly, the question to Winston, Paul et al:
>>
>> How can we *check* that the recovery partition was indeed correctly
>> 'fixed'/updated?
>>
>> Some posters (like John Hall) report no errors, but does that mean
>> their system is OK/'fixed'/updated?
>>
>> Others (like 'sticks' and me) report errors, but does that mean their
>> system is *not* OK/'fixed'/updated?
>>
>
> This has certainly turned into a hobby :-)
>
> [Picture]
>
> https://i.postimg.cc/HnkmKP8X/4441-installed-OK-dates-filesize.gif
>
> Paul
I just tried my system last night and I have 566M in Recovery.
I did the manual way and when I did the shrink on the OS partition it
failed. 96G, said it could not shrink, something about the new size
would be less than the minimum.

And I did verify that the Sel Part was 4 for OS and 5 for Recovery and I
was on the right partition.

Now I wonder if I should run the powershell script? Will it abort and
reset properly if this error pops up there?

You're right Paul. I've spent less time on hobbies.
--
Linux Mint 21.2 Cinnamon
Al

On 1/13/24 07:33 AM, Big Al wrote:
> On 1/12/24 09:14 PM, Paul wrote:
>> On 1/12/2024 6:31 AM, Frank Slootweg wrote:
>>> John Hall <john_nospam@jhall.co.uk> wrote:
>>>> In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall
>>>> <john_nospam@jhall.co.uk> writes
>>>> <snip>
>>>>> I think I'll just wait for Microsoft to fix things rather than try
>>>>> anything fancy.
>>>>
>>>> I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
>>>> Windows Update now tells me that I'm up to date. I wonder whether
>>>> Christmas and New Year meant that this update received less testing
>>>> than
>>>> usual before it was released.
>>>
>>>    Please check that it indeed has been fixed.
>>>
>>>    For example on my wife's Windows 10 system, Windows Update indeed
>>> says
>>> "You're up to date", but in 'Update history' ('Quality Updates' section)
>>> it says that KB5034441 failed to install and gives the 0x80070643 error
>>> code.
>>>
>>>    So: "You're up to date", but install failure and the update is not
>>> re-offered (nor has any other update been offered/installed).
>>>
>>>    And to answer Paul's question, yes this system has a 'special'
>>> partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
>>> partition which probably still contains the HP-proprietary recovery for
>>> Windows 8):
>>>
>>>  From 'Disk Management':
>>>
>>> [Partition type descriptions translated from Dutch:]
>>>
>>> Partition 1: Recovery      partition (400 MB)
>>> Partition 2: EFI system    partition (260 MB)
>>> Partition  : Windows (C:)  partition (449.96 GB)
>>> Partition 5: Recovery      partition (605 MB)
>>> Partition  : RECOVERY (D:) partition ( 14.94 GB)
>>>
>>>    N.B. Partitions are listed in physical order (bottom pane). Disk
>>> Management does not list the partition numbers for C: and D: and I don't
>>> see how Disk Management can show the partition numbers of these
>>> partitions.
>>>
>>>    In the top pane, the order in the 'Volume' column is different than
>>> the physical order: Partition 1, partition 2, partition 5,
>>> RECOVERY (D:), Windows (C:).
>>>
>>>    But most importantly, the question to Winston, Paul et al:
>>>
>>>    How can we *check* that the recovery partition was indeed correctly
>>> 'fixed'/updated?
>>>
>>>    Some posters (like John Hall) report no errors, but does that mean
>>> their system is OK/'fixed'/updated?
>>>
>>>    Others (like 'sticks' and me) report errors, but does that mean their
>>> system is *not* OK/'fixed'/updated?
>>>
>>
>> This has certainly turned into a hobby :-)
>>
>>     [Picture]
>>
>>      https://i.postimg.cc/HnkmKP8X/4441-installed-OK-dates-filesize.gif
>>
>>    Paul
> I just tried my system last night and I have 566M in Recovery.
> I did the manual way and when I did the shrink on the OS partition it
> failed.  96G, said it could not shrink, something about the new size
> would be less than the  minimum.
>
> And I did verify that the Sel Part was 4 for OS and 5 for Recovery and I
> was on the right partition.
>
> Now I wonder if I should run the powershell script?  Will it abort and
> reset properly if this error pops up there?
>
> You're right Paul.  I've spent less time on hobbies.
Just saw Winston's remarks that the powershell script only fixes the
win.re not the partition size.
--
Linux Mint 21.2 Cinnamon
Al

....w¡ñ§±¤ñ <winstonmvp@gmail.com> wrote:
> Frank Slootweg wrote on 1/12/24 4:31 AM:
> > And to answer Paul's question, yes this system has a 'special'
> > partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
> > partition which probably still contains the HP-proprietary recovery for
> > Windows 8):
> >
[...]
> > From 'Disk Management':
> >
> >
> > [Partition type descriptions translated from Dutch:]
> >
> > Partition 1: Recovery partition (400 MB)
> > Partition 2: EFI system partition (260 MB)
> > Partition : Windows (C:) partition (449.96 GB)
> > Partition 5: Recovery partition (605 MB)
> > Partition : RECOVERY (D:) partition ( 14.94 GB)
> >
> > N.B. Partitions are listed in physical order (bottom pane). Disk
> > Management does not list the partition numbers for C: and D: and I don't
> > see how Disk Management can show the partition numbers of these
> > partitions.
> It does not, it has a drive label.
> On your device
> MSR(not shown) iw partition 3
> C: is partition 4
> D: is partition 6

In the meantime, I have found that Macrium Reflect (Free) gives some
more information, including partition numbers:

- Partition 1 seems to be the real - in use - recovery partition,
because MR says:

1 - WINRE (None)
Primary - NTFS
291.4 MB
400.0 MB

- Partition 5 seems to be some kind of left-over recovery partition,
because it is listed without a label (no 'WINRE'):

5 - (None)
Primary - NTFS
523.4 MB
605.0 MB

- Partition 3 is indeed the MSR (Microsoft Reserved Partition):

3 - (None)
Primary - Unformatted
120.0 MB
120.0 MB

> > In the top pane, the order in the 'Volume' column is different than
> > the physical order: Partition 1, partition 2, partition 5,
> > RECOVERY (D:), Windows (C:).
>
> You've variety of built-in tools to view partitions in an admin mode.
> PowerShell's command Get-Volume
> - shows about the same as Disk Management
> Diskpart provides a little more depth
> List Vol (all partitions/volumes with and without assigned drive labels)
> Sel Disk (command to select the desired disk)
> List Part (command to list and show the partitions and partition number
> on the selected disk)

As many people probably have Macrium Reflect (Free), that's probably
easier than using dangerous tools like 'diskpart' or use 'Get-Volume',
which - at least by default - doesn't give the desired information
(doesn't list partition numbers, doesn't list the MSR, lists other
disks).

[...]

On 1/13/2024 7:35 AM, Big Al wrote:
> On 1/13/24 07:33 AM, Big Al wrote:
>> On 1/12/24 09:14 PM, Paul wrote:
>>> On 1/12/2024 6:31 AM, Frank Slootweg wrote:
>>>> John Hall <john_nospam@jhall.co.uk> wrote:
>>>>> In message <r+dvniBRdnnlFwAy@jhall_nospamxx.co.uk>, John Hall
>>>>> <john_nospam@jhall.co.uk> writes
>>>>> <snip>
>>>>>> I think I'll just wait for Microsoft to fix things rather than try
>>>>>> anything fancy.
>>>>>
>>>>> I'm glad I waited, as Microsoft now seem to have fixed it. Settings >
>>>>> Windows Update now tells me that I'm up to date. I wonder whether
>>>>> Christmas and New Year meant that this update received less testing than
>>>>> usual before it was released.
>>>>
>>>>    Please check that it indeed has been fixed.
>>>>
>>>>    For example on my wife's Windows 10 system, Windows Update indeed says
>>>> "You're up to date", but in 'Update history' ('Quality Updates' section)
>>>> it says that KB5034441 failed to install and gives the 0x80070643 error
>>>> code.
>>>>
>>>>    So: "You're up to date", but install failure and the update is not
>>>> re-offered (nor has any other update been offered/installed).
>>>>
>>>>    And to answer Paul's question, yes this system has a 'special'
>>>> partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
>>>> partition which probably still contains the HP-proprietary recovery for
>>>> Windows 8):
>>>>
>>>>  From 'Disk Management':
>>>>
>>>> [Partition type descriptions translated from Dutch:]
>>>>
>>>> Partition 1: Recovery      partition (400 MB)
>>>> Partition 2: EFI system    partition (260 MB)
>>>> Partition  : Windows (C:)  partition (449.96 GB)
>>>> Partition 5: Recovery      partition (605 MB)
>>>> Partition  : RECOVERY (D:) partition ( 14.94 GB)
>>>>
>>>>    N.B. Partitions are listed in physical order (bottom pane). Disk
>>>> Management does not list the partition numbers for C: and D: and I don't
>>>> see how Disk Management can show the partition numbers of these
>>>> partitions.
>>>>
>>>>    In the top pane, the order in the 'Volume' column is different than
>>>> the physical order: Partition 1, partition 2, partition 5,
>>>> RECOVERY (D:), Windows (C:).
>>>>
>>>>    But most importantly, the question to Winston, Paul et al:
>>>>
>>>>    How can we *check* that the recovery partition was indeed correctly
>>>> 'fixed'/updated?
>>>>
>>>>    Some posters (like John Hall) report no errors, but does that mean
>>>> their system is OK/'fixed'/updated?
>>>>
>>>>    Others (like 'sticks' and me) report errors, but does that mean their
>>>> system is *not* OK/'fixed'/updated?
>>>>
>>>
>>> This has certainly turned into a hobby :-)
>>>
>>>     [Picture]
>>>
>>>      https://i.postimg.cc/HnkmKP8X/4441-installed-OK-dates-filesize.gif
>>>
>>>    Paul
>> I just tried my system last night and I have 566M in Recovery.
>> I did the manual way and when I did the shrink on the OS partition it failed.  96G, said it could not shrink, something about the new size would be less than the  minimum.
>>
>> And I did verify that the Sel Part was 4 for OS and 5 for Recovery and I was on the right partition.
>>
>> Now I wonder if I should run the powershell script?  Will it abort and reset properly if this error pops up there?
>>
>> You're right Paul.  I've spent less time on hobbies.
> Just saw Winston's remarks that the powershell script only fixes the win.re not the partition size.

What I use for viewing partition details, is JKDefrag.

[Picture]

https://i.postimg.cc/YqY9fsg0/JKDefrag-and-friends.gif

Command Prompt - Admin

cd /d C:\users\Bullwinkle\Downloads\JKDefrag

jkdefrag -a 1 -d 2 C: # Visual review of the state of defragmentation. No change to disk.

notepad jkdefrag.log # View textual information about the results. "Top 25" at bottom of file.

jkdefrag -a 5 -d 2 C: # Push disk contents towards partition origin, makes fragmentation worse (OK)

Do Properties on C: , Tools, use Optimize # This defragments files < 50MB
# Optimize is crank, misbehaves in VM. Use defrag from command line, below.

jkdefrag -a 2 -d 2 C: # This is the JKDefrag defragmentation call
# Now the big files are shrunk. This means Windows does most of the work, JKDefrag tidies up.

Finally, for SSD owners or VM users who are getting "slab" complaints in Optimize window:

defrag C: # System defragmenter which is less cranky, and just gets to work.

Those are the tools. The game is played like Space Invaders.

I think there has been a subtle change in the Optimize defragmenter, in that
it seems to be moving some red stuff. But I had too many frosted sugar bombs
for breakfast and I can't be sure.

The examples were done with JKDefrag 3.36 . A relatively small file, and portable software.
I have copies of this *everywhere*. Every install gets one. Every VM gets one.

https://www.kessels.com/JkDefrag/

There are also procedures for cleaning up your VM.
One component, is cleaning the NTFS file system.
Compaction of the VM container, depends on what container you are using.
After your compaction run on a dynamic container, the file should be smaller.

sdelete64 -z C: # Cleaning the C partition of a VM.

# The tool is two-pass. Please be patient. Long run time if you made C: way way too big in VM.

https://learn.microsoft.com/en-us/sysinternals/downloads/sdelete

Anyway, enjoy your adventure. Space invaders beware.

Paul

On 13 Jan 2024, Big Al <alan@invalid.com> wrote in
alt.comp.os.windows-10:

> Just saw Winston's remarks that the powershell script only fixes
> the win.re not the partition size.

So, this implies to me that the script will get us through the current
error condition, but if there's a similar update in the future we may
run into it again, due to low free space in the recovery partition.
Would you agree?

Frank Slootweg wrote on 1/13/24 7:44 AM:
> ...w¡ñ§±¤ñ <winstonmvp@gmail.com> wrote:
>> Frank Slootweg wrote on 1/12/24 4:31 AM:
>>> And to answer Paul's question, yes this system has a 'special'
>>> partition layout. *Two* recovery partitions (and the HP 'RECOVERY'
>>> partition which probably still contains the HP-proprietary recovery for
>>> Windows 8):
>>>
> [...]
>>> From 'Disk Management':
>>>
>>>
>>> [Partition type descriptions translated from Dutch:]
>>>
>>> Partition 1: Recovery partition (400 MB)
>>> Partition 2: EFI system partition (260 MB)
>>> Partition : Windows (C:) partition (449.96 GB)
>>> Partition 5: Recovery partition (605 MB)
>>> Partition : RECOVERY (D:) partition ( 14.94 GB)
>>>
>>> N.B. Partitions are listed in physical order (bottom pane). Disk
>>> Management does not list the partition numbers for C: and D: and I don't
>>> see how Disk Management can show the partition numbers of these
>>> partitions.
>> It does not, it has a drive label.
>> On your device
>> MSR(not shown) iw partition 3
>> C: is partition 4
>> D: is partition 6
>
> In the meantime, I have found that Macrium Reflect (Free) gives some
> more information, including partition numbers:
>
> - Partition 1 seems to be the real - in use - recovery partition,
> because MR says:
>
> 1 - WINRE (None)
> Primary - NTFS
> 291.4 MB
> 400.0 MB
>
> - Partition 5 seems to be some kind of left-over recovery partition,
> because it is listed without a label (no 'WINRE'):
>
> 5 - (None)
> Primary - NTFS
> 523.4 MB
> 605.0 MB
>
> - Partition 3 is indeed the MSR (Microsoft Reserved Partition):
>
> 3 - (None)
> Primary - Unformatted
> 120.0 MB
> 120.0 MB
>
>>> In the top pane, the order in the 'Volume' column is different than
>>> the physical order: Partition 1, partition 2, partition 5,
>>> RECOVERY (D:), Windows (C:).
>>
>> You've variety of built-in tools to view partitions in an admin mode.
>> PowerShell's command Get-Volume
>> - shows about the same as Disk Management
>> Diskpart provides a little more depth
>> List Vol (all partitions/volumes with and without assigned drive labels)
>> Sel Disk (command to select the desired disk)
>> List Part (command to list and show the partitions and partition number
>> on the selected disk)
>
> As many people probably have Macrium Reflect (Free), that's probably
> easier than using dangerous tools like 'diskpart' or use 'Get-Volume',
> which - at least by default - doesn't give the desired information
> (doesn't list partition numbers, doesn't list the MSR, lists other
> disks).
>
> [...]
>
Hi, Frank
In an admin command prompt(Powershell or Command.com) enter
reagentc /info
The result will show WinRE's
- the status (Recovery - Enabled or Disabled)
- location of the active WinRE partition.

It's unlikely that Partition 1 is the real in-use(active) WinRE partition.

More likely, that the OEM or a post device first use and much earlier
Windows installation version placed a WinRE before the o/s partition.
- Up until Windows 10 version 2004, a clean install(including OEM's who
did not follow GPT partitioning Guidelines) placed the Recovery partition
at the beginning of the disk. Any upgrade that required a larger recovery
partition then placed the new one after the Windows partition(carving
space out of the Windows partition)
=> MSFT fixed this in Windows 10 2004 version releasing an updated
Media Creation Tool for creating installation media(usb or iso) and also
ISO builds available in Visual Studio subscriptionsA(fka MSDN and TechNet)
=> Devices that initially had WinRE as the first partition and as the
active WinRE partition were fine up until that Recovery partition became
too small to handle an increase in size of the WinRE partitions
files(primarily winre.wim). Windows by design and consistent with GPT
partitioning guidelines created a new and active WinRE partition after
the Windows partition.

i.e. Partition 5 would be your device's 'active, enabled, WinRE
partition)...and also by design, it does not have a label.

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

On 1/13/24 01:41 PM, Nil wrote:
> On 13 Jan 2024, Big Al <alan@invalid.com> wrote in
> alt.comp.os.windows-10:
>
>> Just saw Winston's remarks that the powershell script only fixes
>> the win.re not the partition size.
>
> So, this implies to me that the script will get us through the current
> error condition, but if there's a similar update in the future we may
> run into it again, due to low free space in the recovery partition.
> Would you agree?
>
I would agree. I've tried to do the manual resize and it fails. It
worked on a VM but not my live system. I dual boot Linux.
I'm looking into doing defrag or jkdefrag as Paul has noted to get some
space at the end. That might be why it won't shrink.

This is (now) a low priority item.
--
Linux Mint 21.2 Cinnamon
Al

Paul wrote on 1/12/24 7:14 PM:
>
> This has certainly turned into a hobby :-)
>
> [Picture]
>
> https://i.postimg.cc/HnkmKP8X/4441-installed-OK-dates-filesize.gif
>
> Paul
>
And will be as long as WinRE continues to grow(apparently like yours has,
since it would be unlikely to have ever been initially created as a 759
MB partition)

Lol...also unlikely for anyone's WinRE partition to be the same size as
another's WinRE partition.

You may recall, I've previously been a proponent of creating the WinRe
partition for clean installs at 1 GB.
- with my Win11 23H2(updated with Jan. 2024 updates) WinRE partition at
827 MB its winre.wim at 811 MB...2 GB could easily become my new
recommendation for the WinRE partition.

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

On 1/13/2024 2:37 PM, Big Al wrote:
> On 1/13/24 01:41 PM, Nil wrote:
>> On 13 Jan 2024, Big Al <alan@invalid.com> wrote in
>> alt.comp.os.windows-10:
>>
>>> Just saw Winston's remarks that the powershell script only fixes
>>> the win.re not the partition size.
>>
>> So, this implies to me that the script will get us through the current
>> error condition, but if there's a similar update in the future we may
>> run into it again, due to low free space in the recovery partition.
>> Would you agree?
>>
> I would agree.  I've tried to do the manual resize and it fails.  It worked on a VM but not my live system.  I dual boot Linux.
> I'm looking into doing defrag or jkdefrag as Paul has noted to get some space at the end.  That might be why it won't shrink.
>
> This is (now) a low priority item.Using jkdefrag I found that restore points were shoved at the end of the drive.
I deleted all of them then went back and ran those manual commands and I was able now to expand the partition by that 250M.
The rest of the commands succeeded and then I ran Windows Update and it succeeded also.

So I'm happy that my system has a larger Recovery now. I probably should have shoved it 500M, but... It's at 881M now.

On 1/13/2024 4:17 PM, Big Al wrote:

> I deleted all of them then went back and ran those manual commands and I
> was able now to expand the partition by that 250M.
> The rest of the commands succeeded and then I ran Windows Update and it
> succeeded also.
>
> So I'm happy that my system has a larger Recovery now.  I probably
> should have shoved it 500M, but... It's at 881M now.

I have to admit, I'm thoroughly confused now.
I have a bunch of messages in this thread saved, but is there any chance
you could post the message ID of the one that had the instructions you
followed to get yours working? It would be much appreciated!

--
Stand With Israel!
NOTE: If you use Google Groups I don't see you,
unless you're whitelisted and that's doubtful.