Tried to run the latest update. kb5041580-x64.cab downloaded
from the MS catalog site. I keep getting a fail at 4.9%. Error
8007000d. It seems to be a common error. I don't find anything
helpful in the log.
Well, that error message is an MS-produced error message. Ergo MS should
have it linked to other MS software.
Try this;
Settings/ Update and Security
Troubleshoot
Windows Update
Tried to run the latest update. kb5041580-x64.cab downloaded
from the MS catalog site. I keep getting a fail at 4.9%. Error
8007000d. It seems to be a common error. I don't find anything
helpful in the log.
DISM.exe /Online /Add-Package /PackagePath:L:\Win-security-update-8-24\kb5041580-x64.cab
I've tried all the tricks I can think of: Make sure the services are running. Run SFC. Run DISM repair. I'm beginning to wonder whether
there's some kind of tweak that the update is rejecting, but I wouldn't
know where to start looking.
On Wed, 8/21/2024 2:23 PM, Newyana2 wrote:
Tried to run the latest update. kb5041580-x64.cab downloaded
from the MS catalog site. I keep getting a fail at 4.9%. Error
8007000d. It seems to be a common error. I don't find anything
helpful in the log.
DISM.exe /Online /Add-Package /PackagePath:L:\Win-security-update-8-24\kb5041580-x64.cab
I've tried all the tricks I can think of: Make sure the services are
running. Run SFC. Run DISM repair. I'm beginning to wonder whether
there's some kind of tweak that the update is rejecting, but I wouldn't
know where to start looking.
$ Err_6.4.5.exe 0x8007000d
# for hex 0x8007000d / decimal -2147024883
STIERR_INVALID_HW_TYPE stierr.h
STIERR_INVALID_HW_TYPE stierr.h
# as an HRESULT: Severity: FAILURE (1), FACILITY_WIN32 (0x7), Code 0xd
# for hex 0xd / decimal 13
ERROR_INVALID_DATA winerror.h <===
# The data is invalid. >===
# 3 matches found for "0x8007000d"
It's a rather generic error, you'd need to examine a log file of some sort, and hope there is some context near by.
*******
I got 12 results for package download. The .msu ones are executable, double-click and use.
https://i.postimg.cc/YSQLDtyw/catalog-search.gif
The .msu also works out dependencies. If a servicing stack is missing,
it will tell you something bogus like "not for this machine". The errors
the .msu throws aren't always useful.
On 8/21/2024 8:46 PM, Paul wrote:
On Wed, 8/21/2024 2:23 PM, Newyana2 wrote:
Tried to run the latest update. kb5041580-x64.cab downloaded
from the MS catalog site. I keep getting a fail at 4.9%. Error
8007000d. It seems to be a common error. I don't find anything
helpful in the log.
DISM.exe /Online /Add-Package /PackagePath:L:\Win-security-update-8-24\kb5041580-x64.cab
I've tried all the tricks I can think of: Make sure the services are
running. Run SFC. Run DISM repair. I'm beginning to wonder whether
there's some kind of tweak that the update is rejecting, but I wouldn't
know where to start looking.
$ Err_6.4.5.exe 0x8007000d
# for hex 0x8007000d / decimal -2147024883
STIERR_INVALID_HW_TYPE stierr.h >> STIERR_INVALID_HW_TYPE stierr.h >> # as an HRESULT: Severity: FAILURE (1), FACILITY_WIN32 (0x7), Code 0xd
# for hex 0xd / decimal 13
ERROR_INVALID_DATA winerror.h <===
# The data is invalid. >===
# 3 matches found for "0x8007000d"
It's a rather generic error, you'd need to examine a log file of some sort, >> and hope there is some context near by.
*******
I got 12 results for package download. The .msu ones are executable, double-click and use.
https://i.postimg.cc/YSQLDtyw/catalog-search.gif
The .msu also works out dependencies. If a servicing stack is missing,
it will tell you something bogus like "not for this machine". The errors
the .msu throws aren't always useful.
I also tried the MSU. No luck with either. The MSU ran fine on my
laptop with Win10. On this computer it just showed a brief message
that the computer was not updated. Yet it did replace my ieframe files, oddly.
I had replaced both ieframe.dll files with versions from 20H2 to make
IE functional. The update put back the old ones and thereby broke IE
again, but it didn't perform the update! I get a distinct feeling that MS
are trying to tell me I've been a bad boy and don't deserve an update. Something like, "Our way or the highway." So I need to figure out what
tweak I've made that they don't like.
I'm inclined to suspect this all the more because I had trouble
when I first built this box. I installed, customized, then failed to
run updates and failed to get it activated. After a lot of trying
I finally installed fresh and did those thingss BEFORE tweaking,
and it all worked just fine. But I'm not willing to spend another 2
weeks doing the tweks all over again just for the sake of an update.
I'm inclined to suspect this all the more because I had trouble
when I first built this box. I installed, customized, then failed to
run updates and failed to get it activated. After a lot of trying
I finally installed fresh and did those thingss BEFORE tweaking,
and it all worked just fine. But I'm not willing to spend another 2
weeks doing the tweks all over again just for the sake of an update.
Are you hinting that you damaged your WinSxS on purpose ???
Maybe you need one of those DISM recipes (for repair) ?
dism /Online /Cleanup-image /ScanHealth
dism /Online /Cleanup-image /CheckHealth
dism /Online /Cleanup-image /RestoreHealth <===
dism /Online /Cleanup-image /StartComponentCleanup
sfc /scannow
sfc /verifyonly <===
Size and free space of WinRE partition?
Powershell admin command
Get-Volume
One can not look in Disk Management for the size and free space of WinRE.
I am also assuming, at this time, your device is UEFI with GPT partitioning(not legacy BIOS and MBR partitioning)
First question:
Is this a dual boot device?
If not a dual boot device
Second and Third Question:
Is Disk 1 a clone of O or is Disk 1 another different Windows o/s?
if either case are they bootable from the UEFI BIOS settings?
Let's go back to WinRE
Powershell admin command
Get-Volume
The above will show all the sizes of all partitions on the disks. If you labeled the o/s partition it will show that label. The other partitions
shown should be System and WinRE. WinRE may also be shown as Recovery.
- the MSR partition will not be shown in Get-Volume
One can also see all the partitions but not size via Diskpart
List vol
- will show all partitions(like Disk Management with a bit more info)
But, if you select a disk (in Diskpart)
Select Disk 0
List partition
=> you will see all partitions on Disk 0 including the MSR(i.e.
System, MSR(shows as Reserved), Windows(your os), WinRE(Recovery)
=> Unlike Get-Volume(in Powershell) Diskpart list part does not show
free size.
Fourth Question:
Look in Windows Update\Update History
Is KB5034441 shown as successfully installed?
On 8/23/2024 3:34 AM, ...winston wrote:
One can not look in Disk Management for the size and free space of WinRE.
I am also assuming, at this time, your device is UEFI with GPT partitioning(not legacy BIOS and MBR partitioning)
Yes. But I'm still wondering why WinRE matters. I've
never used WinRE and never knowingly installed it.
First question:Yes. Multi-boot. I've got Win10, Suse15, Xubuntu.
Is this a dual boot device?
If not a dual boot deviceI use BootIt as a boot manager. Win10 and Suse boot
Second and Third Question:
Is Disk 1 a clone of O or is Disk 1 another different Windows o/s?
if either case are they bootable from the UEFI BIOS settings?
from disk 0. Disk 1 is roughly a clone. Not exact and not
the same size. Win10 is there mainly as a backup. I didn't
figure out how to get it botting and don't need it to boot.
Let's go back to WinRE
Powershell admin command
Get-Volume
The above will show all the sizes of all partitions on the disks. If you labeled the o/s partition it will show that label. The other partitions shown should be System and WinRE. WinRE may also be shown as Recovery.
- the MSR partition will not be shown in Get-Volume
Tyiping Get-Volume and pressing Enter does nothing. It just
goes back to a prompt in the next line. Power Shell running
as admin. Get-Partition also does nothing.
One can also see all the partitions but not size via Diskpart
List vol
- will show all partitions(like Disk Management with a bit more info)
But, if you select a disk (in Diskpart)
Select Disk 0
List partition
=> you will see all partitions on Disk 0 including the MSR(i.e. System, MSR(shows as Reserved), Windows(your os), WinRE(Recovery)
=> Unlike Get-Volume(in Powershell) Diskpart list part does not show free size.
Diskpart says 556 MB, same as the GUI tool.
Fourth Question:I show no Update History in Windows Update WinRT
Look in Windows Update\Update History
Is KB5034441 shown as successfully installed?
UI. I did find it in the control panel programs applet.
That KB is not there. There are 3 503s, but none
matches that number. I suspect those are the updates
I ran when I first set up the machine. I think the last
was in April.
On Fri, 8/23/2024 11:46 AM, Newyana2 wrote:
On 8/23/2024 3:34 AM, ...winston wrote:
One can not look in Disk Management for the size and free space of WinRE. >>> I am also assuming, at this time, your device is UEFI with GPT partitioning(not legacy BIOS and MBR partitioning)
Yes. But I'm still wondering why WinRE matters. I've
never used WinRE and never knowingly installed it.
First question:Yes. Multi-boot. I've got Win10, Suse15, Xubuntu.
Is this a dual boot device?
If not a dual boot deviceI use BootIt as a boot manager. Win10 and Suse boot
Second and Third Question:
Is Disk 1 a clone of O or is Disk 1 another different Windows o/s?
if either case are they bootable from the UEFI BIOS settings?
from disk 0. Disk 1 is roughly a clone. Not exact and not
the same size. Win10 is there mainly as a backup. I didn't
figure out how to get it botting and don't need it to boot.
Let's go back to WinRE
Powershell admin command
Get-Volume
The above will show all the sizes of all partitions on the disks. If you labeled the o/s partition it will show that label. The other partitions shown should be System and WinRE. WinRE may also be shown as Recovery.
- the MSR partition will not be shown in Get-Volume
Tyiping Get-Volume and pressing Enter does nothing. It just
goes back to a prompt in the next line. Power Shell running
as admin. Get-Partition also does nothing.
One can also see all the partitions but not size via Diskpart
List vol
- will show all partitions(like Disk Management with a bit more info) >>> But, if you select a disk (in Diskpart)
Select Disk 0
List partition
=> you will see all partitions on Disk 0 including the MSR(i.e. System, MSR(shows as Reserved), Windows(your os), WinRE(Recovery)
=> Unlike Get-Volume(in Powershell) Diskpart list part does not show free size.
Diskpart says 556 MB, same as the GUI tool.
Fourth Question:I show no Update History in Windows Update WinRT
Look in Windows Update\Update History
Is KB5034441 shown as successfully installed?
UI. I did find it in the control panel programs applet.
That KB is not there. There are 3 503s, but none
matches that number. I suspect those are the updates
I ran when I first set up the machine. I think the last
was in April.
[Picture]
https://i.postimg.cc/yNmkTjW6/Get-Volume.gif
https://i.postimg.cc/8PxRKykL/get-volume-win10.gif
Windows Recovery Environment (WinRE) is like Windows Preinstall Environment (WinPE)
but WinRE is managed separately and via being on a separate partition, allows C: to be smashed and the machine can still present info.
reagentc /info
gives some information. But reagentc commands such as
reagentc /disable
actually move the content around (whackamole, really).
I presented a recipe in the past, on how you "reload" a reference
version of WinRE from an install ISO. Then the updates such as Win10 KB5034441
can overwrite the "new" WinRE you set up. While it may try to "run away"
on you, you can stomp it like a bug, with the correct recipe :-) Comforting.
On one occasion, the bastardly thing moved WinRE to another folder on
the same Recovery partition, rather than copy it back to a hidey hole on C: . It's devious, is all I can say. The person who designed that, is obviously OCD and is bound and determined to thwart user maintenance attempts.
Thank God someone came up with a repair recipe, which I copied.
Anyway, carry on.
[Picture]
https://i.postimg.cc/L5p570Q0/WU-Update-History-Ocean-Of-Success.gif
How did Disk 1 come to be. Windows 10 install, copied from another disk,
disk originated from an earlier used device...etc. ?
Reagentc /info indicated Disk1 has the active Recovery partition(Disk 1, partition 4) - so its a bit more than just a backup.
What does roughly a clone mean?It was never cloned, i.e. it was in use at one time before the
current Disk 0 was added, Windows 10 installed to the machine and then configured using booting software or something similar.
Is the userprofile you logged on to and accessed Powershell and
Administator account or just a Standard account?
It should work out-of-the-box and now unless something was tweaked
preventing admin opening. Did you disable UAC?
When you open Powershell in admin mode, does the title bar say:
Administrator: Windows Powershell
-i.e. for the sake of this discussion and why it matters, you'll need
to figure out why its not working.
On 8/23/2024 7:50 PM, ...winston wrote:
I don't really care why PS is not working. Power Shell is a terribly designed mess. I use it only when necessary, such as for
uninstalling "apps". It's worked fine for that.
On Fri, 8/23/2024 9:15 PM, Newyana2 wrote:
On 8/23/2024 7:50 PM, ...winston wrote:
I don't really care why PS is not working. Power Shell is a terribly
designed mess. I use it only when necessary, such as for
uninstalling "apps". It's worked fine for that.
Powershell has versions. Powershell can also have stuff added to it.
When Winston uses a thing like that, that's likely a default commandlet
that comes with the environment. You can install Powershell 7 over
top of Powershell 5. Then, at runtime, specify which version you want.
powershell /? # No, the option you expected is not there.
$PSVersionTable # Returns PSVersion 5.1.22621.3958 (so I have 5.1 by default)
$PSVersionTable.PSVersion
How you clone or copy things, matters. On GPT disks
there are two GUIDs. One GUID is the "type" of the partition,
such as the pseudo-protected ESP partition (FAT32). But
there is also a number which is a unique identifier for
the partition. If you were to copy the partition in such
a way the copy has the same identifier, then later, Windows
will start putting updates for things in the wrong place.
Newyana2 wrote:
But the question still stands... what has any of this got
to do with running an update? My laptop also has two disks
and dual boots 10/11. I can't imagine that the updater
can't figure out where C drive is. When I tried to run the
updater it spent a few minutes looking in the Registry and
such, getting to 5% complete before failing with error
8007000d and then error 13. The latter is windows error code
for invalid data. I think the former also came up as invalid data.
A lot.
KB 5041580 failures have been reported for:
1. 5034441(WinRE update not being installed)
2. 5034441's SafeOS update not installed
2. Windows Recovery partition not adjacent, right of active Windows partition(where Windows expects it to be)
3. Presence of 3rd party Boot Manager's
4. Dual booting Windows with Linux
5. Inability to update the latest O/S Servicing Stack(necessary for
5034441 and 5041580)
On 8/24/2024 12:27 PM, ...winston wrote:
Newyana2 wrote:Â Â Â Â OK. Thanks for your help, Winston. I do have WinRE
  But the question still stands... what has any of this got
to do with running an update? My laptop also has two disks
and dual boots 10/11. I can't imagine that the updater
can't figure out where C drive is. When I tried to run the
updater it spent a few minutes looking in the Registry and
such, getting to 5% complete before failing with error
8007000d and then error 13. The latter is windows error code
for invalid data. I think the former also came up as invalid data.
A lot.
  KB 5041580 failures have been reported for:
  1. 5034441(WinRE update not being installed)
  2. 5034441's SafeOS update not installed
  2. Windows Recovery partition not adjacent, right of active Windows
partition(where Windows expects it to be)
  3. Presence of 3rd party Boot Manager's
  4. Dual booting Windows with Linux
  5. Inability to update the latest O/S Servicing Stack(necessary for
5034441 and 5041580)
next to C, but I also have a boot manager and Linux installed.
It appears that MS are simply not going to let updates through
anymore unless they have control of the machine and of
Windows.
 When I look up 5034441 I find that it caused lots of errors
and that Ms stopped offering it unless there's plenty of room
in the WinRE partition, though they never said exactly how
much room is needed.
It's hard to believe you know nothing about this problem as both winston
and Paul helped numerous people on this forum get through the issue
several months back and it was a huge couple of threads. I guess you
never figured it would matter to you, since you know everything and have total control and didn't need to hear any of it, so you just ignored it
all.
On 8/24/2024 12:27 PM, ...winston wrote:
Newyana2 wrote:OK. Thanks for your help, Winston. I do have WinRE
But the question still stands... what has any of this got
to do with running an update? My laptop also has two disks
and dual boots 10/11. I can't imagine that the updater
can't figure out where C drive is. When I tried to run the
updater it spent a few minutes looking in the Registry and
such, getting to 5% complete before failing with error
8007000d and then error 13. The latter is windows error code
for invalid data. I think the former also came up as invalid data.
A lot.
KB 5041580 failures have been reported for:
1. 5034441(WinRE update not being installed)
2. 5034441's SafeOS update not installed
2. Windows Recovery partition not adjacent, right of active Windows partition(where Windows expects it to be)
3. Presence of 3rd party Boot Manager's
4. Dual booting Windows with Linux
5. Inability to update the latest O/S Servicing Stack(necessary for 5034441 and 5041580)
next to C, but I also have a boot manager and Linux installed.
It appears that MS are simply not going to let updates through
anymore unless they have control of the machine and of
Windows.
When I look up 5034441 I find that it caused lots of errors
and that Ms stopped offering it unless there's plenty of room
in the WinRE partition, though they never said exactly how
much room is needed.
On 8/24/2024 1:24 PM, sticks wrote:
It's hard to believe you know nothing about this problem as both
winston and Paul helped numerous people on this forum get through the
issue several months back and it was a huge couple of threads. I
guess you never figured it would matter to you, since you know
everything and have total control and didn't need to hear any of it,
so you just ignored it all.
 I don't read all posts and don't recall the discussion.
I've also been unaware of WinRE. I'm also not as young as I used
to be and tend to forget things that are not critical. I seem to
have a lazy teenager in my head who has earbuds in. I send
him down the the file room to retrieve a memory and I never
know whether he'll be back... Sorry if that offends you.
It sounds like you've had fun wallowing in indignation, so I won't
worry about it. :)
  I don't consider it my job to know everything about everything
Windows. Do you have any useful advice?
You seem to imply that
you know all about this issue.
On Sat, 8/24/2024 1:03 PM, Newyana2 wrote:
On 8/24/2024 12:27 PM, ...winston wrote:
Newyana2 wrote:OK. Thanks for your help, Winston. I do have WinRE
But the question still stands... what has any of this got
to do with running an update? My laptop also has two disks
and dual boots 10/11. I can't imagine that the updater
can't figure out where C drive is. When I tried to run the
updater it spent a few minutes looking in the Registry and
such, getting to 5% complete before failing with error
8007000d and then error 13. The latter is windows error code
for invalid data. I think the former also came up as invalid data.
A lot.
KB 5041580 failures have been reported for:
1. 5034441(WinRE update not being installed)
2. 5034441's SafeOS update not installed
2. Windows Recovery partition not adjacent, right of active Windows partition(where Windows expects it to be)
3. Presence of 3rd party Boot Manager's
4. Dual booting Windows with Linux
5. Inability to update the latest O/S Servicing Stack(necessary for 5034441 and 5041580)
next to C, but I also have a boot manager and Linux installed.
It appears that MS are simply not going to let updates through
anymore unless they have control of the machine and of
Windows.
When I look up 5034441 I find that it caused lots of errors
and that Ms stopped offering it unless there's plenty of room
in the WinRE partition, though they never said exactly how
much room is needed.
1GB is enough, except in cases where after "reagentc /disable",
the WinRE.wim was transferred from one folder to another folder
in the 1GB partition. At that point, when '4441 tries to run,
it finds there still isn't enough space, as now there are
two WinRE.wim in the same partition. If you made it 2GB, it
would likely work no matter how poor the conditions were.
On 8/24/2024 1:49 PM, Paul wrote:
On Sat, 8/24/2024 1:03 PM, Newyana2 wrote:
On 8/24/2024 12:27 PM, ...winston wrote:
Newyana2 wrote:OK. Thanks for your help, Winston. I do have WinRE
But the question still stands... what has any of this got
to do with running an update? My laptop also has two disks
and dual boots 10/11. I can't imagine that the updater
can't figure out where C drive is. When I tried to run the
updater it spent a few minutes looking in the Registry and
such, getting to 5% complete before failing with error
8007000d and then error 13. The latter is windows error code
for invalid data. I think the former also came up as invalid data.
A lot.
KB 5041580 failures have been reported for:
1. 5034441(WinRE update not being installed)
2. 5034441's SafeOS update not installed
2. Windows Recovery partition not adjacent, right of active Windows partition(where Windows expects it to be)
3. Presence of 3rd party Boot Manager's
4. Dual booting Windows with Linux
5. Inability to update the latest O/S Servicing Stack(necessary for 5034441 and 5041580)
next to C, but I also have a boot manager and Linux installed.
It appears that MS are simply not going to let updates through
anymore unless they have control of the machine and of
Windows.
When I look up 5034441 I find that it caused lots of errors
and that Ms stopped offering it unless there's plenty of room
in the WinRE partition, though they never said exactly how
much room is needed.
1GB is enough, except in cases where after "reagentc /disable",
the WinRE.wim was transferred from one folder to another folder
in the 1GB partition. At that point, when '4441 tries to run,
it finds there still isn't enough space, as now there are
two WinRE.wim in the same partition. If you made it 2GB, it
would likely work no matter how poor the conditions were.
1GB. Thanks. I didn't find that anywhere. In the meantime, though,
I've moved WinRE to C drive, as per Terabyteunlimited instructions.
So size shouldn't be a problem. The update still fails.
I could also try unplugging the second drive to reduce confusion,
but I'm guessing this really isn't about WinRE. Winston said it
might also complain if there's a Linux system present. It seems to
me that the updater is being nosey... and it could at least tell me
what the problem is. I couldn't find anything decipherable in the log.
On Sat, 8/24/2024 2:25 PM, Newyana2 wrote:
On 8/24/2024 1:49 PM, Paul wrote:
On Sat, 8/24/2024 1:03 PM, Newyana2 wrote:
On 8/24/2024 12:27 PM, ...winston wrote:
Newyana2 wrote:OK. Thanks for your help, Winston. I do have WinRE
But the question still stands... what has any of this got
to do with running an update? My laptop also has two disks
and dual boots 10/11. I can't imagine that the updater
can't figure out where C drive is. When I tried to run the
updater it spent a few minutes looking in the Registry and
such, getting to 5% complete before failing with error
8007000d and then error 13. The latter is windows error code
for invalid data. I think the former also came up as invalid data.
A lot.
KB 5041580 failures have been reported for:
1. 5034441(WinRE update not being installed)
2. 5034441's SafeOS update not installed
2. Windows Recovery partition not adjacent, right of active Windows partition(where Windows expects it to be)
3. Presence of 3rd party Boot Manager's
4. Dual booting Windows with Linux
5. Inability to update the latest O/S Servicing Stack(necessary for 5034441 and 5041580)
next to C, but I also have a boot manager and Linux installed.
It appears that MS are simply not going to let updates through
anymore unless they have control of the machine and of
Windows.
When I look up 5034441 I find that it caused lots of errors
and that Ms stopped offering it unless there's plenty of room
in the WinRE partition, though they never said exactly how
much room is needed.
1GB is enough, except in cases where after "reagentc /disable",
the WinRE.wim was transferred from one folder to another folder
in the 1GB partition. At that point, when '4441 tries to run,
it finds there still isn't enough space, as now there are
two WinRE.wim in the same partition. If you made it 2GB, it
would likely work no matter how poor the conditions were.
1GB. Thanks. I didn't find that anywhere. In the meantime, though,
I've moved WinRE to C drive, as per Terabyteunlimited instructions.
So size shouldn't be a problem. The update still fails.
I could also try unplugging the second drive to reduce confusion,
but I'm guessing this really isn't about WinRE. Winston said it
might also complain if there's a Linux system present. It seems to
me that the updater is being nosey... and it could at least tell me
what the problem is. I couldn't find anything decipherable in the log.
For a year now, Microsoft has been working on changing the root of
trust for Secure Boot. Even if you don't have or use Secure Boot,
the update still makes a nuisance of itself. If it wasn't for that,
I would not have done this research.
I installed Windows 11 on this PC, in Secure Boot mode, just for the
side effect of when the update in question came in, it would change
some detail in the UEFI key store to suit Secure Boot. Then,
I turned off Secure Boot again and unplugged that drive.
July 2024 was supposed to be the month where IT people in industry,
checked for side effects from the change. August would be the month
where the change is mandatory.
From July 26th posting:
To verify that the Secure Boot DB update was successful, open an Admin PowerShell
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’
That should return True, if your machine had been properly patched. I only patch the key store on my machines, for the day I pass and someone else
gets my crappy computer :-) I don't use Secure Boot here. The Microsoft patches, I don't think they even sniff for this, they just "roll forward" over whatever you've got.
When you buy your motherboard from Microcenter and set up your machine, it comes
from the factory with ‘Windows UEFI CA 2011’ , in other words, an older root of trust.
Things like Linux shims, are *signed* by that key. Obviously, if you have Secure Boot
enabled, and you were dual booting, and a new Linux shim had not been installed,
there is going to be "friction" when the 2023 shim meets the 2011 key or
the 2011 shim meets the 2023 key. I don't know what is going on this month, and absolutely none of my test configs were set up to catch the side
effects of this. But to the best of my recollection, without researching
this again, that's the basic idea. Something about messing around in UEFI
key store, and breaking some aspect of Secure Booting in a mixed OS environment.
I may have related the story, about finding a blog style post, where a Linux dev was involved in the re-signing of the shim for his distro. They actually have to *fly* to another city, for the signing. Presumably the setup
is air gapped, you go into a locked room and work the knobs for a
signing. Then jump back on the plane and fly home. Multiple people
had to go through this. Just the coffee and donuts bill is staggering.
*******
'4441 is about WinRE.wim , an alternate boot OS when your regular C: is toast.
Keeping WinRE.wim on a separate partition, may allow C: to be encrypted, and then something can still boot if you (say), reset your TPM.
The other patch sequence (Linux dual boot, Secure Boot problem) is for BlackLotus.
https://en.wikipedia.org/wiki/UEFI
"On March 1, 2023, researchers from ESET Cybersecurity Firm reported
“The first in-the-wild UEFI bootkit bypassing UEFI Secure Boot” named
‘BlackLotus’ in their public analyses findings describing the theory behind
its mechanics exploiting the patches that “do not (and cannot) remove the vulnerability”.
I think that's the one. Microsoft was supposed to work on that over the period of one year, do it slowly, in the hope that humans could keep
up with the side effects, and fewer people would be affected.
I still have an outstanding BIOS update for the Asus motherboard.
Yet another CVE. I did the one for the MSI motherboard. Both are AM4.
MSI have lost the custody chain on their BIOS, so you have to say
a prayer that when you download a BIOS, that MSI actually controls
their own website. Motherboard websites (two of them) were hacked
on the same day, a number of years back, so it's not a given that
a BIOS update is the real deal. Someone can now make an MSI BIOS,
and the existing BIOS will think it is a real item and not a fake.
I can't see much improvement in our sense of security. One of the
real concerns, is the technical staff are having trouble keeping
up and doing the handling properly, for this crap.
On 8/24/2024 9:37 PM, Paul wrote:
On Sat, 8/24/2024 2:25 PM, Newyana2 wrote:
On 8/24/2024 1:49 PM, Paul wrote:
On Sat, 8/24/2024 1:03 PM, Newyana2 wrote:
On 8/24/2024 12:27 PM, ...winston wrote:
Newyana2 wrote:OK. Thanks for your help, Winston. I do have WinRE
But the question still stands... what has any of this got
to do with running an update? My laptop also has two disks
and dual boots 10/11. I can't imagine that the updater
can't figure out where C drive is. When I tried to run the
updater it spent a few minutes looking in the Registry and
such, getting to 5% complete before failing with error
8007000d and then error 13. The latter is windows error code
for invalid data. I think the former also came up as invalid data. >>>>>>
A lot.
KB 5041580 failures have been reported for:
1. 5034441(WinRE update not being installed)
2. 5034441's SafeOS update not installed
2. Windows Recovery partition not adjacent, right of active Windows partition(where Windows expects it to be)
3. Presence of 3rd party Boot Manager's
4. Dual booting Windows with Linux
5. Inability to update the latest O/S Servicing Stack(necessary for 5034441 and 5041580)
next to C, but I also have a boot manager and Linux installed.
It appears that MS are simply not going to let updates through
anymore unless they have control of the machine and of
Windows.
When I look up 5034441 I find that it caused lots of errors
and that Ms stopped offering it unless there's plenty of room
in the WinRE partition, though they never said exactly how
much room is needed.
1GB is enough, except in cases where after "reagentc /disable",
the WinRE.wim was transferred from one folder to another folder
in the 1GB partition. At that point, when '4441 tries to run,
it finds there still isn't enough space, as now there are
two WinRE.wim in the same partition. If you made it 2GB, it
would likely work no matter how poor the conditions were.
1GB. Thanks. I didn't find that anywhere. In the meantime, though,
I've moved WinRE to C drive, as per Terabyteunlimited instructions.
So size shouldn't be a problem. The update still fails.
I could also try unplugging the second drive to reduce confusion,
but I'm guessing this really isn't about WinRE. Winston said it
might also complain if there's a Linux system present. It seems to
me that the updater is being nosey... and it could at least tell me
what the problem is. I couldn't find anything decipherable in the log.
For a year now, Microsoft has been working on changing the root of
trust for Secure Boot. Even if you don't have or use Secure Boot,
the update still makes a nuisance of itself. If it wasn't for that,
I would not have done this research.
I installed Windows 11 on this PC, in Secure Boot mode, just for the
side effect of when the update in question came in, it would change
some detail in the UEFI key store to suit Secure Boot. Then,
I turned off Secure Boot again and unplugged that drive.
July 2024 was supposed to be the month where IT people in industry,
checked for side effects from the change. August would be the month
where the change is mandatory.
From July 26th posting:
To verify that the Secure Boot DB update was successful, open an Admin PowerShell
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’
That should return True, if your machine had been properly patched. I only >> patch the key store on my machines, for the day I pass and someone else
gets my crappy computer :-) I don't use Secure Boot here. The Microsoft
patches, I don't think they even sniff for this, they just "roll forward"
over whatever you've got.
When you buy your motherboard from Microcenter and set up your machine, it comes
from the factory with ‘Windows UEFI CA 2011’ , in other words, an older root of trust.
Things like Linux shims, are *signed* by that key. Obviously, if you have Secure Boot
enabled, and you were dual booting, and a new Linux shim had not been installed,
there is going to be "friction" when the 2023 shim meets the 2011 key or
the 2011 shim meets the 2023 key. I don't know what is going on this month, >> and absolutely none of my test configs were set up to catch the side
effects of this. But to the best of my recollection, without researching
this again, that's the basic idea. Something about messing around in UEFI
key store, and breaking some aspect of Secure Booting in a mixed OS environment.
I may have related the story, about finding a blog style post, where a Linux >> dev was involved in the re-signing of the shim for his distro. They actually >> have to *fly* to another city, for the signing. Presumably the setup
is air gapped, you go into a locked room and work the knobs for a
signing. Then jump back on the plane and fly home. Multiple people
had to go through this. Just the coffee and donuts bill is staggering.
*******
'4441 is about WinRE.wim , an alternate boot OS when your regular C: is toast.
Keeping WinRE.wim on a separate partition, may allow C: to be encrypted, and >> then something can still boot if you (say), reset your TPM.
The other patch sequence (Linux dual boot, Secure Boot problem) is for BlackLotus.
https://en.wikipedia.org/wiki/UEFI
"On March 1, 2023, researchers from ESET Cybersecurity Firm reported
“The first in-the-wild UEFI bootkit bypassing UEFI Secure Boot” named >> ‘BlackLotus’ in their public analyses findings describing the theory behind
its mechanics exploiting the patches that “do not (and cannot) remove the vulnerability”.
I think that's the one. Microsoft was supposed to work on that over the
period of one year, do it slowly, in the hope that humans could keep
up with the side effects, and fewer people would be affected.
I still have an outstanding BIOS update for the Asus motherboard.
Yet another CVE. I did the one for the MSI motherboard. Both are AM4.
MSI have lost the custody chain on their BIOS, so you have to say
a prayer that when you download a BIOS, that MSI actually controls
their own website. Motherboard websites (two of them) were hacked
on the same day, a number of years back, so it's not a given that
a BIOS update is the real deal. Someone can now make an MSI BIOS,
and the existing BIOS will think it is a real item and not a fake.
I can't see much improvement in our sense of security. One of the
real concerns, is the technical staff are having trouble keeping
up and doing the handling properly, for this crap.
Thanks... I think. I find all of this difficult to understand. When I installed Suse Linux it broke my system and I just got a black screen with
a message saying "something has gone very wrong". I researched
it, found that it was a bad Linux shim that the Suse people knew about
but hadn't fixed. But it was curable by disabling secure boot. It's been disabled ever since.
Last week, MS apparently screwed up something, causing the same
message if Linux is installed:
https://arstechnica.com/security/2024/08/a-patch-microsoft-spent-2-years-preparing-is-making-a-mess-for-some-linux-users/
I don't understand enough of UEFI altogether to understand what that
all means. But it sounds like having Linux on my computer may be a complication.
Your PS commandline returns true for me. I just built this computer
around February. Maybe that's it. Though I did run updates since. I did a cumulative security update in April. I still don't see what any of this has to do with cumulative security updates. Shouldn't they just be swapping
out various system files? But maybe this explains why Suse broke secure boot... Beats me. I feel no closer to understanding what *could* have
gone wrong than when I first tried to run this update.
On Sat, 8/24/2024 11:09 PM, Newyana2 wrote:
On 8/24/2024 9:37 PM, Paul wrote:
On Sat, 8/24/2024 2:25 PM, Newyana2 wrote:
On 8/24/2024 1:49 PM, Paul wrote:
On Sat, 8/24/2024 1:03 PM, Newyana2 wrote:
On 8/24/2024 12:27 PM, ...winston wrote:
Newyana2 wrote:
But the question still stands... what has any of this got >>>>>>>> to do with running an update? My laptop also has two disks
and dual boots 10/11. I can't imagine that the updater
can't figure out where C drive is. When I tried to run the
updater it spent a few minutes looking in the Registry and
such, getting to 5% complete before failing with error
8007000d and then error 13. The latter is windows error code
for invalid data. I think the former also came up as invalid data. >>>>>>>
A lot.
KB 5041580 failures have been reported for:
1. 5034441(WinRE update not being installed)
2. 5034441's SafeOS update not installed
2. Windows Recovery partition not adjacent, right of active Windows partition(where Windows expects it to be)
3. Presence of 3rd party Boot Manager's
4. Dual booting Windows with Linux
5. Inability to update the latest O/S Servicing Stack(necessary for 5034441 and 5041580)
Remote debug is very hard. I've done threads with hundreds of
posts, just trying to get some idea where a person is stuck.
And just keeping up with CVE (it's not a fetish of mine actually),
is hard enough for me. I'm not exactly breezing through these things.
One of those WinRE.wim things, I spent *hours* on that. These are like
bar bets, not maintenance problems.
Most of the time I ignore security articles, except when
they have a rating of 10/10 :-)
I don't know why you would run Suse on Secure Boot. I stopped
allowing that sort of thing here, after Ubuntu put up a red screen
at boot time and said "we need to modify your MOK".
was "Oh no you don't" and I turned off the PC power. The BIOS is set
to CSM here. Later, the Linux shim was invented, and there was
less talk of trashing computers and red dialog boxes.
With the Microsoft updates, they will attempt to "correct" Secure Boot issues, even though you have Secure Boot disabled. You will then have
failed updates in your Update History. This is an extra synaptic load
for the user, who doesn't need more of a hobby fixing this stuff.
I don't remember saying "UEFI, oh what a wonderful idea" or "Voting YES"
for it. Yet, here I am, having to deal with the shards.
Anyway, call back, if you are making progress on one of the fixes.
Thanks. I'll post if I find anything useful. But I'm not sure that I
care enough about these updates to keep messing with it and risking
system security. Despite not installing, every time I run the update
it messes with various things. It can't figure out how to update the
system, yet it manages to swap out my ieframe.dll files that I specifically got from 20H2 so that IE will work.
When you deleted the original ieframe.dll from System32, it broke the hardlink
certainly. You copied another version of ieframe.dll into its place.
However, if the system does any sort of maintenance, if it wants it
can check that the WinSxS information matches the in-system information,
and it is allowed to re-link the package-version of the file back
into place. While I don't know how or when such maintenance might occur,
just the long duration of a Cumulative Update suggests it's scanning
the whole thing for juicy details. Windows Updates are managed at the
package level. A Cumulative is "a thousand maintenance commands, in a can".
I don't really know how best to help you on your mission. I've tried
deleting the contents of WinSxS -- the system would not boot. That doesn't appear to be an option (even though it was suggested the system would
survive if you wiped WinSxS, that did not work for me). If manually inserting a file into a semi-protected spot, there could be backlash. Only if the package providing the old version of file was in the tree, could you
expect a hardlinking of the desired version, into place. And just about
any Cumulative that gets loaded later, is going to try to "select"
the package it wants, and not what you want.
If you made a private copy of the IE installation, copied all
dependency DLLs into your private folder, maybe you can coax it
to use your privately-arranged DLL in the private folder. That should
make you independent of maintenance. But that is only going to work,
if the loader is smart enough to check for DLLs in the private folder
first, instead of going straight to System32 or SysWOW64.
For Metro.Apps, there would be much tighter management of content -- there is not much chance of meddling with Metro, just be glad iexplore
is Win32 legacy material.
On 8/25/2024 2:46 PM, Paul wrote:
What surprises me is that it's able to do such detailed housekeeping without being asked, but somehow isn't able to actually do the system
When you deleted the original ieframe.dll from System32, it broke the hardlink
certainly. You copied another version of ieframe.dll into its place.
However, if the system does any sort of maintenance, if it wants it
can check that the WinSxS information matches the in-system information,
and it is allowed to re-link the package-version of the file back
into place. While I don't know how or when such maintenance might occur,
just the long duration of a Cumulative Update suggests it's scanning
the whole thing for juicy details. Windows Updates are managed at the
package level. A Cumulative is "a thousand maintenance commands, in a can". >>
update by swapping out the files that's it's actually supposed to deal with. (Ieframe actually is listed as a file in the update, but it's version 19041.4239.
The version Windows keeps putting back is 3803. The version that fixes
the problem is 610.)
I don't really know how best to help you on your mission. I've tried
deleting the contents of WinSxS -- the system would not boot. That doesn't >> appear to be an option (even though it was suggested the system would
survive if you wiped WinSxS, that did not work for me). If manually inserting
a file into a semi-protected spot, there could be backlash. Only if the
package providing the old version of file was in the tree, could you
expect a hardlinking of the desired version, into place. And just about
any Cumulative that gets loaded later, is going to try to "select"
the package it wants, and not what you want.
That issue is not a problem. When Windows puts back the orignal ieframe
I just take ownership, rename it, then put in the version from 20H2. Not
a big deal. I just thought it was striking that the update was doing that, yet
not succeeding in doing the actual update! Windows hasn't messed with
my changed ieframe files except during attempts to run the update.
If you made a private copy of the IE installation, copied all
dependency DLLs into your private folder, maybe you can coax it
to use your privately-arranged DLL in the private folder. That should
make you independent of maintenance. But that is only going to work,
if the loader is smart enough to check for DLLs in the private folder
first, instead of going straight to System32 or SysWOW64.
Again, you don't seem to understand. This is a known solution to Microsoft killing the IE GUI in Win10 when trying to run IE directly. It works
fine to replace the DLLs with versions from 20H2. I've had them swapped
out for months with no issues. It was only running the update that caused problems... I'm beginning to think this update business is probably not
worth the trouble. I used to just occasionally install cumulative security updates, but they didn't used to be such a big deal. And these days I'm also wary that they might somehow sneal Copilot or worse in there.
The CoPilot icon on the desktop at the moment, makes a remote connection
to their datacenter. The dialog box is likely based on MSEdge code (because
I see CoPilot start MSEdge when you click it). CoPilot can answer questions, and can also run a remote copy of CoPilot Studio, to draw a picture you
ask for (...don't bother).
The future CoPilot is for local execution. Only one processor is certified
at the moment, the Qualcomm ARM processor with NPU. Intel Lunar Lake could be next (a CPU with no Intel silicon inside, made entirely at TSMC). NVidia is working on a library, but NVidia is also likely to just do their own thing too,
to compete with Microsoft. The end result of all this, is practically no one will be able to Opt-in to Local CoPilot. The Remote version, needs "rental" features for Microsoft to cash in, and I doubt most people will be whipping out
any credit card for the features so far.
There is not much chance of being mugged by CoPilot, just yet. CoPilot is
in the basement of the building, playing cards with Clippy.
Newyana2 wrote:
1GB. Thanks. I didn't find that anywhere. In the meantime, though,
I've moved WinRE to C drive, as per Terabyteunlimited instructions.
So size shouldn't be a problem. The update still fails.
Well...
Did you run reagentc /info to determine if it points to the WinRE on the Windows o/s disk and that partition is located after and rt. adjacent to
the C:/ drive Windows partition.
As far as WinRe partition..
- the size does not matter, its the amount of free space in the
partition.
And for that you need to get Powershell functional for the Get_Volume command or use a third party tool(or imaging software) to see the size
*and* free space.
Once done, maybe you updating issues can be better addressed.
On 8/25/2024 11:20 PM, Paul wrote:
The CoPilot icon on the desktop at the moment, makes a remote connection
to their datacenter. The dialog box is likely based on MSEdge code (because >> I see CoPilot start MSEdge when you click it). CoPilot can answer questions, >> and can also run a remote copy of CoPilot Studio, to draw a picture you
ask for (...don't bother).
The future CoPilot is for local execution. Only one processor is certified >> at the moment, the Qualcomm ARM processor with NPU. Intel Lunar Lake could be
next (a CPU with no Intel silicon inside, made entirely at TSMC). NVidia is >> working on a library, but NVidia is also likely to just do their own thing too,
to compete with Microsoft. The end result of all this, is practically no one >> will be able to Opt-in to Local CoPilot. The Remote version, needs "rental" >> features for Microsoft to cash in, and I doubt most people will be whipping out
any credit card for the features so far.
There is not much chance of being mugged by CoPilot, just yet. CoPilot is
in the basement of the building, playing cards with Clippy.
That's a sunny view. :) It reminds me of Rodney Dangerfield in
the final scene of Easy Money. I saw an article about Copilot when they
first came out with it. The author asked it for a picture of a pig celebrating St Patrick's Day and watching TV. It generated 4 apparent
photos, of a pig in a green foil hat, sitting at a party-strewn table,
with a TV on in the background. I could see that being very big.
I suspect the longterm plan will be presenting Windows as the
ultimate rental "experience machine". Something like Copilot will be
the primary interface. Typing will seem old fashioned. And with such
a middleman program, Windows will easily track your thought process
and actions for ad targetting. It'll be like Star Trek gone Disney, by
way of Blade Runner and Apocalypse Now:
"Computer, what have you got for hot sex toys"?
"A selection has been materialized in your cabin, Captain Kirk, and
a suitable negligee has been materialized for your lover. But first, let's just do a little security update... Piece o' cake..."
On Mon, 8/26/2024 8:51 AM, Newyana2 wrote:
On 8/25/2024 11:20 PM, Paul wrote:
The CoPilot icon on the desktop at the moment, makes a remote connection >>> to their datacenter. The dialog box is likely based on MSEdge code (because >>> I see CoPilot start MSEdge when you click it). CoPilot can answer questions,
and can also run a remote copy of CoPilot Studio, to draw a picture you
ask for (...don't bother).
The future CoPilot is for local execution. Only one processor is certified >>> at the moment, the Qualcomm ARM processor with NPU. Intel Lunar Lake could be
next (a CPU with no Intel silicon inside, made entirely at TSMC). NVidia is >>> working on a library, but NVidia is also likely to just do their own thing too,
to compete with Microsoft. The end result of all this, is practically no one
will be able to Opt-in to Local CoPilot. The Remote version, needs "rental" >>> features for Microsoft to cash in, and I doubt most people will be whipping out
any credit card for the features so far.
There is not much chance of being mugged by CoPilot, just yet. CoPilot is >>> in the basement of the building, playing cards with Clippy.
That's a sunny view. :) It reminds me of Rodney Dangerfield in
the final scene of Easy Money. I saw an article about Copilot when they
first came out with it. The author asked it for a picture of a pig
celebrating St Patrick's Day and watching TV. It generated 4 apparent
photos, of a pig in a green foil hat, sitting at a party-strewn table,
with a TV on in the background. I could see that being very big.
I suspect the longterm plan will be presenting Windows as the
ultimate rental "experience machine". Something like Copilot will be
the primary interface. Typing will seem old fashioned. And with such
a middleman program, Windows will easily track your thought process
and actions for ad targetting. It'll be like Star Trek gone Disney, by
way of Blade Runner and Apocalypse Now:
"Computer, what have you got for hot sex toys"?
"A selection has been materialized in your cabin, Captain Kirk, and
a suitable negligee has been materialized for your lover. But first, let's >> just do a little security update... Piece o' cake..."
None of the "art" created with CoPilot Studio (test version not the paid version) produced "acceptable output". Close but not quite there.
When CoPilot answers questions, it's the same thing. CoPilot will ignore keywords on purpose, just to make it easier to craft an answer. And it
will never answer a question with "I don't know". That's because
"text completion" is the base technology, and it can always string
words together to make some kind of answer, even if the answer
serves no purpose.
How much would a person pay in rent for that ? "I don't know" :-)
I think it's good to be able to test this version, just to
see what the spectrum of answers looks like.
Is it worth a $10 billion investment ? Only if it comes with advertisements.
The very first question I asked it, was unbounded. I was careless.
I asked it "what are your capabilities?" I was expecting it to read its manifest and say something like "answer questions and provide web references".
I wanted to know whether it could create art or do arithmetic.
But the thing went nuts, started spewing a lot of text to the screen
(faster than I could read it), it timed out after 15 or 20 seconds,
and it *erased* all of the initial answer.
This is why, if you haven't tried this before, I recommend
drafting your question in Notepad first, then copy and paste
the question into the CoPilot dialog. Staring at your question
for a moment or two, helps you determine whether the
question is too unbounded. While you can try to enter guidance
phrases, that doesn't really help all that much. It doesn't
take a T-square and draw sharp lines bounding the answer,
and it would be a sheer accident, if the answer actually
followed your suggestion or hint. It seems the more text you enter,
the more text it can selectively ignore.
Sorry, I don't see an answer if reagentc /info shows it on the same disk
as C: as enabled and on that same disk(disk and partition number)
Fyi...just because it was moved doesn't mean it will grow.
It's not going to grow until KB5042320 is successfully installed.
- Correction -> I earlier stated KB5034441 which is now deprecated and replaced for Win10 with update KB 5042320 on Aug. 14, 2024
<https://support.microsoft.com/en-us/help/5042320>
That's another
mystery to me with Win10. Control Panel has never been unstable in
any way, but now that the're moving applets to Metro/WinRT, several
times I've had problems with them closing when I try to access them.
I get the blue gear window and then it just closes.
Today, there's no such thing as Metro/RT.
Fyi...the most important update is the Secure Boot update that is inthe interim releas
On 8/27/2024 5:30 AM, ...winston wrote:
Sorry, I don't see an answer if reagentc /info shows it on the same disk as C: as enabled and on that same disk(disk and partition number)
That was in the beginning of this thread, before you sent me
on a wild goose chase for 4441. I don't think WinRE was the
problem, in any case.
diskpart
cmd
k:
dir /ah
cd Recovery
On Tue, 8/27/2024 4:14 PM, Newyana2 wrote:
On 8/27/2024 5:30 AM, ...winston wrote:
Sorry, I don't see an answer if reagentc /info shows it on the same disk as C: as enabled and on that same disk(disk and partition number)
That was in the beginning of this thread, before you sent me
on a wild goose chase for 4441. I don't think WinRE was the
problem, in any case.
Background information:
When '4441 installs, it uses a directory similar to this, to build
the WinRE.wim . There isn't much reason then, to be running a SHA256
on the thing for identification purposes. Only the size is somewhat informative. If '4441 has not been successful yet, this area can have
files, otherwise it might be clean. It uses DISM to build stuff in here.
C:\$WinREAgent\Scratch
diskpart
Microsoft DiskPart version 10.0.22621.1 (I'm using a Win11 tool to look into a Win10 issue...)
Copyright (C) Microsoft Corporation.
On computer: WALLACE
DISKPART> list disk
DISKPART> select disk 0
DISKPART> list partition
Partition 6 Recovery 1025 MB 248 GB # This is a resized Recovery on a GPT disk
DISKPART> select partition 6
DISKPART> assign letter=k
DISKPART> exit
cmd
Microsoft Windows [Version 10.0.22631.4037]
(c) Microsoft Corporation. All rights reserved.
k:
dir /ah
Sun, 03/17/2024 08:26 PM <DIR> Recovery
cd Recovery
K:\Recovery>dir /ah
Sun, 03/17/2024 08:26 PM <DIR> WindowsRE
K:\Recovery>cd WindowsRE
K:\Recovery\WindowsRE>dir /ah
Sun, 03/17/2024 08:26 PM 1,109 ReAgent.xml
Sun, 01/14/2024 01:55 PM 517,679,270 Winre.wim <=== after KB5034441, it's bigger
K:\Recovery\WindowsRE>
*******
To show what rough size the WIM had before '4441, we can look in a DVD.
Windows10-x64-22H2.iso 4,783,996,928 bytes
S:\DVD\Windows10-x64-22H2.iso\sources\install.esd\6\Windows\System32\Recovery\
Sat, 12/07/2019 05:12 AM 837 ReAgent.xml \___ This pair is a PushButtonReset pair
Wed, 09/07/2022 10:57 PM 449,274,568 Winre.wim / suitable for pre '4441 conditions.
It's a bit smaller.
After a reboot, the assignment of the letter K done in diskpart, is removed.
Disk 0 +---------+---------+----------+----------+----------+--------+
| 100MB | W11Home | Recovery | WIN10AMD | Recovery | Shared |
| ESP | C: | 649MB | H: | 1GB K: | S: |
+---------+---------+----------+----------+----------+--------+
\___________________/
Maybe Suse Linux is the
real root of your problem.
On 8/28/2024 2:25 AM, ...winston wrote:
Maybe Suse Linux is the real root of your problem.
Maybe. But then again, how? How could it make sense that
Linux on disk prevents updates, unless it's a blatant MS trick?
Do you know? I assume you don't. Or you think you do, but
assume I couldn't understand.
It would be easier if you just explained what you
know in these cases and didn't offer what you really don't know. Condescension is not tech support. Nor is it helpful to tell
people to "try x and report back", without explaining, as though
no one but you can possibly understand the details.
The WinRE partition was always next to C and accurately
identified. But you wouldn't believe that I was capable of figuring
that out. I then moved winre to C and Windows again accurately
saw it. But the update failed. I then installed the 4441 replacement,
which worked, but the update still failed. Throughout all of that
your response is to assume I did something wrong and that I must
be at fault for the update failure. So you tell me to run reagentc /info again.
Can you understand how condescending this is? It's like going
to a doctor who says you're sick and "take these pills" but offers
no explanation of the sickness or what's in the pills. Who would
take pills without knowing what's in them? Not me. The first thing
I do is to look it up in the PDR. Because I want to understand before
I act. Your condescension is an assumption that people can't
understand and should therefore be prevented from trying.
At the current time, I don't see a positive upside to ignoring
'4441. Why do you think I've been repairing them ? Doing
one is a Bar Bet. Doing three of them (all different challenges
too), implied there is a method to my madness. I want the
Update system to remain working, and I don't want "a surprise
during the xxx Cumulative and then I don't know what happened".
THATS why we fix '4441 issue. No overhang. No excuses.
Not assuming that a successful 5042320 install updated WinRE to thelatest servicepack build.
Most notable - Secure Boot disabled with/without TPM chip
GPO/Registry tweaking, Dual boot
Windows/Linux
- updating Edge to version 128.x';
On 8/31/2024 2:43 AM, ...winston wrote:
Not assuming that a successful 5042320 install updated WinRE to the latest servicepack build.
5042320 is not available as a download. That means that to run it I'd
have to let Microsoft do as they like with my computer by fully enabling automated Windows Update. (Though 5041580 ran fine on my laptop,
which also has Windows Update disabled.)
Most notable - Secure Boot disabled with/without TPM chip
Which should not be an issue.
GPO/Registry tweaking, Dual boot Windows/Linux
Again, irrelevant to updating system files. The patch that breaks Linux supposedly doesn't get applied if Linux dualboot is found.
- updating Edge to version 128.x';
?? I've completely removed Edge. Again, should not be relevant.
What I've realized in all this is that Microsoft are pulling a kind of passive aggressive ploy: Don't let them control your computer?
Then you don't get even security updates. I saw a sample of this
when I first set up this computer. It wouldn't activate until I reinstalled and ran activation pre-tweaking... When I removed Edge I lost the
Internet Options applet, which is just a front-end for Registry
settings... Various brittleness aspects that I had assumed were
poor design but seem to actually be by design.
So I may have to give up on updates. I'm not prepared to let
MS configure my system as they like. On the bright side, the vast
majority of updates are not relevant, coming in two categories:
1) A vulnerability requires physical access to the computer. That's
only relevant for business computers where the people with access
may not be trusted.
2) Vulnerabilities in remote code execution or Microsoft products. The
former are unsafe by design and I don't use either remote functions or
MS products to begin with.
In the list of 5041580 fixes I found none that are relevant for me,
and some that seem to be problematic, such as increased blocking of unapproved drivers. Though it WILL be tough to live without an otion
on my lockscreen to "use my Microsoft account". :)
I understand that you're a party-line Microsoft devotee and will
regard my views as some combination of stubborn and stupid. I post
this because others need to know what they're getting into. MS are
putting the squeeze on anyone who rejects their gradual transition
of Windows to a service running in a kiosk system under their control.
Just a quick status update on some "fun" I had here.
First, a broken '4441 does not affect the ability to complete
2024-08 Cumulative W10 V22H2 x64 KB5041580 ("security Update")
2024-08 Cumulative .NET 3,5,4.8,4.8.1 KB5042352 (".NET for August")
Those both completed. The Test Machine just happened to have the perfect setup for working on your symptoms (some of them at least). I didn't
even remember it still being broken.
Now, when I booted into the Win10 setup, it had not had updates for
some months. When I looked in the update history, it said 5034441 had
tried to install at least three times but failed.
After the two updates above were digested and installed, the Update History got edited, and all mention of 5034441 and its failure, were erased. Clever.
So I notice that KB5042320 is the replacement for '4441 bad behavior.
I gave it plenty of space. It failed. Note that, no matter what
the root cause of the failure, it always returns the bogus "out of space" error result. This is, of course, throwing customers under the bus.
People are pulling their hair out, trying to make "moar space" for
the stupid thing :-) No kids, it's not always the space that is the issue.
I looked in the DISM log, because preparation of WinRE.wim requires
mounting and alterations via C:\$WinREAgent . If the folder has
some amount of content in it, then your setup is in the middle of
trying to install and has not entirely given up. When a SafeOS install
is completed, it reduces the wasted space to less than 1 megabyte in
that folder.
The first time, I could see the DISM log
C:\Windows\Logs\DISM\dism.log
that "the preparation of something is rolling back, scavenging..."
My initial theory, was the PBR (PushButtonReset) WinRE.wim I seeded
it with, was too old (10.0.19041.1). When you screw with KB5042320
KB5042320: Windows Recovery Environment update for Windows 10
Version 21H2 and 22H2: January 9, 2024 <=== "Ha!" on the date reference
then like a prima dona, it won't show up in Windows Update for some hours. You can punch the "check for updates" button all day long, and it won't
come out of hiding. This is one of the Microsoft "we care about carbon deposits"
behaviors. Something about making you wait for hours, as part of
some power trip.
So I eventually had it come back, and try to install again. It failed,
even with a newer PushButtonReset version of Winre.wim. I read the
DISM logfile a second time, and I can see "... compression failed". Hmmm. This is a machine where I turned off "new Windows compression" on purpose,
to make the machine easier to service.
fsutil behavior query disablecompression # This returned "1", which means compression disabled
fsutil behavior set disablecompression 0 # This returns machine to as-installed state, compression available.
After I did that, a reboot, a visit to WU, a press of the "Retry failed update?"
and KB5042320 completed! My shocked face. (Sorry, couldn't help myself. Picture)
On 9/2/2024 1:58 PM, Paul wrote:
Just a quick status update on some "fun" I had here.
First, a broken '4441 does not affect the ability to complete
2024-08 Cumulative W10 V22H2 x64 KB5041580 ("security Update") >> 2024-08 Cumulative .NET 3,5,4.8,4.8.1 KB5042352 (".NET for August") >>
Those both completed. The Test Machine just happened to have the perfect
setup for working on your symptoms (some of them at least). I didn't
even remember it still being broken.
Now, when I booted into the Win10 setup, it had not had updates for
some months. When I looked in the update history, it said 5034441 had
tried to install at least three times but failed.
After the two updates above were digested and installed, the Update History >> got edited, and all mention of 5034441 and its failure, were erased. Clever. >>
So I notice that KB5042320 is the replacement for '4441 bad behavior.
I gave it plenty of space. It failed. Note that, no matter what
the root cause of the failure, it always returns the bogus "out of space"
error result. This is, of course, throwing customers under the bus.
People are pulling their hair out, trying to make "moar space" for
the stupid thing :-) No kids, it's not always the space that is the issue. >>
I looked in the DISM log, because preparation of WinRE.wim requires
mounting and alterations via C:\$WinREAgent . If the folder has
some amount of content in it, then your setup is in the middle of
trying to install and has not entirely given up. When a SafeOS install
is completed, it reduces the wasted space to less than 1 megabyte in
that folder.
The first time, I could see the DISM log
C:\Windows\Logs\DISM\dism.log
that "the preparation of something is rolling back, scavenging..."
My initial theory, was the PBR (PushButtonReset) WinRE.wim I seeded
it with, was too old (10.0.19041.1). When you screw with KB5042320
KB5042320: Windows Recovery Environment update for Windows 10
Version 21H2 and 22H2: January 9, 2024 <=== "Ha!" on the date reference
then like a prima dona, it won't show up in Windows Update for some hours. >> You can punch the "check for updates" button all day long, and it won't
come out of hiding. This is one of the Microsoft "we care about carbon deposits"
behaviors. Something about making you wait for hours, as part of
some power trip.
So I eventually had it come back, and try to install again. It failed,
even with a newer PushButtonReset version of Winre.wim. I read the
DISM logfile a second time, and I can see "... compression failed". Hmmm.
This is a machine where I turned off "new Windows compression" on purpose, >> to make the machine easier to service.
fsutil behavior query disablecompression # This returned "1", which means compression disabled
fsutil behavior set disablecompression 0 # This returns machine to as-installed state, compression available.
After I did that, a reboot, a visit to WU, a press of the "Retry failed update?"
and KB5042320 completed! My shocked face. (Sorry, couldn't help myself. Picture)
And then you ran kb5041580, or no? I decided to skip KB5042320 because at least right now it's not available as a download. I'm wary of letting Windows Update
run unbridled, then ending up with God-knows-what. Copilot and ads for air fresheners? Coupons littering the Desktop for $5 off Office 365? New and
improved spyware? MS clearly have no respect for private property at this point
and will have their way if they can get away with it.
Interestingly, my laptop where 5041580 worked fine has not had 5042320 and the WinRE version is old. It also never had 4441. I've had Windows Update disabled since I bought it a couple of years ago. Yet 1580 worked. A notable difference is
that I have it dual-booting with Win11. There are 2 recovery partitions. 200MB
and 1000MB. I had no role in creating those.
Back on my main machine, I added a Registry setting to tell the 1580 update not to
screw with Linux boot. Did you know about that? Big talk in Linux circles. 1580
is supposed to leave it alone if there's a Linux dual boot, but it wasn't doing so.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT\ "OptOut" dword: 1
I also enlarged the recovery partition to 1.5 GB. So I'm ready to try 5041580
without 5042320. But by this point I'm gun shy. The update that supposedly failed nevertheless fucked with a lot of things when I ran it. My personalization and
system Metro applets refused to open. Ieframe.dll got swapped out and then kept
coming back. Services seemed to have been mucked with. (How did workstation service get started?) So I'm not sure I'll ever run that update. I reverted to a
disk image that I'd made before I ran the update.
Interesting thing about IE: Before I swapped in versions from 20H2 (this is 22H2), trying to run iexplore.exe did nothing, though IE could still be instantiated as a webbrowser control and through COM automation. After I swapped them in I
ended up with a fully functioning IE, which is handy. On the laptop where I ran 5041580 successfully, trying to run iexplore.exe now shows a message window:
"Internet Explorer is no longer supported. Would you like to look for a different
app in the Windows Store."
I find that almost endearing. I rarely use the laptop,
so I haven't made so much effort to clean it up. Since it doesn't matter, I have
a sort of academic interest in seeing the sheer perversion of Microsoft's darkening scam. Maybe I'll let Win11 update at will and see what I get. I can always make a disk image and return it to reasonable civility if I want to.
And then you ran kb5041580, or no? I decided to skip KB5042320 because at least right now it's not available as a download. I'm wary of letting Windows Update
run unbridled, then ending up with God-knows-what. Copilot and ads for air fresheners? Coupons littering the Desktop for $5 off Office 365? New and
improved spyware? MS clearly have no respect for private property at this point
and will have their way if they can get away with it.
Interestingly, my laptop where 5041580 worked fine has not had 5042320 and the WinRE version is old. It also never had 4441. I've had Windows Update disabled since I bought it a couple of years ago. Yet 1580 worked. A notable difference is
that I have it dual-booting with Win11. There are 2 recovery partitions. 200MB
and 1000MB. I had no role in creating those.
Back on my main machine, I added a Registry setting to tell the 1580 update not to
screw with Linux boot. Did you know about that? Big talk in Linux circles. 1580
is supposed to leave it alone if there's a Linux dual boot, but it wasn't doing so.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT\ "OptOut" dword: 1
I also enlarged the recovery partition to 1.5 GB. So I'm ready to try 5041580
without 5042320. But by this point I'm gun shy. The update that supposedly failed nevertheless fucked with a lot of things when I ran it. My personalization and
system Metro applets refused to open. Ieframe.dll got swapped out and then kept
coming back. Services seemed to have been mucked with. (How did workstation service get started?) So I'm not sure I'll ever run that update. I reverted to a
disk image that I'd made before I ran the update.
Interesting thing about IE: Before I swapped in versions from 20H2 (this is 22H2), trying to run iexplore.exe did nothing, though IE could still be instantiated as a webbrowser control and through COM automation. After I swapped them in I
ended up with a fully functioning IE, which is handy. On the laptop where I ran 5041580 successfully, trying to run iexplore.exe now shows a message window:
"Internet Explorer is no longer supported. Would you like to look for a different
app in the Windows Store."
I find that almost endearing. I rarely use the laptop,
so I haven't made so much effort to clean it up. Since it doesn't matter, I have
a sort of academic interest in seeing the sheer perversion of Microsoft's darkening scam. Maybe I'll let Win11 update at will and see what I get. I can always make a disk image and return it to reasonable civility if I want to.
On Mon, 9/2/2024 5:19 PM, Newyana2 wrote:
And then you ran kb5041580, or no? I decided to skip KB5042320 because at >> least right now it's not available as a download. I'm wary of letting Windows Update
run unbridled, then ending up with God-knows-what. Copilot and ads for air fresheners? Coupons littering the Desktop for $5 off Office 365? New and
improved spyware? MS clearly have no respect for private property at this point
and will have their way if they can get away with it.
Interestingly, my laptop where 5041580 worked fine has not had 5042320 and
the WinRE version is old. It also never had 4441. I've had Windows Update disabled since I bought it a couple of years ago. Yet 1580 worked. A notable difference is
that I have it dual-booting with Win11. There are 2 recovery partitions. 200MB
and 1000MB. I had no role in creating those.
Back on my main machine, I added a Registry setting to tell the 1580 update not to
screw with Linux boot. Did you know about that? Big talk in Linux circles. 1580
is supposed to leave it alone if there's a Linux dual boot, but it wasn't doing so.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT\
"OptOut" dword: 1
I also enlarged the recovery partition to 1.5 GB. So I'm ready to try 5041580
without 5042320. But by this point I'm gun shy. The update that supposedly failed nevertheless fucked with a lot of things when I ran it. My personalization and
system Metro applets refused to open. Ieframe.dll got swapped out and then kept
coming back. Services seemed to have been mucked with. (How did workstation >> service get started?) So I'm not sure I'll ever run that update. I reverted to a
disk image that I'd made before I ran the update.
Interesting thing about IE: Before I swapped in versions from 20H2 (this is 22H2), trying to run iexplore.exe did nothing, though IE could still be instantiated as a webbrowser control and through COM automation. After I swapped them in I
ended up with a fully functioning IE, which is handy. On the laptop where I ran 5041580 successfully, trying to run iexplore.exe now shows a message window:
"Internet Explorer is no longer supported. Would you like to look for a different
app in the Windows Store."
I find that almost endearing. I rarely use the laptop,
so I haven't made so much effort to clean it up. Since it doesn't matter, I have
a sort of academic interest in seeing the sheer perversion of Microsoft's
darkening scam. Maybe I'll let Win11 update at will and see what I get. I can
always make a disk image and return it to reasonable civility if I want to. >>
kb5041580 ran before WinRE.wim was repaired. Remember, it took about
eight hours for KB5042320 (WinRE.wim) to show up.
I'm not sure the Secure Boot issue, is all the same materials. There
was a revoked certificate in a previous session (July 2024) and it was claimed
that month was for testing. That is a certificate with "2011?" in it,
which got revoked and a "2023" item took its place.
The SBAT seems to be related to the shim issue on Linux -- but I can't
tell if this is just a different bunch of people using another label for
that area, or what is going on.
I did catch the word "mandatory" with respect to an August 2024 change,
as if the final steps of the year long process were to happen in August.
Does that mean OptOut would be ignored ? should this have blown up in July ? would the OptOut have worked in July but not August ? I don't know.
It's all part of the same breakage. We know that revoking the 2011? certificate should kill the old Linux shims. It's an unknown for me,
whether they can "bracket" or "bridge" between situations by having
two shims.
While you found the BleepingComputer reference to OptOut, the SBAT section does not exist and needs to be created.
There seems to be some material as well, in the OpenSUSE forum.
And in the second thread, someone gets a free lunch, by installing
latest Leap, and a side effect of that is it fixes up the shim
that it uses. Would that cause a previous broken thing to work ? Dunno.
There should be some sharing going on in the folder in the ESP partition,
so a newer Leap side effect should get applied to an older Tumbleweed.
https://forums.opensuse.org/t/insane-secure-boot-issue/174345
https://forums.opensuse.org/t/sbat-self-check-failed-security-policy-violation-after-moving-tumbleweed-to-new-ssd/175855
On the Windows side, the terminology a month ago was like this.
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’
On 9/4/2024 8:58 AM, Paul wrote:
On Mon, 9/2/2024 5:19 PM, Newyana2 wrote:
And then you ran kb5041580, or no? I decided to skip KB5042320 because at
least right now it's not available as a download. I'm wary of letting Windows Update
run unbridled, then ending up with God-knows-what. Copilot and ads for air fresheners? Coupons littering the Desktop for $5 off Office 365? New and
improved spyware? MS clearly have no respect for private property at this point
and will have their way if they can get away with it.
Interestingly, my laptop where 5041580 worked fine has not had 5042320 and
the WinRE version is old. It also never had 4441. I've had Windows Update disabled since I bought it a couple of years ago. Yet 1580 worked. A notable difference is
that I have it dual-booting with Win11. There are 2 recovery partitions. 200MB
and 1000MB. I had no role in creating those.
Back on my main machine, I added a Registry setting to tell the 1580 update not to
screw with Linux boot. Did you know about that? Big talk in Linux circles. 1580
is supposed to leave it alone if there's a Linux dual boot, but it wasn't doing so.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT\
"OptOut" dword: 1
I also enlarged the recovery partition to 1.5 GB. So I'm ready to try 5041580
without 5042320. But by this point I'm gun shy. The update that supposedly failed nevertheless fucked with a lot of things when I ran it. My personalization and
system Metro applets refused to open. Ieframe.dll got swapped out and then kept
coming back. Services seemed to have been mucked with. (How did workstation >>> service get started?) So I'm not sure I'll ever run that update. I reverted to a
disk image that I'd made before I ran the update.
Interesting thing about IE: Before I swapped in versions from 20H2 (this is 22H2), trying to run iexplore.exe did nothing, though IE could still be instantiated as a webbrowser control and through COM automation. After I swapped them in I
ended up with a fully functioning IE, which is handy. On the laptop where I ran 5041580 successfully, trying to run iexplore.exe now shows a message window:
"Internet Explorer is no longer supported. Would you like to look for a different
app in the Windows Store."
I find that almost endearing. I rarely use the laptop,
so I haven't made so much effort to clean it up. Since it doesn't matter, I have
a sort of academic interest in seeing the sheer perversion of Microsoft's >>> darkening scam. Maybe I'll let Win11 update at will and see what I get. I can
always make a disk image and return it to reasonable civility if I want to. >>>
kb5041580 ran before WinRE.wim was repaired. Remember, it took about
eight hours for KB5042320 (WinRE.wim) to show up.
I'm not sure the Secure Boot issue, is all the same materials. There
was a revoked certificate in a previous session (July 2024) and it was claimed
that month was for testing. That is a certificate with "2011?" in it,
which got revoked and a "2023" item took its place.
The SBAT seems to be related to the shim issue on Linux -- but I can't
tell if this is just a different bunch of people using another label for
that area, or what is going on.
I did catch the word "mandatory" with respect to an August 2024 change,
as if the final steps of the year long process were to happen in August.
Does that mean OptOut would be ignored ? should this have blown up in July ? >> would the OptOut have worked in July but not August ? I don't know.
It's all part of the same breakage. We know that revoking the 2011?
certificate should kill the old Linux shims. It's an unknown for me,
whether they can "bracket" or "bridge" between situations by having
two shims.
While you found the BleepingComputer reference to OptOut, the SBAT section >> does not exist and needs to be created.
There seems to be some material as well, in the OpenSUSE forum.
And in the second thread, someone gets a free lunch, by installing
latest Leap, and a side effect of that is it fixes up the shim
that it uses. Would that cause a previous broken thing to work ? Dunno.
There should be some sharing going on in the folder in the ESP partition,
so a newer Leap side effect should get applied to an older Tumbleweed.
https://forums.opensuse.org/t/insane-secure-boot-issue/174345
https://forums.opensuse.org/t/sbat-self-check-failed-security-policy-violation-after-moving-tumbleweed-to-new-ssd/175855
On the Windows side, the terminology a month ago was like this.
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’
You'd think this doesn't need to be so complicated, wouldn't you?
In accord with what you're saying, my laptop didn't have an updated
WinRE and secure boot is disabled. (I don't recall doing that.) Yet 1580 installed just fine.
On my main system I've had secure boot disabled since the Suse install broke it back in the beginning. I haven't kept careful records of all these things, but I have had the sense that MS are cracking down on tweaks,
as I mentioned earlier. For example, my home-built machine wouldn't
activate until I re-installed Windows and did it before all tweaking. Why? There's no credible reason for that, aside from MS trying to maintain
tight control.
Maybe they also don't like home-built machines? I wouldn't
put anything past them at this point. I can't imagine any good reason
for all this complication; nor for the voluminous but mainly useless logs created, which detail thousands of operations but don't say exactly why
the update quit.
And why would an update that failed to install nevertheless swap out
my ieframe DLLs and break settings applets?
But lately I'm having fun with something less critical: How do I change
the background color of selected text to something less dreary? The
default is dirty sky blue: 0 120 215 0r 0078D7. I want the decidedly cheerful 45 150 255 or 2D96FF. I found settings in HKCU\Ccontrol Panel\Colors\Hilight and a similar setting in HKU. There's also a custom theme file. Why doesn't Windows give me access to all those settings, like it used to? And there's
a hotdrag color. And there are old color settings under
HKCU\Control Panel\Desktop.
So far my choice seems to be holding, but it's reverted several times. Where is Windows finding that old color? Where is my custom color for
active title bars stored? What I'm using doesn't match any of the settings I've found. How do MS spend billions of dollars and still fuck up so many things? The default color for selected text... How hard is that to just put that into one damn setting and use it?
Even more strange, the RichEdit50W class window I'm using in my own
text editor is not going with my choice of bright blue sky with white text. It's
showing pale blue with black text. 132 193 255. Where the heck is it
getting that? I can't find it in the Registry or in my custom.theme file. Everything else from Firefox to Notepad to VS6 is using my choice. (If it fails again I intend to put a little EXE in the startup folder to make a call to SetSysColors at each boot.)
So, as you can see, I have a critical emergency here and have to put security updates on the back burner. :)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 361 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 123:18:19 |
| Calls: | 7,716 |
| Files: | 12,861 |
| Messages: | 5,727,955 |
