"...winston" <winstonmvp@gmail.com> wrote:

KB5046400: Windows Recovery Environment update for Windows 10, version
21H2 and 22H2: October 8, 2024
KB5044615: Safe OS Dynamic Update for Windows 10, version 21H2 and 22H2: October 8, 2024

Requirements:
Sufficient WinRE partition space (minimum 250 MB free space)
WinRE version number less than 10.0.19041.5000
KB5031539 or later SSU installed to apply this update

Check WinRE Version number:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
-> WinREVersion

i.e.
only offered...
if WinRE version is less than 10.0.19041.5000
if device has an active WinRE partition

Detailed Info reference: <https://support.microsoft.com/en-us/topic/kb5046400-windows-recovery-environment-update-for-windows-10-version-21h2-and-22h2-october-8-2024-62ea1496-d349-4dfb-b326-28dd7b9f99b9>

<https://support.microsoft.com/en-us/topic/kb5044615-safe-os-dynamic-update-for-windows-10-version-21h2-and-22h2-october-8-2024-22adef4f-207c-4b57-9bf4-44fb126a3bca>

Wonder which rescue method is better. Both are possible, but seems only
one is really needed.

WinRE (Window Recovery Environment) image in a hidden partition
* Which Microsoft's installer screwed up in my setup by placing it the
wrong position which would require rearranging the partitions to get
their script to work.
* At boot-time, so the partition table denoting active partition must
be sufficiently uncorrupted to read the boot sector to load the
boot manager which then runs WinRE.
* Or Windows loads sufficiently to allow rebooting to WinRE.

Or, daily image backups (scheduled to eliminate the user forgetting) of
all partitions on the system and boot partitions (which can be separate
or the same partition).
* Using a boot-time menu entry as noted above.
* Or using bootable media which does not rely on the Windows boot
manager to load.

Trying to recover what got damaged, or restarting with an exact image of
the drive(s) state. I also don't rely on Windows System Restore to
eradicate malware, corruption of the registry (current set loaded at
Windows load), file system corruption or other cause of file loss, etc.
I rely on image backups (monthly full, weekly differential, daily
incremental) to restore my drive back to an exact prior state.
Retaining image backups for a year provides opportunity to walk back to whatever state I want to restore. For any files that need longer
retention, those are saved (duplicated) in separate logical/file
backups, but I've mostly used removable media for those with backups of
those devices.

WinRE is based on WinPE (Windows Preinstallation Environment). So is
the bootable image used by backup software whether for the boot-time
entry, or in the bootable media for the backup program.

I ask because I'm unlikely to waste time to rearrange my partitions in
the order that Microsoft's script wants to find WinRE as the last
partition instead of in the middle. They undersized the WinRE
partition, and want to enlarge it to add more code for more security
which obviously if only applicable if and when you ever use WinRE.

https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-recovery-environment--windows-re--technical-reference?view=windows-11
WinRE starts automatically after detecting the following issues:
- Two consecutive failed attempts to start Windows.
- Two consecutive unexpected shutdowns that occur within two minutes of
boot completion.
- Two consecutive system reboots within two minutes of boot completion.
- A Secure Boot error (except for issues related to Bootmgr.efi).
- A BitLocker error on touch-only devices.

I configured the BIOS to require a password to boot. That prompt
appears after the POST, but before any boot sector or OS is loaded. The
first 2 conditions won't happen for WinRE when I am away from the
computer, and I don't WinRE triggered when it is my choice to reboot
very soon after a boot. I don't use Secure Boot or Bitlocker. In fact,
my mobo doesn't have a TPM module, and my BIOS is configured to disable
eTPM, so I'm not nuisanced with prompts to upgrade to Windows 11. The
updater sees TPM is absent which is a requirement for Windows 11. So,
now I'm thinking of eradicating the WinRE partition, too.

Since WinRE seems superfluous when doing scheduled daily image backups,
and since the WinRE updates will get bypassed when there is no WinRE
partition to eliminate that nuisancesome source of updates, perhaps I
should just delete the existing WinRE partition to merge into and
enlarge the C: boot partition (Microsoft calls the partition used for
booting the "system" partition, and the partition used for loading the system/OS the "boot" partition, so, yeah, ass backwards). Or, I could
just delete the 529 MB WinRE partition to add even more unallocated
space for overprovisioning on that SSD, but that's tiny compared to the existing 190 GB of unallocated space that I already added for more overprovisioning which is over what the manufacturer already built into
the SSD (about 10% of its raw capacity).

