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:

I am at version 10.0.19045.3930 on all my computers. Is that where I should
be?
--
<Bill>

Brought to you from Anchorage, Alaska

On 1/15/2024 10:37 AM, rsutton wrote:
> On 1/15/2024 7:56 AM, Paul wrote:
>> On 1/14/2024 9:44 PM, sticks wrote:
>>> On 1/14/2024 4:17 PM, sticks wrote:
>>>> Checked my newest system that is about 2 years old and has an SSD drive, and it hadn't been offered it yet.  Upon checking it downloaded it and it too failed.  Checked the size of the MR partition and it too is only about 600MB with less than 80MB free.  So, after sending this, it's down to that computer to do it all on that one too.  At least I'm not so intimidated now.
>>>
>>> Well that didn't go as easily as I had hoped!
>>> Once again I followed the directions on the link Big Al gave.  The only difference was this system is GPT and not MBR.  No problem, directions were easy enough.  All went fine until the last 2 steps, step 8, re-enable WinRE.  It couldn't do it.  Can't remember the exact wording, but it couldn't find the WinRE.wim file.  I did find a copy of the file on the disk, and tried copying it into C:\windows\system32\recovery but that alone did not work.  After a little researching, one suggestion was that the ReAgent.xml file was somehow corrupted or contained faulty information and if the .wim file was there windows would recreate the .xml.  So I renamed it and went to check.
>>>
>>> reagentc /info still said it was disabled and had no location
>>> So, I then tried reagentc /enable and it worked.
>>>
>>> Says it is enabled and it created a new xml file.
>>> Went to windows update and the damn 5034441 is finally installed on all the computers here.
>>> Wow, I sure hope grandma can do this!
>>
>> That Linux Grandma, she gets around. She can bake a
>> cake while installing '4441. Fixing Windows Update is
>> no harder than making a batch of shortbread cookies.
>>
>> One of the steps is to delete the Reserved partition (with Override, to make it possible).
>>
>> Creating a new partition and formatting it NTFS, of course that will erase the
>> previous WinRE.wim . And that was one of the concerns I expressed in my first
>> reading of the procedure, is that "reagentc /enable" after all is said and
>> done, the partition is empty, and a routine like that should be sniffing
>> for details.
>>
>> The real question, is why this was working in the first place. Why
>> did "reagentc /enable" work for me ? I don't know the answer to that.
>>
>>     Paul
> Having followed up on the KB5034441 not installing, I did the steps to delete and re-add a larger partition and made it ntfs, etc. Now, the KB installed successfully, but the (in my case partition 4 ) is empty! I thought the KB would refill it during installation.  Suggestions?

Follow procedure for uninstallation of Patch Tuesday stuff.

The LCU section of the file tree, contains some amount of recent patches.
But the "C" stands for Cumulative, and a Security Update would not be there.

*******

There is likely more than one way to remove it.

https://www.tenforums.com/tutorials/5472-view-windows-update-history-windows-10-a.html

But then, I can't secure a .msu for replacement.

KB5034441 Well, this isn't working for me...

https://www.catalog.update.microsoft.com/Search.aspx?q=5034441

And searches like this, prove Catalog is running, just not doing what I want.
I see "Cumulatives" but no "Security" ones

https://www.catalog.update.microsoft.com/Search.aspx?q=security+update+windows+10++2024-01

If I look in the Uninstall list, 4122 (a previous security) is listed as a Cumulative
on the Catalog site. You can't win, apparently. You can find this one. Just not stock up
on a spare 4441. They could have pulled it I suppose.

https://www.catalog.update.microsoft.com/Search.aspx?q=KB5034122

*******

To check for presence (that you got a new WinRE.wim) .

As Admin

diskpart
list disk
select disk 0
list partition
select partition 4 # This should be the Recovery partition you made. Recall what partition number that was.
assign letter=K # Temporary assignment of a letter, to a hidden partition. Remove access, via a reboot.
exit

Now, in the administrator window

dir /ah K:\Recovery\WindowsRE

That should list a WinRE.wim with a Jan2024 date stamp on it.

The permissions are set, to thwart normal access, so this
should not be easy. This is why I use TestDisk 7.0 for
taking screen shots of "success".

The letter K: will be de-asserted on a reboot.

*******

While '4441 is running, you will notice WinREUpdateInstaller.exe running
in Task Manager.

That's evidence the attempt to replace winRE.wim is in motion.
The procedure is not entirely cloaked in PendMoves or the like.
It has a visible component, that tells you the update is in motion.

The only reason I can remember the name of the thing, is I have a Procmon
trace of the '4441 running. It builds a file in

C:\Windows\Temp
C:\$WinREAgent\Scratch\update.wim 525,---,---
C:\$WinREAgent\Scratch\exported.wim 495,---,---

( C:\Windows\Logs\CBS\CBS.log
C:\Windows\Logs\WinREAgent\setupact.log )

That's a few breadcrumbs. I can't see it writing to Recovery itself.

Paul

On 1/15/2024 8:44 AM, Big Al wrote:

> Did you ever try mintool partition wizard?
> https://www.partitionwizard.com/free-partition-manager.html

No, like backup tools, these things require a lot of careful
test, before you trust them.

Take gparted as a example. I fed it an Apple Mac disk drive,
from my mac G4. "Oh yes" it said, "I grok this format".

I tried to make some change to the disk. gparted
absolutely destroyed it. I had a backup :-) I was
expecting trouble. What was interesting, is the damage
had no pattern to it. It was like a chainsaw was engaged.
You would think with a series of similar partitions,
the damage done on each would be similar. But it was not.

