• KB5034441 WinRE.wim and emergency boot, security fix, failure to instal

    From Paul@21:1/5 to All on Sun Jun 9 23:47:37 2024
    [Note: The following is not a "recipe class" description.
    It's to help you attempt to hack your ReagentC back to working.]

    I managed to get my Optiplex 780 fixed. (MSDOS partitioned disk, no UEFI, legacy BIOS)

    By fiddling with it, I had seemed to break the reagentc
    thing altogether :-) By clever work, it was disabled, and
    I could not find the files... anywhere. Now, we know
    the OS handles those three or so files with care, but the
    situation is, there are a million places it can hide the
    files.

    I discovered a new place. It's in a hidden "Temporary" folder
    next to WindowsRE folder. And that *might* be how a partition
    which is large enough, refuses to take a fix. The Temporary folder,
    is where I found my ~450MB or so "lost" WinRE.wim. That used up
    450MB of my 1GB partition, leaving 550MB for '4441 to use.

    *******

    The interesting part of my adventure, is the solving of the
    "pushing on a piece of string". Previously, I could not figure
    out how humans were supposed to "drive" the process. For example,
    if you reagentc /disable , it would "place the files in a safe
    place". If you checked reagentc /info and all the fields were
    zero, as near as I can figure, that is bad. Enabling reagentc again,
    it is likely consulting the files in the safe place, finding they
    are valid, and using them to copy back to the partition used before.

    But there did not seem to be any way for a human to "prime" the
    process from scratch.

    The first ingredient was this. I could not use this at first,
    because it did not seem to be a complete story.

    REAGENTC.EXE /setreimage /path R:\Recovery\WindowsRE /logpath C:\Temp\Reagent.log

    Where does the drive letter R: come from ? Like this. It's assigned to the hidden NTFS partition, to make it "visible enough" for the command to work.

    Administrator: [Note: This info is for an MSDOS partitioned disk, and legacy boot]

    diskpart
    list disk
    select disk 0
    list partition
    select partition 3 # The hidden partition with type 0x27 and the label "System Reserved", 1GB in size
    assign letter=R # Makes the partition visible for some parts of the OS to see...

    That letter is removed on a reboot, so you don't have to worry about
    it being a permanent (and incorrect) fixture.

    Where the pieces fell together, is I found an article on Tenforums,
    which said to copy the WinRE.wim and ReAgent.xml from the Windows10
    installer DVD. In "sources", is the large (3.5GB+) install.wim file.
    Opening that in 7ZIP, folder 6 is the Windows 10 Pro folder. And
    there is a 450MB WinRE.wim in there.

    The magic part about the ReAgent.xml file next to it, is the
    file is armed with PBR ("PushButtonReset"). That means, when our
    mystery software reads that file, it says "Oh, you're new here, and
    you want me to bless your WinRE.wim ?".

    So on drive R:, I have the "usual things"

    R:
    Recovery
    WindowsRE
    WinRE.wim # from DVD
    ReAgent.xml # PushButtonReset version of the control file, also from DVD.

    Now, if you execute the command, and then check the log

    ( reagentc /disable )

    REAGENTC.EXE /setreimage /path R:\Recovery\WindowsRE /logpath C:\Temp\Reagent.log

    The Reagent.log file says "staged" as a result of the command. At this point, nothing has been blessed. The OS simply makes a note of the materials.

    However, when you do

    reagentc /enable

    now the staged materials are used to update the BCD file with the
    identifier of the new WinRE.wim setup, including the physical address
    it likes instead of the letter R: . It was never going to like the
    letter R:, but by using R:, the software translates this for us,
    into a partition number and so on.

    Some unclear issues, are how the folders are supposed to be set up.
    In Powershell, you type "cmd" to switch to Command Prompt, as only
    that shell recognizes the commands properly.

    R:
    Recovery
    WindowsRE <=== You've put the WinRE.wim and the Reagent.xml in here already,
    now you can "shut the door on them"

    cd /d R:
    md Recovery
    cd Recovery
    md WindowsRE
    attrib -h -s WindowsRE # Make the folder System and Hidden, at the same time
    cd ..
    attrib -h -s Recovery #

    Normally, when you do

    dir

    hidden things are not listed.
    If you do

    dir /ah

    then the hidden items should be listed.

    So now you can see what I was doing, to set up my disk drive,
    and put a brand new, empty 1GB, 0x27 partition, on the machine.

    To make the partition in the first place, there's likely some way
    to do it entirely with "diskpart". But what I did was:

    disk management, create the partition, format it NTFS. Now
    the partition is 0x07 type. Using PTEDIT32.exe as administrator,
    you can change the partition field by typing 0x27 over top. Save.
    On the next reboot, the partition is hidden NTFS type. And then,
    using the "letter R: " recipe, you can make stuff in it, change
    attributes and so on.

    [Picture]

    https://i.postimg.cc/Fz6X4Ljh/W10-DELL-reagentc-legacy-boot.gif

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From T i m@21:1/5 to Paul on Sun Jul 14 19:29:59 2024
    On 10/06/2024 04:47, Paul wrote:
    [Note: The following is not a "recipe class" description.
    It's to help you attempt to hack your ReagentC back to working.]

    I managed to get my Optiplex 780 fixed. (MSDOS partitioned disk, no UEFI, legacy BIOS)

    By fiddling with it, I had seemed to break the reagentc
    thing altogether :-) By clever work, it was disabled, and
    I could not find the files... anywhere. Now, we know
    the OS handles those three or so files with care, but the
    situation is, there are a million places it can hide the
    files.

    I discovered a new place. It's in a hidden "Temporary" folder
    next to WindowsRE folder. And that *might* be how a partition
    which is large enough, refuses to take a fix. The Temporary folder,
    is where I found my ~450MB or so "lost" WinRE.wim. That used up
    450MB of my 1GB partition, leaving 550MB for '4441 to use.

    *******

    <snip>

    Good work!

    Firstly, I am in a similar position in that I can't apply that update
    but I'm not sure if it (WinRE) was ever working in the first place so
    can't get it 'back to working' as such?

    Secondly I'm not sure how bothered I am if I don't have it (WinRE), but
    might be more bothered that it seems to block further updates?

    I don't believe I have a RE partition (so can't make it bigger) so is
    that just MS f'ing it up or is there an actual issue on my PC?

    FWIW I built the PC ages ago and so it's a clean but mature install of
    W10 etc (not filled with cruft).

    C:\WINDOWS\system32>reagentc /info
    Windows Recovery Environment (Windows RE) and system reset configuration Information:

    Windows RE status: Enabled
    Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition1\Recovery\WindowsRE
    Boot Configuration Data (BCD) identifier: 0a336b79-8dae-11ec-af84-fa9f0459504e
    Recovery image location:
    Recovery image index: 0
    Custom image location:
    Custom image index: 0

    REAGENTC.EXE: Operation Successful.


    DISKPART> list disk

    Disk ### Status Size Free Dyn Gpt
    -------- ------------- ------- ------- --- ---
    Disk 0 Online 931 GB 0 B


    DISKPART> list partition

    Partition ### Type Size Offset
    ------------- ---------------- ------- -------
    Partition 1 Primary 579 MB 1024 KB
    Partition 2 Primary 900 GB 580 MB
    Partition 3 Primary 30 GB 900 GB


    Cheers, T i m

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bill Bradshaw@21:1/5 to T i m on Mon Jul 15 08:23:49 2024
    T i m wrote:
    On 10/06/2024 04:47, Paul wrote:
    [Note: The following is not a "recipe class" description.
    It's to help you attempt to hack your ReagentC back to
    working.] I managed to get my Optiplex 780 fixed. (MSDOS partitioned
    disk, no
    UEFI, legacy BIOS) By fiddling with it, I had seemed to break the
    reagentc
    thing altogether :-) By clever work, it was disabled, and
    I could not find the files... anywhere. Now, we know
    the OS handles those three or so files with care, but the
    situation is, there are a million places it can hide the
    files.

    I discovered a new place. It's in a hidden "Temporary" folder
    next to WindowsRE folder. And that *might* be how a partition
    which is large enough, refuses to take a fix. The Temporary folder,
    is where I found my ~450MB or so "lost" WinRE.wim. That used up
    450MB of my 1GB partition, leaving 550MB for '4441 to use.

    *******

    <snip>

    Good work!

    Firstly, I am in a similar position in that I can't apply that update
    but I'm not sure if it (WinRE) was ever working in the first place so
    can't get it 'back to working' as such?

    Secondly I'm not sure how bothered I am if I don't have it (WinRE),
    but might be more bothered that it seems to block further updates?

    I don't believe I have a RE partition (so can't make it bigger) so is
    that just MS f'ing it up or is there an actual issue on my PC?

    FWIW I built the PC ages ago and so it's a clean but mature install of
    W10 etc (not filled with cruft).

    C:\WINDOWS\system32>reagentc /info
    Windows Recovery Environment (Windows RE) and system reset
    configuration Information:

    Windows RE status: Enabled
    Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition1\Recovery\WindowsRE
    Boot Configuration Data (BCD) identifier: 0a336b79-8dae-11ec-af84-fa9f0459504e
    Recovery image location:
    Recovery image index: 0
    Custom image location:
    Custom image index: 0

    REAGENTC.EXE: Operation Successful.


    DISKPART> list disk

    Disk ### Status Size Free Dyn Gpt
    -------- ------------- ------- ------- --- ---
    Disk 0 Online 931 GB 0 B


    DISKPART> list partition

    Partition ### Type Size Offset
    ------------- ---------------- ------- -------
    Partition 1 Primary 579 MB 1024 KB
    Partition 2 Primary 900 GB 580 MB
    Partition 3 Primary 30 GB 900 GB


    Cheers, T i m

    When I do this I have a partition that is listed at type "recovery."
    --
    <Bill>

    Brought to you from Anchorage, Alaska

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From T i m@21:1/5 to Bill Bradshaw on Mon Jul 15 18:32:02 2024
    On 15/07/2024 17:23, Bill Bradshaw wrote:

    <snip>

    DISKPART> list partition

    Partition ### Type Size Offset
    ------------- ---------------- ------- -------
    Partition 1 Primary 579 MB 1024 KB
    Partition 2 Primary 900 GB 580 MB
    Partition 3 Primary 30 GB 900 GB



    When I do this I have a partition that is listed at type "recovery."

    Yeah, that's the sort of thing I would have expected as well but I think
    I read on the Interwebs that even if you don't have such a partition,
    you can still have the recovery function but from within the system drive?

    FWIW I've hidden the update as I don't need it anyway. ;-)

    Cheers, T i m

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to T i m on Mon Jul 15 14:07:28 2024
    On 7/15/2024 1:32 PM, T i m wrote:
    On 15/07/2024 17:23, Bill Bradshaw wrote:

    <snip>

    DISKPART> list partition

       Partition ###  Type              Size     Offset
       -------------  ----------------  -------  -------
       Partition 1    Primary            579 MB  1024 KB
       Partition 2    Primary            900 GB   580 MB
       Partition 3    Primary             30 GB   900 GB



    When I do this I have a partition that is listed at type "recovery."

    Yeah, that's the sort of thing I would have expected as well but I think I read on the Interwebs that even if you don't have such a partition, you can still have the recovery function but from within the system drive?

    FWIW I've hidden the update as I don't need it anyway. ;-)

    Cheers, T i m

    Having a WinRE.wim stored on a separate partition, allows
    the machine to minimally boot when C: cannot be mounted.

    Say that you are on Win10 Pro and have engaged Bitlocker
    to protect C: . There might be a scenario where you
    need to use your Recovery info to get the Bitlocker contents
    visible again.

    The only reason I'm bothering with this, is for the
    technical challenge. I'm not too concerned about having
    non-optimal configs and not all my recovery procedures
    can work when I need them. This is a personal preference
    thing.

    Just be aware that, Microsoft has removed some driver materials
    from catalog.update.microsoft.com . If you clean install the
    OS today, you'll find the process is not as "smooth" as it once was.
    For example, the X79 chipset driver (once upon a time was in
    catalog.update and could fix Device Manager display properly),
    I don't think that is available any more. When I needed to get
    my 7900GT video card working (on the "test machine used for
    archaic test"), I did not get a driver for that either,
    and I had to get it from the NVidia site (as a WDDM 1.0 driver,
    ancient). And it did not work properly in 19045.xxx either.
    I've taken the machine apart and back into the junk room it went.
    Pulling the CMOS battery out of a motherboard, means the machines
    fare is sealed...

    And PCI Express cards, only work with one standard level before.
    Apparently. A PCI Express Rev3 video card, is supposed to work
    in a Rev2 or Rev3 slot. Well, the 7900GT is a Rev1 card and
    the computer slot was a Rev1.0a slot, and I have absolutely
    no matching goods to make a second working combo. Having
    a Rev3 card in hand... does nothing for me. Cannot reuse
    old computer, unless the video card is the right vintage.
    Cannot run an OS with an old card, if it behaves flaky.

    the only question is, why did Microsoft excrete '4441 into the
    user domain in the first place ??? Surely they knew this would
    happen. Surely. Like Tuesday follows March.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to T i m on Mon Jul 15 16:01:20 2024
    On 7/15/2024 1:32 PM, T i m wrote:
    On 15/07/2024 17:23, Bill Bradshaw wrote:

    <snip>

    DISKPART> list partition

       Partition ###  Type              Size     Offset
       -------------  ----------------  -------  -------
       Partition 1    Primary            579 MB  1024 KB
       Partition 2    Primary            900 GB   580 MB
       Partition 3    Primary             30 GB   900 GB



    When I do this I have a partition that is listed at type "recovery."

    Yeah, that's the sort of thing I would have expected as well but I think I read on the Interwebs that even if you don't have such a partition, you can still have the recovery function but from within the system drive?

    FWIW I've hidden the update as I don't need it anyway. ;-)

    Cheers, T i m

    The good news is, you can have your Recovery Partition
    where ever you want, with the PBR.

    What I can't predict, is how many hours of experiments it will take.

    Just remember to "reagentc /disable" before doing the step.
    So the original can't compete with the PBR.

    Paul

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