I consider image backups to restore to a known and good prior state of
all partitionts on a drive a better solution than trying to recover from
damage to the partition tables (does WinRE even handle that?), the file
systems in the partitions, or corruption of both system and data files
in those partitions (WinRE won't recover deleted data files).

I'd want my drive to be exactly how it was before whatever problem
occured, not hobbling forward with duct tape wrapped around damaged
knees. When my car is damaged in an accident, I'd rather get a new car
than what I get back from the body shop. Too bad I can't save an image
backup of my car.

WinRE is an escape route for those who don't backup their system. I
have restored from image backups a few times (sometimes from my own
fuckup), but I've never used nor wanted to use WinRE, and the same for
System Recovery. I have System Recovery disabled: awaste of drive space
for restore points. Seems WinRE is also something I should eradicate.

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

On Thu, 10/10/2024 12:14 AM, ...winston wrote:

VanguardLH wrote:

"...winston" <winstonmvp@gmail.com> wrote:

KB5046400: Windows Recovery Environment update for Windows 10, version
21H2 and 22H2: October 8, 2024
KB5044615: Safe OS Dynamic Update for Windows 10, version 21H2 and 22H2: >>> October 8, 2024

Requirements:
   Sufficient WinRE partition space (minimum 250 MB free space)
   WinRE version number less than  10.0.19041.5000
   KB5031539 or later SSU installed to apply this update

Check WinRE Version number:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
   -> WinREVersion

i.e.
only offered...
   if WinRE version is less than 10.0.19041.5000
   if device has an active WinRE partition

Detailed Info reference:
<https://support.microsoft.com/en-us/topic/kb5046400-windows-recovery-environment-update-for-windows-10-version-21h2-and-22h2-october-8-2024-62ea1496-d349-4dfb-b326-28dd7b9f99b9>

<https://support.microsoft.com/en-us/topic/kb5044615-safe-os-dynamic-update-for-windows-10-version-21h2-and-22h2-october-8-2024-22adef4f-207c-4b57-9bf4-44fb126a3bca>

Wonder which rescue method is better.  Both are possible, but seems only
one is really needed.

I'm more inclined to not venture into debating which is better.
Imo, having multiple 3rd party tools(like backup images using different imaging apps(Acronis, Macrium),  latest o/s bootable media(USB), ISO file, and Windows built-in system recovery and tools is a better approach.
 i.e. forget about what's better - just have what's available at your disposal.

Fyi...
 If one is running Windows 10 22H2 and met the requirements(sufficient WinRE partition free disk space, active recovery WinRE partition(preferably located after the Windows partition)...and updated Windows 10 22H2 with the Oct 8 2024 updates, the

following should have been installed:

KB5044273 LCU/SSU 19045.5011
KB5044615: Safe OS Dynamic Update
KB5046400: Windows Recovery Environment

Powershell commands should show the results
Get-Volume
  - WinRE partition size and free space
Reagentc /info
  - WinRE location \\?\GLOBALROOT\device\harddisk#\partition#\Recovery\WindowsRE\winre.wim /index:1
  => where # in the location output will be your specific hardisk and partition #
  => Then use that full path in the DISM /Get-ImageInfo /ImageFile: command to see the WinRE Service Pack Build number and modified date
 e.g.
DISM /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE\winre.wim /index:1

The DISM command for 22H2 should show Service Pack Build 5000 and a modified date on the same or relative near date when the above 3 KB's were installed. Update History should show the KB's for LCU/SSU and WinRE.
Note: You probably will not see the Safe OS KB in Update History or Installed Updates, but one can read KB5044615 for additional info on files version numbers that were installed.

Likewise, similar updating in October 2024 occurs on Windows 11(LCU/SSU, SafeOS, WinRE).

KB5046400

2GB partition defined (TestMachine 4930K, W10 2x4 disks, for later tracking)

0x80070643 "Download Error"

:-)

What is interesting, is the file in Scratch has exactly the same
SHA1SUM value as the one in the 2GB partition. After I took a hash
of the file in Scratch, it was removed.

Name: update.wim Thursday, ‎October ‎10, ‎2024, ‏‎11:27:21 AM
Size: 481405782 bytes (459 MiB)
SHA1: 60ECEC41C19005991D06F964176B01850C977D5A

Name: winre.wim Monday, ‎September ‎2, ‎2024, ‏‎11:29:46 AM
Size: 481405782 bytes (459 MiB)
SHA1: 60ECEC41C19005991D06F964176B01850C977D5A

The Registry key is missing, which is likely why the update tried to run.
No, I did not remove it.

Paul

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

On Thu, 10/10/2024 12:16 PM, Paul wrote:

On Thu, 10/10/2024 12:14 AM, ...winston wrote:

VanguardLH wrote:

"...winston" <winstonmvp@gmail.com> wrote:

KB5046400: Windows Recovery Environment update for Windows 10, version >>>> 21H2 and 22H2: October 8, 2024
KB5044615: Safe OS Dynamic Update for Windows 10, version 21H2 and 22H2: >>>> October 8, 2024

Requirements:
   Sufficient WinRE partition space (minimum 250 MB free space)
   WinRE version number less than  10.0.19041.5000
   KB5031539 or later SSU installed to apply this update

Check WinRE Version number:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
   -> WinREVersion

i.e.
only offered...
   if WinRE version is less than 10.0.19041.5000
   if device has an active WinRE partition

Detailed Info reference:
<https://support.microsoft.com/en-us/topic/kb5046400-windows-recovery-environment-update-for-windows-10-version-21h2-and-22h2-october-8-2024-62ea1496-d349-4dfb-b326-28dd7b9f99b9>

<https://support.microsoft.com/en-us/topic/kb5044615-safe-os-dynamic-update-for-windows-10-version-21h2-and-22h2-october-8-2024-22adef4f-207c-4b57-9bf4-44fb126a3bca>

Wonder which rescue method is better.  Both are possible, but seems only >>> one is really needed.

I'm more inclined to not venture into debating which is better.
Imo, having multiple 3rd party tools(like backup images using different imaging apps(Acronis, Macrium),  latest o/s bootable media(USB), ISO file, and Windows built-in system recovery and tools is a better approach.
 i.e. forget about what's better - just have what's available at your disposal.

Fyi...
 If one is running Windows 10 22H2 and met the requirements(sufficient WinRE partition free disk space, active recovery WinRE partition(preferably located after the Windows partition)...and updated Windows 10 22H2 with the Oct 8 2024 updates, the

following should have been installed:

KB5044273 LCU/SSU 19045.5011
KB5044615: Safe OS Dynamic Update
KB5046400: Windows Recovery Environment

Powershell commands should show the results
Get-Volume
  - WinRE partition size and free space
Reagentc /info
  - WinRE location \\?\GLOBALROOT\device\harddisk#\partition#\Recovery\WindowsRE\winre.wim /index:1
  => where # in the location output will be your specific hardisk and partition #
  => Then use that full path in the DISM /Get-ImageInfo /ImageFile: command to see the WinRE Service Pack Build number and modified date
 e.g.
DISM /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE\winre.wim /index:1

The DISM command for 22H2 should show Service Pack Build 5000 and a modified date on the same or relative near date when the above 3 KB's were installed. Update History should show the KB's for LCU/SSU and WinRE.
Note: You probably will not see the Safe OS KB in Update History or Installed Updates, but one can read KB5044615 for additional info on files version numbers that were installed.


Likewise, similar updating in October 2024 occurs on Windows 11(LCU/SSU, SafeOS, WinRE).

KB5046400

2GB partition defined (TestMachine 4930K, W10 2x4 disks, for later tracking)

0x80070643 "Download Error"

:-)

What is interesting, is the file in Scratch has exactly the same
SHA1SUM value as the one in the 2GB partition. After I took a hash
of the file in Scratch, it was removed.

Name: update.wim Thursday, ‎October ‎10, ‎2024, ‏‎11:27:21 AM
Size: 481405782 bytes (459 MiB)
SHA1: 60ECEC41C19005991D06F964176B01850C977D5A

Name: winre.wim Monday, ‎September ‎2, ‎2024, ‏‎11:29:46 AM
Size: 481405782 bytes (459 MiB)
SHA1: 60ECEC41C19005991D06F964176B01850C977D5A

The Registry key is missing, which is likely why the update tried to run.
No, I did not remove it.

A second install, went more normally. Registry
value was present, and ended in 3920, update applied
and now it reads 5000. That's the AMD machine and
disk 30A.

Paul

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

On 10/9/2024 11:14 PM, ...winston wrote:

 If one is running Windows 10 22H2 and met the requirements(sufficient WinRE partition free disk space, active recovery WinRE
partition(preferably located after the Windows partition)...and updated Windows 10 22H2 with the Oct 8 2024 updates, the following should have
been installed:
KB5044273 LCU/SSU 19045.5011
KB5044615: Safe OS Dynamic Update
KB5046400: Windows Recovery Environment

Powershell commands should show the results
Get-Volume
  - WinRE partition size and free space
Reagentc /info
  - WinRE location \\?\GLOBALROOT\device\harddisk#\partition#\Recovery\WindowsRE\winre.wim /index:1
  => where # in the location output will be your specific hardisk and partition #
  => Then use that full path in the DISM /Get-ImageInfo /ImageFile:
command to see the WinRE Service Pack Build number and modified date
 e.g.
DISM /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE\winre.wim /index:1

The DISM command for 22H2 should show Service Pack Build 5000 and a
modified date on the same or relative near date when the above 3 KB's
were installed. Update History should show the KB's for LCU/SSU and WinRE. Note: You probably will not see the Safe OS KB in Update History or
Installed Updates, but one can read KB5044615 for additional info on
files version numbers that were installed.

Everything you wrote is exactly how it is on my machine. Even not
seeing the Safe OS update. I did go and look and you have to go into
the registry and look for WinREVerion at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion. If it installed properly it should be at version 10.0.19041.5000. Mine is at
this value.

Thanks winston!


--
I Stand With Israel!

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

On Thu, 10/10/2024 2:33 PM, ...winston wrote:

Paul wrote:

On Thu, 10/10/2024 12:16 PM, Paul wrote:

On Thu, 10/10/2024 12:14 AM, ...winston wrote:

VanguardLH wrote:

"...winston" <winstonmvp@gmail.com> wrote:

KB5046400: Windows Recovery Environment update for Windows 10, version >>>>>> 21H2 and 22H2: October 8, 2024
KB5044615: Safe OS Dynamic Update for Windows 10, version 21H2 and 22H2: >>>>>> October 8, 2024

Requirements:
    Sufficient WinRE partition space (minimum 250 MB free space) >>>>>>     WinRE version number less than  10.0.19041.5000
    KB5031539 or later SSU installed to apply this update

Check WinRE Version number:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
    -> WinREVersion

i.e.
only offered...
    if WinRE version is less than 10.0.19041.5000
    if device has an active WinRE partition

Detailed Info reference:
<https://support.microsoft.com/en-us/topic/kb5046400-windows-recovery-environment-update-for-windows-10-version-21h2-and-22h2-october-8-2024-62ea1496-d349-4dfb-b326-28dd7b9f99b9>

<https://support.microsoft.com/en-us/topic/kb5044615-safe-os-dynamic-update-for-windows-10-version-21h2-and-22h2-october-8-2024-22adef4f-207c-4b57-9bf4-44fb126a3bca>

Wonder which rescue method is better.  Both are possible, but seems only >>>>> one is really needed.

I'm more inclined to not venture into debating which is better.
Imo, having multiple 3rd party tools(like backup images using different imaging apps(Acronis, Macrium),  latest o/s bootable media(USB), ISO file, and Windows built-in system recovery and tools is a better approach.
  i.e. forget about what's better - just have what's available at your disposal.

Fyi...
  If one is running Windows 10 22H2 and met the requirements(sufficient WinRE partition free disk space, active recovery WinRE partition(preferably located after the Windows partition)...and updated Windows 10 22H2 with the Oct 8 2024 updates, the

following should have been installed:

KB5044273 LCU/SSU 19045.5011
KB5044615: Safe OS Dynamic Update
KB5046400: Windows Recovery Environment

Powershell commands should show the results
Get-Volume
   - WinRE partition size and free space
Reagentc /info
   - WinRE location \\?\GLOBALROOT\device\harddisk#\partition#\Recovery\WindowsRE\winre.wim /index:1
   => where # in the location output will be your specific hardisk and partition #
   => Then use that full path in the DISM /Get-ImageInfo /ImageFile: command to see the WinRE Service Pack Build number and modified date
  e.g.
DISM /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE\winre.wim /index:1

The DISM command for 22H2 should show Service Pack Build 5000 and a modified date on the same or relative near date when the above 3 KB's were installed. Update History should show the KB's for LCU/SSU and WinRE.
Note: You probably will not see the Safe OS KB in Update History or Installed Updates, but one can read KB5044615 for additional info on files version numbers that were installed.


Likewise, similar updating in October 2024 occurs on Windows 11(LCU/SSU, SafeOS, WinRE).

KB5046400

2GB partition defined (TestMachine 4930K, W10 2x4 disks, for later tracking)

0x80070643 "Download Error"

:-)

What is interesting, is the file in Scratch has exactly the same
SHA1SUM value as the one in the 2GB partition. After I took a hash
of the file in Scratch, it was removed.

Name: update.wim                                  Thursday, ‎October ‎10, ‎2024, ‏‎11:27:21 AM
Size: 481405782 bytes (459 MiB)
SHA1: 60ECEC41C19005991D06F964176B01850C977D5A

Name: winre.wim                                   Monday, ‎September ‎2, ‎2024, ‏‎11:29:46 AM
Size: 481405782 bytes (459 MiB)
SHA1: 60ECEC41C19005991D06F964176B01850C977D5A

The Registry key is missing, which is likely why the update tried to run. >>> No, I did not remove it.

A second install, went more normally. Registry
value was present, and ended in 3920, update applied
and now it reads 5000. That's the AMD machine and
disk 30A.

    Paul

First, backing up a bit to your earlier post.
If the device(test machine) os was previously updated with either of the two earlier WinRE updates(way back in July 2023 and Dec 2023(or Jan 2024) then the reg key would be present.
If the device(test machine) was recent install(disk or vm) then the reg key would not be present but would not be a reason why the update tried to run(the Service Pack Build number, modified date, etc. can be found in the image with/without the reg key

being present using the Powershell DISM route I noted in my earlier reply to VanguardLH.

:) It never crossed my mind or even considered that you would remove that reg key.

I'm more inclined to think the initial failure(since KB5046400) is only offered via Windows Update(not stand-alone Catalog option) was due to other reasons.

Similarly, with respect to that same reg key...it's not always present on Win11 even after the having applied those earlier(Jan.'24, Oct.'23, June '23, ) Win RE Updates. The Oct. 2024 WinRE update(and SafeOS) will still be applied in Win11 23H2 and

probably before or after or coincidental with Win11 23H2 Oct. 224 LCU/SSU.

 - For Win11 23H2 KB5044617 indicates the latest(Oct 2024) WinRE version(10.0.22621.4305).

Fixed!

(own-goal :-/ )

fsutil behavior set disablecompression 1 # Even though this is an NTFS setting, the DISM compression
# attribute of a winRE.wim cannot be applied if this is asserted.
# This is just stupid. The attribute is like the compression
# type of a ZIP, which can either be "Store" or "LZW" in a sense.
# It is a private setting that only DISM knows about. What DISM
# is doing, does NOT involve NTFS New Compression or Old Compression.

Debug sequence:

1) WindowsUpdate.log # Contains *no hint*, not even a mouse fart of a hint,
# what is wrong. Contains continuous and erroneous indication
# that the DoSVC sandbox is busy and we can't get the update,
# which as it happens, is bullshit. I wasted time because
# of this attempt to mislead me. I switched DoSBC OFF and ON...

2) I got lucky :-) The Agent Ransack search
dialog, had the last search I did.

dism.log

Now, this had the word "compression" in it, and this was enough to tickle the
same neuron the last time this happened.

fsutil behavior set disablecompression 0 # And Reboot, click the Retry button and notice the
# machine activity is "different".

Since the partition was 2GB, the right flavor, and so on,
it installed. The registry setting, I missed it, but it *was*
there, and it was 3920, now it is 5000.

Recommendation: Tell the patch-person for this one, to catch the compression
setting and deliver an error other than the one and only
error code they've got at Microsoft. 0x80070643 Bob For Apples Error

My head is in the barrel, but I still didn't nab an apple.

Paul

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

On Mon, 10/14/2024 5:41 PM, ...winston wrote:

Paul wrote:

Since the partition was 2GB, the right flavor, and so on,

it installed. The registry setting, I missed it, but it *was*
there, and it was 3920, now it is 5000.

My head is in the barrel, but I still didn't nab an apple.

    Paul

For Windows the barrel is more likely full of pickles.

Here's one for you to ponder about the Oct.2024 Win10 WinRE update

Background"
 Much older device
Surface 3, Win10 Pro 64 Bit, Atom chip, 8 GB RAM, 128 GB SSD(60 GB free space), 128 GB SDXC(90 GB free space), WinRE partition(1 GB, 447 MB Free)
 - Monthly LCU's and SSU always take up to 30-45 minutes to check for updates, download and install before the required restart, and another 5-10 minutes before logon screen followed by another minute or so to desktop.
 - Feature updates since Win10 2004 always fail to install via Windows Update(no amount of troubleshooting - Windows Update, DiskCleanup, DISM Health or Component store, rename Software Distrib. etc. fixes WU inability to install the last 4 feature

updates(20H2, 21H1, 21H2, 22H2)

 What does work and only works for feature updates is the ISO with the *.wim image) when running setup.exe after copying the mounted ISO's files to new folder on the root of C: drive.

This month took an unusual route to install all Oct 2024 updates.
Windows Update installed LCU/SSU without issue. Not installed - .NET cumulative, WinRE
WU update successfully installed Win10:   (took about 30 min)
 - KB 5001716(Windows Update Service Components)
 - KB 5044273 (LCU/SSU 19045.5011)
WU did not install:
 - KB 5044091 (.NET 3.5, 4.8, 4.8.1 Cumulative)
 - KB 5046400 (WinRE Service Pack Build 5000)

Rerunning Windows Update 2x(twice)failed to install .NET and WinRE updates and notified with the same error code.
 - 0x899705b4 => usually indicates timeout issue

No change after the usual troubleshooting(Windows Update, DiskCleanup, DISM, Sfc, rename Software Distribution) and rerunning WU(same error code).

Was going to sit on it/comeback later, then noticed in Update History that no .NET 3.5/4.8/4.8.1 updates had been installed since July 2024.

Went to the Microsoft Catalog for Oct 2024 .NET's KB5044091 which was two separate downloadable KB's 5044020 and 5044029)
 - Downloaded both and installed both successfully, restarted

Reran Windows Update => KB 5044091 (WinRE) offered, successfully installed and updated to WinRE Service Pack Build 5000 - Free space on WinRE partition dropped by 16 MB(431 MB free space)

Sometimes the barrel is full of briny pickle juice.

Go figure - only partially convinced that .NET was the root cause, but it worked.
 - and after WinRE was updated, uninstalled those 2 standalone .Net KB's(4020, 4029) then reran Windows Update and was offered KB 5044091 .NET Oct 2024 update, installed fine(shows up as its KB# in Update History and only as KB5044029 in Programs&

Features Installed Updates.


dotNET uses JIT re-compilation. If the JIT won't work, this
can prevent a .NET equipped executable from running. It's remotely
possible some damage there, could prevent forward progress.

If run in a Command Prompt, there is an opportunity for an executable
to whine about mscoree.dll or similar.

For example, at one time, the Firewall would not start, because
the .NET for it was not ready to go. We no longer see that today.

The "netfx_setupverifier.exe" only goes up to 4.7.2 , so isn't
in a position to test everything on offer today. I think that at least
tried to link the library, as part of a test that everything worked.
While Microsoft has some "Learn" pages, they're mostly about
enumeration, and not about test (test for functional subsystem).

https://learn.microsoft.com/en-us/archive/blogs/astebner/net-framework-setup-verification-tool-cleanup-tool-and-detection-sample-code-now-support-net-framework-4-7-2

This is what I've got. Haven't spotted anything more recent.

Name: netfx_setupverifier.exe
Size: 281,088 bytes (274 KiB)
SHA256: 8DA4184523F89395762216ADF906F6679ED4DEDB3D96E7AA106BF213A390A356

My WinRE run would not work, because DISM was flummoxed. If .NET was not working, that could also cause something like DISM to fail. But then, more
or less speaking, the entire OS would fall over, if .NET damage was
bad enough :-)

And you had enough SSD, so maybe this example machine did not need
to use WOF (Windows Overlay Filesystem) or other tricks, for space reasons.

Paul

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