But that's how things go with software, and why
when offered a new item, you think about how many
test bench items you might need.

Paul

On 1/15/2024 12:39 PM, Bill Bradshaw wrote:
> 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:
>
> I am at version 10.0.19045.3930 on all my computers. Is that where I should
> be?
>

Yes. Matches the number on my odometer.

Paul

On Mon, 15 Jan 2024 13:16:46 -0500, Paul <nospam@needed.invalid> wrote:

>On 1/15/2024 8:44 AM, Big Al wrote:
>
>> Did you ever try mintool partition wizard?
>> https://www.partitionwizard.com/free-partition-manager.html
>
>No, like backup tools, these things require a lot of careful
>test, before you trust them.

I would have agreed with you on that point until about 1994. Not so much these
days. The last 30 years have shown us that partitions (and partition managers)
aren't the magical mysterious things that they used to be.

Paul wrote on 1/14/24 5:04 PM:
>
> This means, when '4441 installs, it would have to remove the old WinRE.wim
> before installing the new bigger one.
>
> Paul
>

Windows keeps a log file when the 'reagentc /disable' command is done.
The logfile's location and name
C:\Windows\Logs\ReAgent
ReAgent.log

If the system is operating under design-intent, when the above command is
executed, the winre.wim file is moved from the active recovery partition
to the C:\WINDOWS\system32\Recovery\ folder

[ReAgentc.exe] -----Executing command line: reagentc /disable-----
[ReAgentc.exe] ------------------------------------------------------
[ReAgentc.exe] Update enhanced config info is enabled.
[ReAgentc.exe] WinRE is installed
[ReAgentc.exe] winreCopyWIMBack moved WIM file from
\\?\GLOBALROOT\device\harddisk1\partition4\Recovery\WindowsRE\ to
C:\WINDOWS\system32\Recovery\Winre.wim successfully!

This move ensures that the fix which disables, deletes the Recovery
partition, shrinks the o/s to create more space for a larger Recovery
partition has the ability when reagentc /enable is executed to move the
winre.wim from C: back to the Recovery partition.
- i.e. if not moved, then the winre.wim file would need to be recovered
from media or an ISO.

The same logfile when reagentc /enable is run after resizing(enlarging)
the Recovery partition will show the moving of winre.wim back from
....\system32\Recovery to the Recovery partition.

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

Paul wrote on 1/15/24 5:56 AM:

>
> One of the steps is to delete the Reserved partition (with Override, to make it possible).
>
> Creating a new partition and formatting it NTFS, of course that will erase the
> previous WinRE.wim . And that was one of the concerns I expressed in my first
> reading of the procedure, is that "reagentc /enable" after all is said and
> done, the partition is empty, and a routine like that should be sniffing
> for details.
>
> The real question, is why this was working in the first place. Why
> did "reagentc /enable" work for me ? I don't know the answer to that.
>
> Paul
>
When one runs reagentc /disable - winre.wim is moved to C:\Windows
\system32\Recovery folder

Thus not lost(erased) when deleting the Reserved partition. Once the new
partition is created with the larger size, reagentc/enable moves the
winre.wim file back to newly created partition(same file, same size).

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

On Jan 9, 2024, Ant wrote
(in article<jOycnT_9xr1ACQD4nZ2dnZfqn_SdnZ2d@earthlink.com>):

> Others'
> (https://www.reddit.com/r/Windows10/comments/192l9kj/cumulative_updates_januar
> y_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:
>
> 1. https://support.microsoft.com/en-us/topic/january-9-2024-kb5034275-cumulati
> ve-update-for-net-framework-3-5-4-8-and-4-8-1-for-windows-10-version-22h2-6c9a
> 603c-f0a1-4b32-b7fa-a1c6337523f1
> 2. https://support.microsoft.com/en-us/topic/january-9-2024-kb5034122-os-build
> s-19044-3930-and-19045-3930-7656c6a4-0b06-4424-86a9-d0719f4ac252
>
> I read
> https://support.microsoft.com/en-us/topic/kb5034441-windows-recovery-environme
> nt-update-for-windows-10-version-21h2-and-22h2-january-9-2024-62c04204-aaa5-4f
> ee-a02a-2fdea17075a8
> 's known issue about small WinRE partition with a
> https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-r
> esize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c82
> 29763bf
> link.
>
> Couldn't MS do this to its users automatically without having to do it
> manually for
> non-technical users? :/

Yes, they could, but where’s the fun in that?

Ah, well... I usually back up my home Windows boxes internal boot volumes to
external media twice a year, on the 1st Jan and 1st July. (A full backup,
everything. Note that the data ain’t on the boot volume, it’s on assorted
network thingies, and yes, there’s a separate backup process for the data.)
I then restore the backup to a different volume. I let the backup/restore app
(Macrium or Acronis, most definitately NOT anything from MS) do the
partitions. I now have three identical boot volumes. I set the backup
software to do incremental backups to one of the full backup volumes, the
other is disconnected and sitting in a fire-resistant file cabinet, and
ignore it for the next six months.

If I encountered this problem, (which I haven’t, it appears that my
recovery partitions are big enough, thank you Acronis, if only MS had some
Tuetonic thoroughness) I would wipe the volume, repartition it, and restore
from backup. Nuke and pave usually works. There’s a reason why I have
backups.

Of course, I can do this because I have backups, and spare volumes, and good
software (i.e., not MS backup software. The backup paret of MS’s junk now
saeems to work; the restore part, now, the restore part started out pretty
bad and up to the last time that I tried it got worse.) Those who don’t
have backups...

WinBoxes at work have good backups, too.

On 1/15/2024 2:36 PM, Char Jackson wrote:
> On Mon, 15 Jan 2024 13:16:46 -0500, Paul <nospam@needed.invalid> wrote:
>
>> On 1/15/2024 8:44 AM, Big Al wrote:
>>
>>> Did you ever try mintool partition wizard?
>>> https://www.partitionwizard.com/free-partition-manager.html
>>
>> No, like backup tools, these things require a lot of careful
>> test, before you trust them.
>
> I would have agreed with you on that point until about 1994. Not so much these
> days. The last 30 years have shown us that partitions (and partition managers)
> aren't the magical mysterious things that they used to be.
>

Lets see. Acronis Partition Manager. Few of the routines are
particularly unique. I spot the "cluster size changer" module
in my new purchase. Now, knowing that a function like this is
"very risky", I'm armed with a backup. I push the button.
The churning stops. OK, it says it is done. I start looking
around. I'm in System32, and I see "gee, I never knew Microsoft
put zero sized files in System32". A bit more checking, a number
of files have zero size. If it was a pinball machine, we would
be making the "tilt" sound effect about now.

The thing that makes quality software, is a healthy sense of
paranoia. It's got nothing to do with our knowledge of the topic.
And everything to do with how thorough we can be. That's why
so many of the steps in partition management, are "unnecessary ones".
They are part of a defensive strategy against bad software, as
much as anything else.

For starters, you do CHKDSK before an operation, and CHKDSK
after an operation (some softwares, have their own checking or
consistency routines). You should not have changed the health
status of a partition, by your actions. And not doing CHKDSK,
is why technically perfect code, used to corrupt partitions.
It was because the partition was corrupted before the
partition manager was used, and the partition manager was
the fall guy. Even though CHKDSK has nothing to do with
resizing a partition, we do it anyway, as part of that
sense of paranoia.

Some tools, even have a "simulate" phase before the "do-it"
phase. Some problems can be detected while simulating a change.

The author of gparted, rewrote his code. The first version was
finished, but it had added a lot of whizzy features. And just the
risk level associated with this, was too much for its author.
The code was rewritten, and only the "solid" features were
allowed in. and that's what experience teaches you. It's
the paranoia we learned, that made the difference.

You learn how to write the software, while smashing one
partition at a time.

Paul

On 1/15/2024 2:40 PM, ...w¡ñ§±¤ñ wrote:
> Paul wrote on 1/14/24 5:04 PM:
>>
>> This means, when '4441 installs, it would have to remove the old WinRE.wim
>> before installing the new bigger one.
>>
>>     Paul
>>
>
> Windows keeps a log file when the 'reagentc /disable' command is done.
>  The logfile's location and name
>   C:\Windows\Logs\ReAgent
>    ReAgent.log
>
>
> If the system is operating under design-intent, when the above command is executed, the winre.wim file is moved from the active recovery partition to the C:\WINDOWS\system32\Recovery\ folder
>
> [ReAgentc.exe] -----Executing command line: reagentc  /disable-----
> [ReAgentc.exe] ------------------------------------------------------
> [ReAgentc.exe] Update enhanced config info is enabled.
> [ReAgentc.exe] WinRE is installed
> [ReAgentc.exe] winreCopyWIMBack moved WIM file from \\?\GLOBALROOT\device\harddisk1\partition4\Recovery\WindowsRE\ to C:\WINDOWS\system32\Recovery\Winre.wim successfully!
>
>
> This move ensures that the fix which disables, deletes the Recovery partition, shrinks the o/s to create more space for a larger Recovery partition has the ability when reagentc /enable is executed to move the winre.wim from C: back to the Recovery partition.
>  - i.e. if not moved, then the winre.wim file would need to be recovered from media or an ISO.
>
> The same logfile when reagentc /enable is run after resizing(enlarging) the Recovery partition will show the moving of winre.wim back from ...\system32\Recovery to the Recovery partition.

But I thought that was why it was creating all those duff
Recovery partitions. So that, on a Rollback, it could just
point at the known-good Recovery partition.

Although Win11 has only had one upgrade to date, that
did not seem to create yet-another Recovery partition.
Maybe the behavior changed at some point

Paul

Paul

Paul wrote on 1/15/24 6:03 PM:
> On 1/15/2024 2:40 PM, ...w¡ñ§±¤ñ wrote:
>> Paul wrote on 1/14/24 5:04 PM:
>>>
>>> This means, when '4441 installs, it would have to remove the old WinRE.wim
>>> before installing the new bigger one.
>>>
>>>     Paul
>>>
>>
>> Windows keeps a log file when the 'reagentc /disable' command is done.
>>  The logfile's location and name
>>   C:\Windows\Logs\ReAgent
>>    ReAgent.log
>>
>>
>> If the system is operating under design-intent, when the above command is executed, the winre.wim file is moved from the active recovery partition to the C:\WINDOWS\system32\Recovery\ folder
>>
>> [ReAgentc.exe] -----Executing command line: reagentc  /disable-----
>> [ReAgentc.exe] ------------------------------------------------------
>> [ReAgentc.exe] Update enhanced config info is enabled.
>> [ReAgentc.exe] WinRE is installed
>> [ReAgentc.exe] winreCopyWIMBack moved WIM file from \\?\GLOBALROOT\device\harddisk1\partition4\Recovery\WindowsRE\ to C:\WINDOWS\system32\Recovery\Winre.wim successfully!
>>
>>
>> This move ensures that the fix which disables, deletes the Recovery partition, shrinks the o/s to create more space for a larger Recovery partition has the ability when reagentc /enable is executed to move the winre.wim from C: back to the Recovery partition.
>>  - i.e. if not moved, then the winre.wim file would need to be recovered from media or an ISO.
>>
>> The same logfile when reagentc /enable is run after resizing(enlarging) the Recovery partition will show the moving of winre.wim back from ...\system32\Recovery to the Recovery partition.
>
> But I thought that was why it was creating all those duff
> Recovery partitions. So that, on a Rollback, it could just
> point at the known-good Recovery partition.
>
> Although Win11 has only had one upgrade to date, that
> did not seem to create yet-another Recovery partition.
> Maybe the behavior changed at some point
>
> Paul
>
>
> Paul
>
You have to go back to 2004(Fall build iirc) for not creating an
additional recovery partition.
- Since then, if following guidelines(and obviously aware of the GPT
partitioning guideline and the knowledge of the change in install media
if using MCT created media), OEM's, System Builders who build pcs and use
OEM media, and end-users all devices with Win10 or later fresh installed
place the recovery partition after the Windows partition.
- no new recovery partitions just a growing one, sucking space from the
Windows partition.

There is some variation from the OEM and System Build side, there
pre-2004 images were still in use for months after the MCT media update
thus continued to ship or deliver devices with OEM Windows and a Recovery
partition that was not right adjacent(after) the Windows partition.

Since then post version 2004 with Win10 version upgrades(semiannual
releases initially, now annual) its not unusual to see multiple Recovery
partitions(beginning, a newer one adjacent to Windows, an older after the
active, and obviously that mega-GB OEM Recovery that does not come into
play when the active WinRE is updated or enlarged at the expense of
shrinking C.)...especially, and reported in newgroups or online Q/A forums.

For Win11, if GPT guidelines were followed the likelihood for mulitple
should be quite rare....even though the possiblity remains for OEMs,
System Builders, end-users to not follow guidelines or even later
'tampering' with the partitioning.

None of this pre-cludes that MSFT messed this one up(Recovery partition
too small for updating the partiton with a new or updated winre.wim) and
so far it looks like the issue is limitee to Win10 and not Win11. Which
raise the question of poor quality control and/or a disconnect in
internal communications between teams responsible for the supported Win10
and Win11 versions.

Enjoy your hobby...hopefully the next tornado deployed to the trailer
park won't be as damaging.

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

On Mon, 15 Jan 2024 19:58:53 -0500, Paul <nospam@needed.invalid> wrote:

>On 1/15/2024 2:36 PM, Char Jackson wrote:
>> On Mon, 15 Jan 2024 13:16:46 -0500, Paul <nospam@needed.invalid> wrote:
>>
>>> On 1/15/2024 8:44 AM, Big Al wrote:
>>>
>>>> Did you ever try mintool partition wizard?
>>>> https://www.partitionwizard.com/free-partition-manager.html
>>>
>>> No, like backup tools, these things require a lot of careful
>>> test, before you trust them.
>>
>> I would have agreed with you on that point until about 1994. Not so much these
>> days. The last 30 years have shown us that partitions (and partition managers)
>> aren't the magical mysterious things that they used to be.
>>
>
>Lets see. Acronis Partition Manager. Few of the routines are
>particularly unique. I spot the "cluster size changer" module
>in my new purchase. Now, knowing that a function like this is
>"very risky", I'm armed with a backup. I push the button.
>The churning stops. OK, it says it is done. I start looking
>around. I'm in System32, and I see "gee, I never knew Microsoft
>put zero sized files in System32". A bit more checking, a number
>of files have zero size. If it was a pinball machine, we would
>be making the "tilt" sound effect about now.

I used to be paranoid about working with partitions too, but 30 years and at
least several hundred operations without any issues that I can remember have
changed that.

On 1/16/2024 5:20 PM, Char Jackson wrote:
> On Mon, 15 Jan 2024 19:58:53 -0500, Paul <nospam@needed.invalid> wrote:
>
>> On 1/15/2024 2:36 PM, Char Jackson wrote:
>>> On Mon, 15 Jan 2024 13:16:46 -0500, Paul <nospam@needed.invalid> wrote:
>>>
>>>> On 1/15/2024 8:44 AM, Big Al wrote:
>>>>
>>>>> Did you ever try mintool partition wizard?
>>>>> https://www.partitionwizard.com/free-partition-manager.html
>>>>
>>>> No, like backup tools, these things require a lot of careful
>>>> test, before you trust them.
>>>
>>> I would have agreed with you on that point until about 1994. Not so much these
>>> days. The last 30 years have shown us that partitions (and partition managers)
>>> aren't the magical mysterious things that they used to be.
>>>
>>
>> Lets see. Acronis Partition Manager. Few of the routines are
>> particularly unique. I spot the "cluster size changer" module
>> in my new purchase. Now, knowing that a function like this is
>> "very risky", I'm armed with a backup. I push the button.
>> The churning stops. OK, it says it is done. I start looking
>> around. I'm in System32, and I see "gee, I never knew Microsoft
>> put zero sized files in System32". A bit more checking, a number
>> of files have zero size. If it was a pinball machine, we would
>> be making the "tilt" sound effect about now.
>
> I used to be paranoid about working with partitions too, but 30 years and at
> least several hundred operations without any issues that I can remember have
> changed that.
>

At the current time, one of the reasons for that, is background
integrity checking by the OS. But because that's not documented,
we have no way of knowing how good a job of latent faults that does.

Paul

....w¡ñ§±¤ñ wrote on 1/15/24 8:40 PM:
> Paul wrote on 1/15/24 6:03 PM:
>> On 1/15/2024 2:40 PM, ...w¡ñ§±¤ñ  wrote:
>>> Paul wrote on 1/14/24 5:04 PM:
>>>>
>>>> This means, when '4441 installs, it would have to remove the old
>>>> WinRE.wim
>>>> before installing the new bigger one.
>>>>
>>>>      Paul
>>>>
>>>
>>> Windows keeps a log file when the 'reagentc /disable' command is done.
>>>   The logfile's location and name
>>>    C:\Windows\Logs\ReAgent
>>>     ReAgent.log
>>>
>>>
>>> If the system is operating under design-intent, when the above command
>>> is executed, the winre.wim file is moved from the active recovery
>>> partition to the C:\WINDOWS\system32\Recovery\ folder
>>>
>>> [ReAgentc.exe] -----Executing command line: reagentc  /disable-----
>>> [ReAgentc.exe] ------------------------------------------------------
>>> [ReAgentc.exe] Update enhanced config info is enabled.
>>> [ReAgentc.exe] WinRE is installed
>>> [ReAgentc.exe] winreCopyWIMBack moved WIM file from
>>> \\?\GLOBALROOT\device\harddisk1\partition4\Recovery\WindowsRE\ to
>>> C:\WINDOWS\system32\Recovery\Winre.wim successfully!
>>>
>>>
>>> This move ensures that the fix which disables, deletes the Recovery
>>> partition, shrinks the o/s to create more space for a larger Recovery
>>> partition has the ability when reagentc /enable is executed to move
>>> the winre.wim from C: back to the Recovery partition.
>>>   - i.e. if not moved, then the winre.wim file would need to be
>>> recovered from media or an ISO.
>>>
>>> The same logfile when reagentc /enable is run after
>>> resizing(enlarging) the Recovery partition will show the moving of
>>> winre.wim back from ...\system32\Recovery to the Recovery partition.
>>
>> But I thought that was why it was creating all those duff
>> Recovery partitions. So that, on a Rollback, it could just
>> point at the known-good Recovery partition.
>>
>> Although Win11 has only had one upgrade to date, that
>> did not seem to create yet-another Recovery partition.
>> Maybe the behavior changed at some point
>>
>>     Paul
>>
>>
>>      Paul
>>
> You have to go back to 2004(Fall build iirc) for not creating an
> additional recovery partition.
>  - Since then, if following guidelines(and obviously aware of the GPT
> partitioning guideline and the knowledge of the change in install media
> if using MCT created media), OEM's, System Builders who build pcs and use
> OEM media, and end-users all devices with Win10 or later fresh installed
> place the recovery partition after the Windows partition.
>  - no new recovery partitions just a growing one, sucking space from the
> Windows partition.
>
> There is some variation from the OEM and System Build side, there
> pre-2004 images were still in use for months after the MCT media update
> thus continued to ship or deliver devices with OEM Windows and a Recovery
> partition that was not right adjacent(after) the Windows partition.
>
> Since then post version 2004 with Win10 version upgrades(semiannual
> releases initially, now annual) its not unusual to see multiple Recovery
> partitions(beginning, a newer one adjacent to Windows, an older after the
> active, and obviously that mega-GB OEM Recovery that does not come into
> play when the active WinRE is updated or enlarged at the expense of
> shrinking C.)...especially, and reported in newgroups or online Q/A forums.
>
> For Win11, if GPT guidelines were followed the likelihood for mulitple
> should be quite rare....even though the possiblity remains for OEMs,
> System Builders, end-users to not follow guidelines or even later
> 'tampering' with the partitioning.
>
> None of this pre-cludes that MSFT messed this one up(Recovery partition
> too small for updating the partiton with a new or updated winre.wim) and
> so far it looks like the issue is limitee to Win10 and not Win11. Which
> raise the question of poor quality control and/or a disconnect in
> internal communications between teams responsible for the supported Win10
> and Win11 versions.
>
> Enjoy your hobby...hopefully the next tornado deployed to the trailer
> park won't be as damaging.
>

A few other comments complimentary of colleagues in the Enterprise
community managing(suffering, too) with the Win10 Jan 2024 update WinRE
snafu on multiple(hundreds, thousands) of devices(on/off internal network)
- The script in KB 5034957 for CVE-2024-20666 Bitlocker Bypass that
MSFT released isn't new.
=> It is the same identical script that was previously released in
KB5025175 for CVE-2022-41099 Bit Locker Bypass(Nov. 2022, Mar 2023)
- The script checks if WinRE needs patching by checking the file
version of bootmenuux.dll.
= you can see this in action in the screenshot on this page:
<https://www.bleepingcomputer.com/news/microsoft/microsoft-shares-script-to-update-windows-10-winre-with-bitlocker-fixes/>

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

On 1/15/2024 3:03 AM, ...w¡ñ§±¤ñ wrote:
> sticks wrote on 1/14/24 3:17 PM:
>> On 1/14/2024 2:34 PM, Big Al wrote:
>>> On 1/14/24 09:12 AM, sticks wrote:
>>>> On 1/14/2024 7:25 AM, Big Al wrote:
>>>>> On 1/13/24 06:25 PM, sticks wrote:
>>>>>> 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!
>>>>>>
>>>>> 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 AL!
>>>>
>>> Note:  When you get to the part of shrinking the OS by 250M, and the
>>> shrink fails, then just exit and reagentc /enable.
>>> No harm done.  That was my issue.  The os would not shrink, no room
>>> at the end.  I ran Paul's jkdefrag, Mydefrag, and saw the files at
>>> the end stopping the shrink.  They were the files I could move /
>>> delete etc.
>>> Then I could restart the process.
>>
>> Fortunately, I had lots of space on that drive and partition and did
>> not have this problem.
>> I did solve the update problem on this system using Paul's explanation
>> of basically the same link Al provided.  One of the commands was not
>> quite the right syntax, but help provided the full correct one, and it
>> worked. Don't know why that was.
>> I shrank the C: partition by 1000mb and built a new WinRE partition by
>> the same 1000 mb.  Now the total of my RE partition is 1527MB or 1.49
>> GB.  After completing everything on the MS link, I ran updates again
>> and it installed immediately.  I then did another macrium image and
>> deleted the old one.  As far as I'm concerned that should be the end
>> of it for now!
>> Checked the wife's laptop and it has a 15G RE partition (don't know
>> why it's that big) and had successfully installed the update.
>> Checked my newest system that is about 2 years old and has an SSD
>> drive, and it hadn't been offered it yet.  Upon checking it downloaded
>> it and it too failed.  Checked the size of the MR partition and it too
>> is only about 600MB with less than 80MB free.  So, after sending this,
>> it's down to that computer to do it all on that one too.  At least I'm
>> not so intimidated now.  Now I am not a total newbie on computers, but
>> certainly not a guru of any sorts, but I still can't think of any of
>> the people I know who could do this.  They wouldn't even try.  This
>> all doesn't seem acceptable to me.
>>
>> Much thanks to everyone, especially Big Al, Paul and Winston!
>>
>>
>>
> The 15 GB RE partition is unlikely the 'Active' WinRE partition.
> OEM' place a recovery partition normally at the end of the disk which is
> used to restore the device to as-shipped factory condition.
>  - the successful update didn't use or touch that 15 GB partition.
>
> Open a Command prompt with admin privileges
> At the prompt, enter the following then press the return key.
>  reagentc /info
>
> The result will show the real active WinRe partition # and the disk # on
> which it resides.
>

It looks like it indeed is on partition 1, which is the 15 GB partition.

<https://www.dropbox.com/scl/fi/v9mizojxmnb0dxq79sf4h/Recovery-Partition.jpg?rlkey=75nq7il3z7ig8y77y89jfd74u&dl=0>

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

sticks wrote on 1/17/24 2:41 PM:
> On 1/15/2024 3:03 AM, ...w¡ñ§±¤ñ wrote:
>> sticks wrote on 1/14/24 3:17 PM:
>>> On 1/14/2024 2:34 PM, Big Al wrote:
>>>> On 1/14/24 09:12 AM, sticks wrote:
>>>>> On 1/14/2024 7:25 AM, Big Al wrote:
>>>>>> On 1/13/24 06:25 PM, sticks wrote:
>>>>>>> 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!
>>>>>>>
>>>>>> 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 AL!
>>>>>
>>>> Note:  When you get to the part of shrinking the OS by 250M, and the
>>>> shrink fails, then just exit and reagentc /enable.
>>>> No harm done.  That was my issue.  The os would not shrink, no room
>>>> at the end.  I ran Paul's jkdefrag, Mydefrag, and saw the files at
>>>> the end stopping the shrink.  They were the files I could move /
>>>> delete etc.
>>>> Then I could restart the process.
>>>
>>> Fortunately, I had lots of space on that drive and partition and did
>>> not have this problem.
>>> I did solve the update problem on this system using Paul's explanation
>>> of basically the same link Al provided.  One of the commands was not
>>> quite the right syntax, but help provided the full correct one, and it
>>> worked. Don't know why that was.
>>> I shrank the C: partition by 1000mb and built a new WinRE partition by
>>> the same 1000 mb.  Now the total of my RE partition is 1527MB or 1.49
>>> GB.  After completing everything on the MS link, I ran updates again
>>> and it installed immediately.  I then did another macrium image and
>>> deleted the old one.  As far as I'm concerned that should be the end
>>> of it for now!
>>> Checked the wife's laptop and it has a 15G RE partition (don't know
>>> why it's that big) and had successfully installed the update.
>>> Checked my newest system that is about 2 years old and has an SSD
>>> drive, and it hadn't been offered it yet.  Upon checking it downloaded
>>> it and it too failed.  Checked the size of the MR partition and it too
>>> is only about 600MB with less than 80MB free.  So, after sending this,
>>> it's down to that computer to do it all on that one too.  At least I'm
>>> not so intimidated now.  Now I am not a total newbie on computers, but
>>> certainly not a guru of any sorts, but I still can't think of any of
>>> the people I know who could do this.  They wouldn't even try.  This
>>> all doesn't seem acceptable to me.
>>>
>>> Much thanks to everyone, especially Big Al, Paul and Winston!
>>>
>>>
>>>
>> The 15 GB RE partition is unlikely the 'Active' WinRE partition.
>> OEM' place a recovery partition normally at the end of the disk which
>> is used to restore the device to as-shipped factory condition.
>>   - the successful update didn't use or touch that 15 GB partition.
>>
>> Open a Command prompt with admin privileges
>> At the prompt, enter the following then press the return key.
>>   reagentc /info
>>
>> The result will show the real active WinRe partition # and the disk #
>> on which it resides.
>>
>
> It looks like it indeed is on partition 1, which is the 15 GB partition.
>
> <https://www.dropbox.com/scl/fi/v9mizojxmnb0dxq79sf4h/Recovery-Partition.jpg?rlkey=75nq7il3z7ig8y77y89jfd74u&dl=0>
>
> Looks like another case of an OEM placing their
reset-to-factory-condition Recovery partition(which also includes the
WinRE partition) at the beginning of the disk.
- This device could also be a pre-Win10 device(originally built with Win
7, or 8x). Many of those pre-Win10 devices were built like this by the OEM's.

MBR guidelines for partitioning are shown in this MSFT article
<https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions?>

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

On 1/17/24 10:48 PM, ...w¡ñ§±¤ñ wrote:
<snip>

> reset-to-factory-condition Recovery partition(which also includes the
> WinRE partition) at the beginning of the disk.
> - This device could also be a pre-Win10 device(originally built with Win
> 7, or 8x). Many of those pre-Win10 devices were built like this by the
> OEM's.
>
> MBR guidelines for partitioning are shown in this MSFT article
> <https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions?>
>
>
>
Interesting that the article says the system will grow the WinRE
partition as needed and take from the Windows partition. Contrary to
the 4441 update that won't grow the partition. Seems one hand isn't
following the other at Microsoft.
--
Linux Mint 21.2 Cinnamon
Al

On 1/18/2024 8:03 AM, Big Al wrote:
> On 1/17/24 10:48 PM, ...w¡ñ§±¤ñ wrote:
> <snip>
>
>> reset-to-factory-condition Recovery partition(which also includes the WinRE partition) at the beginning of the disk.
>> - This device could also be a pre-Win10 device(originally built with Win 7, or 8x). Many of those pre-Win10 devices were built like this by the OEM's.
>>
>> MBR guidelines for partitioning are shown in this MSFT article
>> <https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions?>
>>
>>
>>
> Interesting that the article says the system will grow the WinRE partition as needed and take from the Windows partition.   Contrary to the 4441 update that won't grow the partition.   Seems one hand isn't following the other at Microsoft.

There's a subtle distinction there. The previously seen mechanism, works like this.
I don't really think of this as "growing a partition", rather "creating
a new partition which is a bit bigger".

+-----+----------------------------------+----------+
| MBR | Win10 C: | Recovery |
+-----+----------------------------------+----------+

+-----+-----------------------+ - - - - -+----------+
| MBR | Win10 C: (shrink) | | Recovery |
+-----+-----------------------+ - - - - -+----------+

+-----+-----------------------+----------+----------+
| MBR | Win10 C: (shrink) | Recovery | Recovery |
+-----+-----------------------+----------+----------+
^ ^ ^ ^ No longer
WinRE.wim needed

Microsoft doesn't know how to do the following. They refuse to
"dd" the partition to change the origin. Then expand it.
It should be quite safe, since the partition has no
drive letter typically and is not being accessed except
by their own code. You could move the partition by
block transfer, then do an expand to make it the desired
1GB or whatever. (shrink C: , move Recovery left, expand Recovery)

+-----+-------------------------------+-------------+
| MBR | Win10 C: | Recovery1GB |
+-----+-------------------------------+-------------+

When I did that from Linux, gparted chose to move that
partition using "dd" (to the left), rather than another method.
After it was moved to the left, I did a resize in gparted,
to finish the operation. I did not select move/resize and
do both in the same operation. But I could have done it
that way.

Paul

On 1/18/24 12:55 PM, Paul wrote:
> On 1/18/2024 8:03 AM, Big Al wrote:
>> On 1/17/24 10:48 PM, ...w¡ñ§±¤ñ wrote:
>> <snip>
>>
>>> reset-to-factory-condition Recovery partition(which also includes the WinRE partition) at the beginning of the disk.
>>> - This device could also be a pre-Win10 device(originally built with Win 7, or 8x). Many of those pre-Win10 devices were built like this by the OEM's.
>>>
>>> MBR guidelines for partitioning are shown in this MSFT article
>>> <https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions?>
>>>
>>>
>>>
>> Interesting that the article says the system will grow the WinRE partition as needed and take from the Windows partition.   Contrary to the 4441 update that won't grow the partition.   Seems one hand isn't following the other at Microsoft.
>
> There's a subtle distinction there. The previously seen mechanism, works like this.
> I don't really think of this as "growing a partition", rather "creating
> a new partition which is a bit bigger".
>
> +-----+----------------------------------+----------+
> | MBR | Win10 C: | Recovery |
> +-----+----------------------------------+----------+
>
> +-----+-----------------------+ - - - - -+----------+
> | MBR | Win10 C: (shrink) | | Recovery |
> +-----+-----------------------+ - - - - -+----------+
>
> +-----+-----------------------+----------+----------+
> | MBR | Win10 C: (shrink) | Recovery | Recovery |
> +-----+-----------------------+----------+----------+
> ^ ^ ^ ^ No longer
> WinRE.wim needed
>
> Microsoft doesn't know how to do the following. They refuse to
> "dd" the partition to change the origin. Then expand it.
> It should be quite safe, since the partition has no
> drive letter typically and is not being accessed except
> by their own code. You could move the partition by
> block transfer, then do an expand to make it the desired
> 1GB or whatever. (shrink C: , move Recovery left, expand Recovery)
>
> +-----+-------------------------------+-------------+
> | MBR | Win10 C: | Recovery1GB |
> +-----+-------------------------------+-------------+
>
> When I did that from Linux, gparted chose to move that
> partition using "dd" (to the left), rather than another method.
> After it was moved to the left, I did a resize in gparted,
> to finish the operation. I did not select move/resize and
> do both in the same operation. But I could have done it
> that way.
>
> Paul
Yes, I don't like doing 6 operations at once.
I do them 1 at a time. If one fails I don't want to build upon a
failure. Just dang common sense to me.
--
Linux Mint 21.2 Cinnamon
Al

Big Al wrote on 1/18/24 6:03 AM:
> On 1/17/24 10:48 PM, ...w¡ñ§±¤ñ wrote:
> <snip>
>
>> reset-to-factory-condition Recovery partition(which also includes the
>> WinRE partition) at the beginning of the disk.
>> - This device could also be a pre-Win10 device(originally built with
>> Win 7, or 8x). Many of those pre-Win10 devices were built like this by
>> the OEM's.
>>
>> MBR guidelines for partitioning are shown in this MSFT article
>> <https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions?>
>>
>>
>>
>>
> Interesting that the article says the system will grow the WinRE
> partition as needed and take from the Windows partition.   Contrary to
> the 4441 update that won't grow the partition.   Seems one hand isn't
> following the other at Microsoft.

It's actually two different things.
- If WinRE needs growth and is present as partition to the immediate
right of Windows, space from C will be carved out(chopped off) to allow
Windows(during an update) to enlarge the Recovery partition to accomodate
the updates to the files in the WinRE partition
- In this latest case, patching for security and updating Win10
including its WinRE partitoin, there is insuffficient space to
start/finish the process(install the update, shrink Winodws(C:), update
WinRE partition files. Additionally, the part of the process that shrinks
the Windows partition may fall because, system files(e.g. System Restore
Points or other Windows protected files) reside on the end of the Windows
partition) prevent the shrinking.

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

On 1/18/24 04:40 PM, ...w¡ñ§±¤ñ wrote:
>  - In this latest case, patching for security and updating Win10
> including its WinRE partitoin, there is insuffficient space to
> start/finish the process(install the update, shrink Winodws(C:), update
> WinRE partition files. Additionally, the part of the process that
> shrinks the Windows partition may fall because, system files(e.g. System
> Restore Points or other Windows protected files) reside on the end of
> the Windows partition) prevent the shrinking.

I was going to ask till I got to the bottom of your reply.
The above was my problem, I may have had space but C: had files at the
end of the partition. So I was probably fighting 2 issues.

I manually fixed them both and the update went smooth.
--
Linux Mint 21.2 Cinnamon
Al

Big Al wrote on 1/18/24 3:34 PM:
> On 1/18/24 04:40 PM, ...w¡ñ§±¤ñ wrote:
>>   - In this latest case, patching for security and updating Win10
>> including its WinRE partitoin, there is insuffficient space to
>> start/finish the process(install the update, shrink Winodws(C:), update
>> WinRE partition files. Additionally, the part of the process that
>> shrinks the Windows partition may fall because, system files(e.g.
>> System Restore Points or other Windows protected files) reside on the
>> end of the Windows partition) prevent the shrinking.
>
> I was going to ask till I got to the bottom of your reply.
> The above was my problem, I may have had space but C: had files at the
> end of the partition.  So I was probably fighting 2 issues.
>
> I manually fixed them both and the update went smooth.

Glad to hear you figured it out.
There's so much variation across all device in the Win10 universe - no
single common reason for the patch failure.
- another one to this same table is a device without a Win10 Recovery
partition for another variety or reasons(cloned with only the System and
Windows partition, restores with only the System and Windows partition,
Recovery USB media created and WinRE partition deleted, no Recovery USB
media created and WinRE partition deleted. Even another one reported
earlier today - WinRE as first partition on disk but created with a 2GB
size(more than 1 GB free space), enabled and functional for recovery(i.e.
in the wrong place) but sufficient for the security update to install and
update winre.wim.

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

I still see this and no fix with today's automatic monthly updates. It
still has the manual technical script instructions to fix it. :(
--
"[The Lord declares,] 'Rend your heart and not your garments. Return to the Lord your God, for he is gracious and compassionate, slow to anger and abounding in love, and he relents from sending calamity.'" --Joel 2:13! :) <3's Day eve & (L/C)NY (wood dragon).
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| |
\ _ /
( )

On 2/13/2024 2:00 PM, Ant wrote:
> I still see this and no fix with today's automatic monthly updates. It
> still has the manual technical script instructions to fix it.

I've seen you post on this several times. At this point, it's probably
not going to fix it unless YOU try something. Have you tried following
the instructions, making your windows partition smaller, and increasing
the sizer of your ReAgent partition bigger?

Winston, Paul, and others have been very helpful in assisting me fix
this issue on several systems. In the message below, Winston details
removing restore points because of the location they get put on the
disk. Perhaps that might help you.

Message ID:
news://news.eternal-september.org:119/uq1o6ira1s@dont-email.me

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

sticks <wolverine01@charter.net> wrote:
> On 2/13/2024 2:00 PM, Ant wrote:
> > I still see this and no fix with today's automatic monthly updates. It
> > still has the manual technical script instructions to fix it.

> I've seen you post on this several times. At this point, it's probably
> not going to fix it unless YOU try something. Have you tried following
> the instructions, making your windows partition smaller, and increasing
> the sizer of your ReAgent partition bigger?

> Winston, Paul, and others have been very helpful in assisting me fix
> this issue on several systems. In the message below, Winston details
> removing restore points because of the location they get put on the
> disk. Perhaps that might help you.

> Message ID:
> news://news.eternal-september.org:119/uq1o6ira1s@dont-email.me

Try telling non-technical users like elders. :P
--
"[The Lord declares,] 'Rend your heart and not your garments. Return to the Lord your God, for he is gracious and compassionate, slow to anger and abounding in love, and he relents from sending calamity.'" --Joel 2:13! :) <3's Day eve & (L/C)NY (wood dragon).
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| |
\ _ /
( )