• Wondering how this disk got all this

    From sticks@21:1/5 to All on Tue Feb 6 10:41:08 2024
    This was the laptop that was taking so long to boot up (~20 minutes).
    I'll do another thread on why it was taking so long to boot up.

    <https://www.dropbox.com/scl/fi/uiiez3086ili1myaucp55/Drive.jpg?rlkey=ji0soyglau9x9ija9xrwv00m3&dl=0>

    <https://www.dropbox.com/scl/fi/bxs3kc56chc4ixc1hhsn6/Drive2.jpg?rlkey=w5nd00f4d7olya6y6v0cqeviv&dl=0>

    Laptop came with Windows 8 from Asus, which is what I believe created
    the 20.01 GB "Restore" partition.

    It has been a while, but I believe I created partition 6 (D:) because
    they were not paying attention to where they were placing their working
    files, and for some stupid reason I thought this would get them in the
    habit of knowing where their files were located. As it only had 150 MB
    in it, obviously that didn't work.

    About 1.5 years back, I updated this laptop to Windows 10. The Drive2
    link above shows partition 5 also as a "Recovery" partition. Both
    partitions 2 and 5 seem to have enough space to be able to do the
    ReAgent KB5034441 update, though one is before the C drive and one is
    between the C and D drives. But it would not install the update and fails.

    My question is how did partition 5 get in there in-between the two
    drives? I'm wondering why diskpart claims it is a recovery partition,
    though it also calls partition 7 a recovery partition when disk
    management calls it a "Restore" partition. What the heck is partition 5?



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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Slootweg@21:1/5 to sticks on Tue Feb 6 18:23:22 2024
    sticks <wolverine01@charter.net> wrote:
    This was the laptop that was taking so long to boot up (~20 minutes).
    I'll do another thread on why it was taking so long to boot up.

    <https://www.dropbox.com/scl/fi/uiiez3086ili1myaucp55/Drive.jpg?rlkey=ji0soyglau9x9ija9xrwv00m3&dl=0>

    <https://www.dropbox.com/scl/fi/bxs3kc56chc4ixc1hhsn6/Drive2.jpg?rlkey=w5nd00f4d7olya6y6v0cqeviv&dl=0>

    Laptop came with Windows 8 from Asus, which is what I believe created
    the 20.01 GB "Restore" partition.

    Yes, 'Restore', not 'Recovery'. The 'Restore' partition (7) probably
    contains the files needed to restore the system to 'as shipped from
    factory' condition, i.e. not just plain Windows 8, but also any and all 'added-value' Asus stuff.

    It looks similar to my HP laptop which also came with Windows 8 and
    has a 14.94GB partition, also at the end of the disk, which, in order to
    add to the confusion, is called 'RECOVERY'. :-)

    Sorry, can't help with the rest, but I'm sure Winston can explain the mysterious 'Recovery' partition 5.

    It has been a while, but I believe I created partition 6 (D:) because
    they were not paying attention to where they were placing their working files, and for some stupid reason I thought this would get them in the
    habit of knowing where their files were located. As it only had 150 MB
    in it, obviously that didn't work.

    About 1.5 years back, I updated this laptop to Windows 10. The Drive2
    link above shows partition 5 also as a "Recovery" partition. Both
    partitions 2 and 5 seem to have enough space to be able to do the
    ReAgent KB5034441 update, though one is before the C drive and one is
    between the C and D drives. But it would not install the update and fails.

    My question is how did partition 5 get in there in-between the two
    drives? I'm wondering why diskpart claims it is a recovery partition,
    though it also calls partition 7 a recovery partition when disk
    management calls it a "Restore" partition. What the heck is partition 5?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to sticks on Tue Feb 6 18:04:02 2024
    On 2/6/2024 11:41 AM, sticks wrote:
    This was the laptop that was taking so long to boot up (~20 minutes). I'll do another thread on why it was taking so long to boot up.

    <https://www.dropbox.com/scl/fi/uiiez3086ili1myaucp55/Drive.jpg?rlkey=ji0soyglau9x9ija9xrwv00m3&dl=0>

    <https://www.dropbox.com/scl/fi/bxs3kc56chc4ixc1hhsn6/Drive2.jpg?rlkey=w5nd00f4d7olya6y6v0cqeviv&dl=0>

    Laptop came with Windows 8 from Asus, which is what I believe created the 20.01 GB "Restore" partition.

    It has been a while, but I believe I created partition 6 (D:) because they were not paying attention to where they were placing their working files, and for some stupid reason I thought this would get them in the habit of knowing where their files were
    located.  As it only had 150 MB in it, obviously that didn't work.

    About 1.5 years back, I updated this laptop to Windows 10.  The Drive2 link above shows partition 5 also as a "Recovery" partition.  Both partitions 2 and 5 seem to have enough space to be able to do the ReAgent KB5034441 update, though one is before
    the C drive and one is between the C and D drives. But it would not install the update and fails.

    My question is how did partition 5 get in there in-between the two drives?  I'm wondering why diskpart claims it is a recovery partition, though it also calls partition 7 a recovery partition when disk management calls it a "Restore" partition.  What
    the heck is partition 5?




    1 2 3 4 5 6 7 -------------------------+---------+-----+---------+---------+-----+---------------------------+
    ESP System Partition |System |MSR |C: |System |D: |Restore (Could be W7) |
    (Microsoft folder, BCD) |Reserved |NoFS |Partition|Reserved |Data |12GB |
    |WinRE.wim|128MB| |WinRE.wim| |Traditional OS restoration |
    -------------------------+---------+-----+---------+---------+-----+---------------------------+

    reagentc /info # in an Administrator window

    The partition number in reagentc /info, should point to the one
    on the right of the C: partition. "Partition 5" is the real one.
    "Partition 2" is no longer in usage. Partition 5 was caused by
    an OS Upgrade. Partition 2 was invented, before they knew what
    they were doing.

    Any time that metadata uses partition numbers, it is not a
    good idea to be deleting partitions "to the left" of the
    affected partition. At least, unless you know how
    to repair the damage. 5 is using partition number for reference,
    so do not delete 2 (unless you are ready to do reagentc repair procedure).

    We don't know what MSR is for. If it changed size, then we
    would know. I have not seen it behave in a dynamic fashion.
    There is no file system on MicroSoftReserved partition. It is
    a partition type with a partition GUID assignment. Could it be
    crypto ? Is it garbage ? Dunno.

    Many things in OSes, use BLKIDs, or they use metadata which
    does not depend on the partition number, and this makes
    them more resistant to damage. But even in the best designed
    OSes, there will always be that "one evil feature" that
    continues to cling to a partition number :-) And that is the
    feature that breaks when you are too ambitious while cleaning house.

    If you, in diskpart.exe, "assign letter=K" to a partition,
    that allows hidden partitions to be listed. The alternative,
    is to use TestDisk, but that is an acquired taste as a tool.
    Note that assigning a letter in this way, is not honored by
    all the software. It has limited scope.

    diskpart
    list disks
    select disk 0
    list partitions
    select partition 5
    assign letter=K
    exit

    K:
    dir
    cd directoryname
    dir
    ... # Descend and look around.

    [Reboot, to clear the K: assignment and be shed of it.]

    There is nothing special about K: . It's just my favorite
    non-colliding drive letter :-)

    GPT partitions, have two "long number strings". One
    is a label of sorts (like enumeration or a counting number or a BLKID).
    The other is the "partition type". In legacy, 0x07 is NTFS
    partition type. Well, they have a long series of digits
    to represent that in Microsoft GPT-land. Linux has a shorthand.
    0x0700 means "I am that long GUID that Microsoft uses, for NTFS".
    The number 0x0700 is not physically realized on the media. It
    is a "comfort food" for the user, so they don't have to type shit :-)

    There are 64KB tables at both ends of the disk. The table has room
    for 128 entries. Only the first seven slots in the table, are
    used in your two tables. The rest of the table is filled with zeros.
    (This can make it difficult to figure out where the table ends.)
    With a hex editor, you can now go look for it :-)

    If you elevate this to Administrator, it can be used as a disk editor.
    That's how I have viewed the tables in this example. At the moment,
    I just view the contents as "garbage", as I'm too lazy to become
    familiar with editing the stuff. I suspect the table could be
    protected with checksums, which is why you can't be careless in there.

    https://mh-nexus.de/en/hxd/

    Some tools do not clear the tables properly. You cannot "dd" a GPT
    between two different sized disks. Why ? The secondary table
    is placed at the wrong offset if you do that. The secondary table
    is supposed to "always be right down near the end". So if it was
    "this far" from the end of one drive, you would move it, with dd,
    to be "this far" from the end of your newer/bigger drive. If you
    use Macrium Backup/Restore, it knows the rules for handing
    the secondary table.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to Paul on Wed Feb 7 10:06:59 2024
    On 2/6/2024 5:04 PM, Paul wrote:
    On 2/6/2024 11:41 AM, sticks wrote:
    This was the laptop that was taking so long to boot up (~20 minutes). I'll do another thread on why it was taking so long to boot up.

    <https://www.dropbox.com/scl/fi/uiiez3086ili1myaucp55/Drive.jpg?rlkey=ji0soyglau9x9ija9xrwv00m3&dl=0>

    <https://www.dropbox.com/scl/fi/bxs3kc56chc4ixc1hhsn6/Drive2.jpg?rlkey=w5nd00f4d7olya6y6v0cqeviv&dl=0>

    Laptop came with Windows 8 from Asus, which is what I believe created the 20.01 GB "Restore" partition.

    It has been a while, but I believe I created partition 6 (D:) because they were not paying attention to where they were placing their working files, and for some stupid reason I thought this would get them in the habit of knowing where their files
    were located.  As it only had 150 MB in it, obviously that didn't work.

    About 1.5 years back, I updated this laptop to Windows 10.  The Drive2 link above shows partition 5 also as a "Recovery" partition.  Both partitions 2 and 5 seem to have enough space to be able to do the ReAgent KB5034441 update, though one is
    before the C drive and one is between the C and D drives. But it would not install the update and fails.

    My question is how did partition 5 get in there in-between the two drives?  I'm wondering why diskpart claims it is a recovery partition, though it also calls partition 7 a recovery partition when disk management calls it a "Restore" partition. 
    What the heck is partition 5?




    1 2 3 4 5 6 7 -------------------------+---------+-----+---------+---------+-----+---------------------------+
    ESP System Partition |System |MSR |C: |System |D: |Restore (Could be W7) |
    (Microsoft folder, BCD) |Reserved |NoFS |Partition|Reserved |Data |12GB |
    |WinRE.wim|128MB| |WinRE.wim| |Traditional OS restoration |
    -------------------------+---------+-----+---------+---------+-----+---------------------------+

    reagentc /info # in an Administrator window

    The partition number in reagentc /info, should point to the one
    on the right of the C: partition. "Partition 5" is the real one.
    "Partition 2" is no longer in usage. Partition 5 was caused by
    an OS Upgrade. Partition 2 was invented, before they knew what
    they were doing.

    Yes, partition 5 was where reagentc /info pointed.

    Any time that metadata uses partition numbers, it is not a
    good idea to be deleting partitions "to the left" of the
    affected partition. At least, unless you know how
    to repair the damage. 5 is using partition number for reference,
    so do not delete 2 (unless you are ready to do reagentc repair procedure).

    I have done this repair procedure many times now, so I ultimately
    decided to delete the partitions 2, 5 and 7. I then made partition 4
    big, and shrunk it by 1500 MB and created the WinRE partition in the
    right spot and reagentc /info showed it was all there and enabled.
    Looked like this when done.

    <https://www.dropbox.com/scl/fi/5njsciy0k0w7cyxml1x9m/Drive3.jpg?rlkey=xy5ph92r59cdezpn628jwoc7z&dl=0>

    I haven't actually tried yet to see on this system if the recovery agent actually works. I probably should do that since I still cannot get this
    to do the 4441 update for some reason. There is no BitLocker in use on
    this machine, so I really don't care if it gets updated if the recovery environment still works. I also know I can just reimage if it gets
    screwed up. It will just try and fail every time it does updates.
    Is there a way to tell MS Update not to try this one again?

    ---snip---

    If you, in diskpart.exe, "assign letter=K" to a partition,
    that allows hidden partitions to be listed. The alternative,
    is to use TestDisk, but that is an acquired taste as a tool.
    Note that assigning a letter in this way, is not honored by
    all the software. It has limited scope.

    diskpart
    list disks
    select disk 0
    list partitions
    select partition 5
    assign letter=K
    exit

    K:
    dir
    cd directoryname
    dir
    ... # Descend and look around.

    [Reboot, to clear the K: assignment and be shed of it.]



    I think you're saying that if I do above and assign partition 2 a letter
    it will show up here too?

    <https://www.dropbox.com/scl/fi/yb44qp98u0keqooocu36q/Drive4.jpg?rlkey=olvo7fzvxwvbyjf5l4arakvc0&dl=0>

    ---snip---

    As usual, very interesting stuff for me. Thanks!


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to All on Wed Feb 7 10:19:22 2024
    On 2/6/2024 6:02 PM, ...w¡ñ§±¤ñ wrote:
    sticks wrote on 2/6/24 9:41 AM:
    This was the laptop that was taking so long to boot up (~20 minutes).
    I'll do another thread on why it was taking so long to boot up.

    <https://www.dropbox.com/scl/fi/uiiez3086ili1myaucp55/Drive.jpg?rlkey=ji0soyglau9x9ija9xrwv00m3&dl=0>

    <https://www.dropbox.com/scl/fi/bxs3kc56chc4ixc1hhsn6/Drive2.jpg?rlkey=w5nd00f4d7olya6y6v0cqeviv&dl=0>

    Laptop came with Windows 8 from Asus, which is what I believe created
    the 20.01 GB "Restore" partition.

    It has been a while, but I believe I created partition 6 (D:) because
    they were not paying attention to where they were placing their
    working files, and for some stupid reason I thought this would get
    them in the habit of knowing where their files were located.  As it
    only had 150 MB in it, obviously that didn't work.

    About 1.5 years back, I updated this laptop to Windows 10.  The Drive2
    link above shows partition 5 also as a "Recovery" partition.  Both
    partitions 2 and 5 seem to have enough space to be able to do the
    ReAgent KB5034441 update, though one is before the C drive and one is
    between the C and D drives. But it would not install the update and
    fails.

    My question is how did partition 5 get in there in-between the two
    drives?  I'm wondering why diskpart claims it is a recovery partition,
    though it also calls partition 7 a recovery partition when disk
    management calls it a "Restore" partition.  What the heck is partition 5? >>



    If this is the same laptop mentioned in the 'Revert to Windows 8' post/thread...please try to avoiding creating another thread for the
    same device and most likely the future direction(your intent) for the
    same device.  i.e. don't start another thread about this device, use
    **this exact same thread'.

    That is a different thread and the OP is Knuttle.

    ---snip---

    Partition 5
     - Windows 10 created Recovery partition(i.e. created when it was
    upgraded to Win10 or later in the correct location(after the Windows partition and by shrinking the Windows partition to make space and place
    the partition after the Windows partition)
    Partition 7

    ---snip---


    I answered much of this in my response to Paul, but you have educated me
    now on my question as to how partition 5 got in-between the two drives.
    It's funny how the brain works. I knew that is exactly what MS does, as
    I have done it over a dozen times myself. For some reason, I assumed it
    would go after both of the C and D drives, and it didn't occur to me the process would ignore D and do what it is supposed to and place it
    directly after C.

    I'm going to try and see if I am missing something like this in my
    thinking since it still won't update 4441 even though it is enabled and
    is positioned after C now like this

    <https://www.dropbox.com/scl/fi/5njsciy0k0w7cyxml1x9m/Drive3.jpg?rlkey=xy5ph92r59cdezpn628jwoc7z&dl=0>


    ---snip---

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to All on Wed Feb 7 14:58:31 2024
    On 2/7/2024 11:57 AM, ...w¡ñ§±¤ñ wrote:


    I'm going to try and see if I am missing something like this in my
    thinking since it still won't update 4441 even though it is enabled
    and is positioned after C now like this

    <https://www.dropbox.com/scl/fi/5njsciy0k0w7cyxml1x9m/Drive3.jpg?rlkey=xy5ph92r59cdezpn628jwoc7z&dl=0>

    Fyi...WinRE partition being enabled doesn't necessarily guarantee KB 5034441(and its SafeOS update KB5034232) will be installed.

    Meaning it won't try, or it can still fail? Because it definitely keeps
    trying to install it.


    The status of the o/s version, build and the version/build of the SSU(Servicing Stack Update) is also a controlling factor.

    What is the current installed version and build of Windows 10?

    Windows 10 Home Edition
    Version 22H2
    Build 19045.3996

    I tried finding the installed servicing stack build, but that doesn't
    seem so simple. Is there a specific KB for this build I should check to
    see if it is installed?


    The partition order shown in your pic is the correct order.
     - post re-partitioning, did you re-run reagentc /info to determine the recovery partition status(partition number and enabled)?

    Yes, it is enabled. I am going to try /boottore and see if I can get in
    there.


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to sticks on Wed Feb 7 20:14:27 2024
    On 2/7/2024 11:06 AM, sticks wrote:
    On 2/6/2024 5:04 PM, Paul wrote:
    On 2/6/2024 11:41 AM, sticks wrote:
    This was the laptop that was taking so long to boot up (~20 minutes). I'll do another thread on why it was taking so long to boot up.

    <https://www.dropbox.com/scl/fi/uiiez3086ili1myaucp55/Drive.jpg?rlkey=ji0soyglau9x9ija9xrwv00m3&dl=0>

    <https://www.dropbox.com/scl/fi/bxs3kc56chc4ixc1hhsn6/Drive2.jpg?rlkey=w5nd00f4d7olya6y6v0cqeviv&dl=0>

    Laptop came with Windows 8 from Asus, which is what I believe created the 20.01 GB "Restore" partition.

    It has been a while, but I believe I created partition 6 (D:) because they were not paying attention to where they were placing their working files, and for some stupid reason I thought this would get them in the habit of knowing where their files
    were located.  As it only had 150 MB in it, obviously that didn't work.

    About 1.5 years back, I updated this laptop to Windows 10.  The Drive2 link above shows partition 5 also as a "Recovery" partition.  Both partitions 2 and 5 seem to have enough space to be able to do the ReAgent KB5034441 update, though one is
    before the C drive and one is between the C and D drives. But it would not install the update and fails.

    My question is how did partition 5 get in there in-between the two drives?  I'm wondering why diskpart claims it is a recovery partition, though it also calls partition 7 a recovery partition when disk management calls it a "Restore" partition. 
    What the heck is partition 5?




                1                 2       3       4         5        6      7
    -------------------------+---------+-----+---------+---------+-----+---------------------------+
    ESP System Partition     |System   |MSR  |C:       |System   |D:   |Restore  (Could be W7)     |
    (Microsoft folder, BCD)  |Reserved |NoFS |Partition|Reserved |Data |12GB                       |
                              |WinRE.wim|128MB|         |WinRE.wim|     |Traditional OS restoration |
    -------------------------+---------+-----+---------+---------+-----+---------------------------+

    reagentc /info                    # in an Administrator window

    The partition number in reagentc /info, should point to the one
    on the right of the C: partition. "Partition 5" is the real one.
    "Partition 2" is no longer in usage. Partition 5 was caused by
    an OS Upgrade. Partition 2 was invented, before they knew what
    they were doing.

    Yes, partition 5 was where reagentc /info pointed.

    Any time that metadata uses partition numbers, it is not a
    good idea to be deleting partitions "to the left" of the
    affected partition. At least, unless you know how
    to repair the damage. 5 is using partition number for reference,
    so do not delete 2 (unless you are ready to do reagentc repair procedure).

    I have done this repair procedure many times now, so I ultimately decided to delete the partitions 2, 5 and 7.  I then made partition 4 big, and shrunk it by 1500 MB and created the WinRE partition in the right spot and reagentc /info showed it was
    all there and enabled. Looked like this when done.

    <https://www.dropbox.com/scl/fi/5njsciy0k0w7cyxml1x9m/Drive3.jpg?rlkey=xy5ph92r59cdezpn628jwoc7z&dl=0>

    I haven't actually tried yet to see on this system if the recovery agent actually works.  I probably should do that since I still cannot get this to do the 4441 update for some reason.  There is no BitLocker in use on this machine, so I really don't
    care if it gets updated if the recovery environment still works.  I also know I can just reimage if it gets screwed up. It will just try and fail every time it does updates.
    Is there a way to tell MS Update not to try this one again?

    ---snip---

    If you, in diskpart.exe, "assign letter=K" to a partition,
    that allows hidden partitions to be listed. The alternative,
    is to use TestDisk, but that is an acquired taste as a tool.
    Note that assigning a letter in this way, is not honored by
    all the software. It has limited scope.

        diskpart
        list disks
        select disk 0
        list partitions
        select partition 5
        assign letter=K
        exit

        K:
        dir
        cd directoryname
        dir
        ...                # Descend and look around.

        [Reboot, to clear the K: assignment and be shed of it.]



    I think you're saying that if I do above and assign partition 2 a letter it will show up here too?

    <https://www.dropbox.com/scl/fi/yb44qp98u0keqooocu36q/Drive4.jpg?rlkey=olvo7fzvxwvbyjf5l4arakvc0&dl=0>

    ---snip---

    As usual, very interesting stuff for me.  Thanks!



    If you assign drive letter K to a partition,
    it does not show in Disk Management. It might not
    be accounted for in MountVol. It would only show in
    Disk Management if the partition was a regular NTFS one.

    But at least in a terminal, you should be able
    to do

    K:
    dir
    cd directoryname
    dir

    and look around a bit if you want.

    If the hidden partition is unformatted, then it's not going
    to mount this way. Only if there is a file system inside the
    hidden item, does this work. And there could still be
    permission issues.

    Since FAT32 doesn't have that sort of permission issue,
    you should be able to skate around in an ESP for a look.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to Paul on Wed Feb 7 19:42:58 2024
    On 2/7/2024 7:14 PM, Paul wrote:
    On 2/7/2024 11:06 AM, sticks wrote:

    If you assign drive letter K to a partition,
    it does not show in Disk Management. It might not
    be accounted for in MountVol. It would only show in
    Disk Management if the partition was a regular NTFS one.

    But at least in a terminal, you should be able
    to do

    K:
    dir
    cd directoryname
    dir

    and look around a bit if you want.

    If the hidden partition is unformatted, then it's not going
    to mount this way. Only if there is a file system inside the
    hidden item, does this work. And there could still be
    permission issues.

    Since FAT32 doesn't have that sort of permission issue,
    you should be able to skate around in an ESP for a look.

    Paul


    OK, this was more of a 'I want to learn' question than an 'I need to do
    it' one. I know it's a relatively small MS folder, so I'll just leave
    it alone and keep from screwing anything else up for now.

    Thanks for the info!



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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to All on Wed Feb 7 21:07:29 2024
    On 2/7/2024 5:16 PM, ...w¡ñ§±¤ñ wrote:
    sticks wrote on 2/7/24 1:58 PM:
    On 2/7/2024 11:57 AM, ...w¡ñ§±¤ñ wrote:

    I'm going to try and see if I am missing something like this in my
    thinking since it still won't update 4441 even though it is enabled
    and is positioned after C now like this

    <https://www.dropbox.com/scl/fi/5njsciy0k0w7cyxml1x9m/Drive3.jpg?rlkey=xy5ph92r59cdezpn628jwoc7z&dl=0>

    Fyi...WinRE partition being enabled doesn't necessarily guarantee KB
    5034441(and its SafeOS update KB5034232) will be installed.

    Meaning it won't try, or it can still fail?  Because it definitely
    keeps trying to install it.

    An update can't fail, if not attempted.

    When an update is attempted, two possible outcomes - success of failure.
     - the latter does not exempt future attempts.
    i.e. an indication that if offered(and based on the device's condition),
    it should be installed)

    I thought you perhaps meant it might not be offered and install
    attempted. For example, from what I've read 4441 is supposed to add
    something associated with it's ability to navigate BitLocker encrypted
    systems. Since Windows 10 Home edition does not have BitLocker, is it
    still being offered because though it doesn't have BitLocker, there is
    another option to encrypt data?


    The status of the o/s version, build and the version/build of the
    SSU(Servicing Stack Update) is also a controlling factor.

    What is the current installed version and build of Windows 10?

    Windows 10 Home Edition
    Version 22H2
    Build 19045.3996

    I tried finding the installed servicing stack build, but that doesn't
    seem so simple.  Is there a specific KB for this build I should check
    to see if it is installed?

    Version/Build(22H2 19045.3996) indicates the Jan. 23, 2024 KB5034203
    Preview update was installed which also installs its included SSU
    19045.3989


    The partition order shown in your pic is the correct order.
      - post re-partitioning, did you re-run reagentc /info to determine
    the recovery partition status(partition number and enabled)?

    Yes, it is enabled.  I am going to try /boottore and see if I can get
    in there.


     For what purpose ?...'getting in there' won't provide any information
    on success or failure of 5034441(and its included SafeOS update KB5034232)

    I wanted to check for two reasons.

    First, simply because I enjoy the learning chances people like you,
    Paul, Vanguard, Andy, Charles and so many others are gracious enough in providing. I always find it fascinating.

    Second, because since this 4441 update provides Bitlocker functionality
    in some way, and this computer doesn't use either encryption or
    Bitlocker, I wanted to know if it still could be accessed to use the
    recovery tools if needed. I checked using reagentc /boottore and yes it
    did allow me to go in and look around. It all seems to be there. Only
    problem I had was on a couple of the actual recovery option tiles, once
    clicked I was told I needed an administrator account to sign in to do
    anything. There is only one account on this laptop, and it is an
    administrator account, though it is set up as without a MS account. If
    I recall they call that an off line account. So I guess in a way it is
    not functional until I can figure out what that means.


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to sticks on Wed Feb 7 22:36:17 2024
    On 2/7/2024 10:07 PM, sticks wrote:
    On 2/7/2024 5:16 PM, ...w¡ñ§±¤ñ wrote:
    sticks wrote on 2/7/24 1:58 PM:
    On 2/7/2024 11:57 AM, ...w¡ñ§±¤ñ wrote:

    I'm going to try and see if I am missing something like this in my thinking since it still won't update 4441 even though it is enabled and is positioned after C now like this

    <https://www.dropbox.com/scl/fi/5njsciy0k0w7cyxml1x9m/Drive3.jpg?rlkey=xy5ph92r59cdezpn628jwoc7z&dl=0>

    Fyi...WinRE partition being enabled doesn't necessarily guarantee KB 5034441(and its SafeOS update KB5034232) will be installed.

    Meaning it won't try, or it can still fail?  Because it definitely keeps trying to install it.

    An update can't fail, if not attempted.

    When an update is attempted, two possible outcomes - success of failure.
      - the latter does not exempt future attempts.
    i.e. an indication that if offered(and based on the device's condition), it should be installed)

    I thought you perhaps meant it might not be offered and install attempted.  For example, from what I've read 4441 is supposed to add something associated with it's ability to navigate BitLocker encrypted systems.  Since Windows 10 Home edition does
    not have BitLocker, is it still being offered because though it doesn't have BitLocker, there is another option to encrypt data?


    The status of the o/s version, build and the version/build of the SSU(Servicing Stack Update) is also a controlling factor.

    What is the current installed version and build of Windows 10?

    Windows 10 Home Edition
    Version 22H2
    Build 19045.3996

    I tried finding the installed servicing stack build, but that doesn't seem so simple.  Is there a specific KB for this build I should check to see if it is installed?

    Version/Build(22H2 19045.3996) indicates the Jan. 23, 2024 KB5034203 Preview update was installed which also installs its included SSU 19045.3989


    The partition order shown in your pic is the correct order.
      - post re-partitioning, did you re-run reagentc /info to determine the recovery partition status(partition number and enabled)?

    Yes, it is enabled.  I am going to try /boottore and see if I can get in there.


      For what purpose ?...'getting in there' won't provide any information on success or failure of 5034441(and its included SafeOS update KB5034232)

    I wanted to check for two reasons.

    First, simply because I enjoy the learning chances people like you, Paul, Vanguard, Andy, Charles and so many others are gracious enough in providing.  I always find it fascinating.

    Second, because since this 4441 update provides Bitlocker functionality in some way, and this computer doesn't use either encryption or Bitlocker, I wanted to know if it still could be accessed to use the recovery tools if needed.  I checked using
    reagentc /boottore and yes it did allow me to go in and look around.  It all seems to be there.  Only problem I had was on a couple of the actual recovery option tiles, once clicked I was told I needed an administrator account to sign in to do anything.
      There is only one account on this laptop, and it is an administrator account, though it is set up as without a MS account.  If I recall they call that an off line account.  So I guess in a way it is not functional until I can figure out what that
    means.


    Using Diskpart

    list disk
    select disk 0
    list partition
    select partition 3 # 1.46GB, should be NTFS
    detail partition # Is it formatted ? Check. You can format it from diskpart.

    format quick fs=ntfs label="Recovery" # The label of course, is a joke, and we can't see it.
    detail partition # Doing that makes the script easier to read.

    exit

    If it is actually NTFS, you can

    assign letter=K

    after the formatting step. It should
    be empty of course. A dir will tell you
    what's in K. Sometimes, you do a second

    dir # Display visible files
    dir /ah # Display hidden files

    It already says "Recovery Partition", which means something
    other than "regular partition" has been assigned to it.
    The GPT table entry is correct, but it might not be formatted NTFS.

    The refusal could also happen, if any step in the manufacture of the WinRE.wim has failed.

    On W11Home right now, this has stuff in it, but I don't know
    exactly why this has staging in it.

    C:\$WinREAgent\Scratch\Mount\Windows\System32

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to All on Thu Feb 8 20:04:37 2024
    On 2/7/2024 11:18 PM, ...w¡ñ§±¤ñ wrote:
    sticks wrote on 2/7/24 6:42 PM:

    If you are using Macrium Reflect or similar for making an image of the Windows 10 GPT partitions, one could just explore the Recovery partition
    and look at the date of the Winre.wim file...the rest of the files(version/build) found in that partition won't provide more or
    additional significant information relative to reasons for '4441/4232' failing to install.
    ..but one can look at a few(two) files in Windows\System32 that get
    changed when the Recovery partition is updated.
    winload.exe version/build and date
    winload.efi version/build and date
    Then compare those with what you found for Service Pack Build in the
    earlier noted DISM /Get-ImageInfo command

    Normally the build number of these 2 files will be identical to the
    installed Windows version(seen in winver) and will be greater than or
    equal to the Service Pack build reported in /Get-ImageInfo

    My winload.exe version is the same as yours. 10.0.19041.3996
    The properties page for the winload.efi file did not have a spot for a
    version number.

    The dates for the two files also differ from the Get-ImageInfo (2014)
    and look like they are probably the date I created the ReAgent
    partition. They give a date of 1/31/2024

    Note: My Surface 3 running Win10 Pro(Home in this case would not be different, its all Win10)after updating with 4441 shows
    - the two winload files as 10.0.19041.3996
    - Get-ImageInfo shows the Service Pack Build as 3920

    Sidenote:
     To get that Surface 3 to update(failed 4 times on '4441').  I took a different route(b/c I knew that System Restore points located at the end
    of the C:\Windows partition can prevent resizing(shrinking) the Windows partition inevitably causine '4441' failing.

    But, I'm assuming with 1500MB in that partition I wouldn't have to do
    any of what you've described? Or (I admit I forgot to check if any of
    these were already installed) should I go ahead and get the KB's below
    and install them manually too?

    So..
    - I deleted all System Restore Points
    - Disabled System Restore for the C: drive(it was not enabled for other drives either)
    - Used Windows Disk Cleanup in admin mode to remove everything it showed
    as removable(i.e. - all boxes were checked before running) - took about
    15 min on that 8 yr old device(Intel Atom chip and 4 GB RAM, 128 GB disk storage), and WinRE partition had sufficient free space to handle the Recovery partition updating).
    - Turned off Windows Update option 'Receive updates from other Microsoft products
    - Installed the Jan 9 2024 KB5034275(.NET Cumulative) and KB 5034122 update
    - Installed the Jan 23 KB5034203 Cumulative Preview successfully - 19045.3996,
    ...then successfully installed KB 5034441 (WinRE update which also
    applies SafeOS Security update KB5034232), which also updated the
    Recovery Partition.  Verified by the earlier info(the two winload files version/build and Get-ImageInfo Service Pack Build.

    Other Win10 devices with succesful Recovery Partition update and 4441
    update may show different version/buile numbers and/or Service Pack
    Build of the Winre.wim file..but still representative or a successful
    install of the KB and updating the Recovery partition(resized or not
    with a larger usage of total Recovery partition size.



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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to All on Thu Feb 8 19:56:47 2024
    On 2/7/2024 9:55 PM, ...w¡ñ§±¤ñ wrote:

    Automatically booting on startup to the Recovery Environment would function(as long as the partition and files are not damaged) with or
    without installation of KB 034441(and its SafeOS update KB5034232)

    There is a Powershell command that can be used to determine the Service
    Pack Build #, and last modified date of the Recovery partition's
    winre.wim file

    DISM /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk1\partition4\Recovery\WindowsRE\winre.wim /index:1

    Note: the above is an example...variables that may need to be changed if different for your system are
     harddisk1
     parition4
     /index:1

    When you run reagentc /info the first two terms are shown in the Windows
    RE Location field result
     - thus based on what you see, if necessary modify the above DISM
    command for harddisk# and partition#

    /index:1 is the usual location for all devices.
     - don't change it

    I ran this and it looks old (2014), maybe it can tell you something that
    is wrong?

    <https://www.dropbox.com/scl/fi/4o12tuqttpcvdgm5nv3a3/Get-ImageInfo.jpg?rlkey=j6grshwae1s7sp5f8xuf47mty&dl=0>



    Second, because since this 4441 update provides Bitlocker
    functionality in some way, and this computer doesn't use either
    encryption or Bitlocker, I wanted to know if it still could be
    accessed to use the recovery tools if needed.  I checked using
    reagentc /boottore and yes it did allow me to go in and look around.
    It all seems to be there.  Only problem I had was on a couple of the
    actual recovery option tiles, once clicked I was told I needed an
    administrator account to sign in to do anything.  There is only one
    account on this laptop, and it is an administrator account, though it
    is set up as without a MS account.  If I recall they call that an off
    line account.  So I guess in a way it is not functional until I can
    figure out what that means.


    Bitlocker not present on Home is not a variable in whether or not the Recovery partition is functional
     - which you proved.

    The 4441/4232 combined update is meant to be applied with or without Bitlocker and for both Home, Pro, etc. editions.
     - The SafeOS update(4232) is should be seen/interpreted as a necessary compatibility update(alleviate a potential problem) that installs prior
    to '4441' which installs and updates the Recovery partition.

    One could attempt to install the correct bit version of the very small
    size stand-alone SafeOS '4232' update, restart, then let Windows Update attempt to install '4441' <https://www.catalog.update.microsoft.com/Search.aspx?q=KB5034232>

    I did find and install this update, restarted, and it still failed.



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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to All on Sat Feb 10 10:29:50 2024
    On 2/10/2024 5:32 AM, ...w¡ñ§±¤ñ wrote:
    sticks wrote on 2/8/24 6:56 PM:
    On 2/7/2024 9:55 PM, ...w¡ñ§±¤ñ wrote:
    DISM /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk1\partition4\Recovery\WindowsRE\winre.wim /index:1

    Note: the above is an example...variables that may need to be changed if different for your system are
      harddisk1
      parition4
      /index:1

    When you run reagentc /info the first two terms are shown in the Windows RE Location field result
      - thus based on what you see, if necessary modify the above DISM command for harddisk# and partition#

    /index:1 is the usual location for all devices.
      - don't change it

    I ran this and it looks old (2014), maybe it can tell you something that is wrong?

    <https://www.dropbox.com/scl/fi/4o12tuqttpcvdgm5nv3a3/Get-ImageInfo.jpg?rlkey=j6grshwae1s7sp5f8xuf47mty&dl=0>


    Interesting.

    Your pic indicates Service Pack Build 16384.
     10240.16384 is the official RTM build of the original release of Windows 10 original released to Insider Ring on July 15 2015 and the general public on July 29th 2015. Exactly one year later ithe same build was released/used as the free upgrade
    version for Windows 7, 8.0 and 8.1 users.

    16384 was also the initial Win RE build with those 2012 era 'create and modify' dates.

    We can postulate about all the possible reasons on how WinRE partition was modified since 2015....originally as part of feature build updates(semi-annually up up to 21H2, then annually starting with 22H2(fall of 2022).  The following year in June 2023
    updates to WinRE partition were included(when required to be updated) in the monthly Cumulative Updates(for Win10 22H2 and also Win11 22H2
     - In Nov. 2023, Win11 23H2 released and included in the WinRE partition inclusion in monthly updates.

    Why your WinRE service pack build number over 8 yrs old could be a variety of causes.
     - never updated with feature updates
     - that earlier partition #2 Recovery partition(which iirc you removed was created at one time in the #5 partition(by Windows, and after the Windows partition) maybe with the #2 partition bits and never ever updated
       => Updating WinRE partition should have at least happened on #5 multiple times and especially with 21H1, 21H2, and 22H2 and again via cumulative updates in July 2023, Sept 2023, Dec 2023....and again in Jan 2024.
       => Once your redid the disk(removing #2 the inactive WinRE, and resized #4(which was #5)...if done properly it would have at least 22H2 bits with a Service Pack build # of 3000 or greater.

    Which raises a few reasonable questions.
     What did you use to resize Windows and the Recovery Partion?

    Did you follow the KB article for resizing WinRE partition?  <https://support.microsoft.com/help/5028997>

    Anything else, about this device or past history that's not been provided in earlier posts?

    Doesn't the 6.2.9200 indicate Windows 8.0 2012-10-26 ?

    This is a sample from my Win81 (6.3.9600) disk drive, which does not have
    a separate partition System Reserved. The file is on the C: partition.
    The file size in the DISM report, is the uncompressed size, whereas the WinRE.wim file itself is 279,000,000 or so.

    [Picture]

    https://i.postimg.cc/28Q92yH4/WIN81-Win-RE-WIM-sample.gif

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to All on Sat Feb 10 09:29:22 2024
    On 2/10/2024 4:32 AM, ...w¡ñ§±¤ñ wrote:
    sticks wrote on 2/8/24 6:56 PM:
    On 2/7/2024 9:55 PM, ...w¡ñ§±¤ñ wrote:
    DISM /Get-ImageInfo
    /ImageFile:\\?\GLOBALROOT\device\harddisk1\partition4\Recovery\WindowsRE\winre.wim /index:1

    Note: the above is an example...variables that may need to be changed
    if different for your system are
      harddisk1
      parition4
      /index:1

    When you run reagentc /info the first two terms are shown in the
    Windows RE Location field result
      - thus based on what you see, if necessary modify the above DISM
    command for harddisk# and partition#

    /index:1 is the usual location for all devices.
      - don't change it

    I ran this and it looks old (2014), maybe it can tell you something
    that is wrong?

    <https://www.dropbox.com/scl/fi/4o12tuqttpcvdgm5nv3a3/Get-ImageInfo.jpg?rlkey=j6grshwae1s7sp5f8xuf47mty&dl=0>


    Interesting.

    Your pic indicates Service Pack Build 16384.
     10240.16384 is the official RTM build of the original release of
    Windows 10 original released to Insider Ring on July 15 2015 and the
    general public on July 29th 2015. Exactly one year later ithe same build
    was released/used as the free upgrade version for Windows 7, 8.0 and 8.1 users.

    This came as a Windows 8.0 which immediately got upgraded to 8.1

    16384 was also the initial Win RE build with those 2012 era 'create and modify' dates.

    We can postulate about all the possible reasons on how WinRE partition
    was modified since 2015....originally as part of feature build updates(semi-annually up up to 21H2, then annually starting with
    22H2(fall of 2022).  The following year in June 2023 updates to WinRE partition were included(when required to be updated) in the monthly Cumulative Updates(for Win10 22H2 and also Win11 22H2
     - In Nov. 2023, Win11 23H2 released and included in the WinRE
    partition inclusion in monthly updates.

    Why your WinRE service pack build number over 8 yrs old could be a
    variety of causes.
     - never updated with feature updates
     - that earlier partition #2 Recovery partition(which iirc you removed
    was created at one time in the #5 partition(by Windows, and after the
    Windows partition) maybe with the #2 partition bits and never ever updated
       => Updating WinRE partition should have at least happened on #5 multiple times and especially with 21H1, 21H2, and 22H2 and again via cumulative updates in July 2023, Sept 2023, Dec 2023....and again in Jan 2024.
       => Once your redid the disk(removing #2 the inactive WinRE, and
    resized #4(which was #5)...if done properly it would have at least 22H2
    bits with a Service Pack build # of 3000 or greater.

    Which raises a few reasonable questions.
     What did you use to resize Windows and the Recovery Partion?

    Did you follow the KB article for resizing WinRE partition?
     <https://support.microsoft.com/help/5028997>

    Yes, except I did not use 250MB. I have done this several times now and
    made them all a little bigger than that.
    Anything else, about this device or past history that's not been
    provided in earlier posts?

    Oh, since it was not mine, I'm sure any number of unique things could
    have happened. I doubt they updated with any consistency, but one would
    still think eventually it got done.

    As this is the only one of the systems I have tried to fix this issue
    that has failed, I do find it interesting and if you have other things
    you too are interested in having me try I would be available for that. Otherwise, I could just leave it be since it could be redone with the
    good macrium image. I don't find this the best option since I'm not
    sure whose hands this will end up in. I'm kind of leaning towards just
    format and reinstall the entire thing. I have the original win 8 key,
    but would like to just reinstall the Win 10 on it's own. I have to
    learn about the digital license stuff and what doing it that way would
    require.

    But like I said, if there is anything else you would like to know if it
    works or not, please ask.

    Thanks

    sticks



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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to Never on Thu Feb 15 08:19:04 2024
    On 2/10/2024 4:02 PM, ...w¡ñ§±¤ñ wrote:
    sticks wrote on 2/10/24 8:29 AM:
    On 2/10/2024 4:32 AM, ...w¡ñ§±¤ñ wrote:

    This came as a Windows 8.0 which immediately got upgraded to 8.1


    That adds some creditibilty to the old 16384 Service Pack #.
     - Note: Paul caught the  6.2.9200 Windows 8.0 version

    It also may indicate a resistance to past feature and cumulative updates which had code to update the WinRE partition(i.e. those updates expect
    to see Win10 content not 8.0/8.1)

    Which raises a few reasonable questions.
      What did you use to resize Windows and the Recovery Partion?

    Did you follow the KB article for resizing WinRE partition?
      <https://support.microsoft.com/help/5028997>

    Yes, I used the elevated command prompt


    Yes, except I did not use 250MB.  I have done this several times now
    and made them all a little bigger than that.
    Anything else, about this device or past history that's not been
    provided in earlier posts?

    I.e. you used the diskpart routine to resize and not 3rd party software
     - Did you also use Diskpart commands to delete the old partition

    Yes, diskpart.

    I hadn't yet tried the part we talked about yesterday of removing all
    the restore points since the partition was at 1.5GB and seemed to have
    enough space. But, I tried it anyway yesterday. It did not help and
    4441 still failed.


    :) If this were my device I would have wiped that device after upgrading
    to Win10(digital license now link to the device) and used Win10 22H2 usb created media for booting, its includes tools to wipe the device, and a diskpart script to create the 4 required GPT partitions(System 100MB,
    MSR 16 MB, Windows, and a 2.0 GB Win RE partition, then continue and
    install Windows 10 22H2
     - Also, that first account created after W10 22H2 installation and
    final setup would be a MSFT account, not a Local account.

    So I broke down and did the above. Once installed, the first set of
    updates included 4441 and it went through right away. Lot of work on
    this one, but alas, it is finally done and working properly!

      I have the original win 8 key, but would like to just reinstall the
    Win 10 on it's own.

    With Win10 on the current device and digitally licensed the Win8 key is
    not needed, at at this stage useless.

    This is correct. Never asked for anything.

     Does raise a question
     Was this device upgraded from Win8x Home to Win8x Pro or Win10 Home to Win10 Pro?

    Both were Home versions

    Much thanks!


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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to All on Sat Feb 17 10:34:32 2024
    On 2/16/2024 11:36 AM, ...w¡ñ§±¤ñ wrote:
    sticks wrote on 2/15/24 7:19 AM:

    Wtg!  Well done.
     You're welcome.

    You can rerun that earlier mentioned commane to see your current WinRE Service Pack build and dates etc.

    I had intended to do this and forgot before claiming it was all fixed.
    Nice catch. When I checked, it was all the same build (2014) as before.
    I had to go back and do the recreating of the partition, and renamed
    the .wim file in the recovery directory, re-enabling it, and I think it
    finally shows a current ReAgent!

    <https://www.dropbox.com/scl/fi/qb1aa61bhgdo5099bvpws/ReAgentNew.jpg?rlkey=jnhiz15sutdqm2cwsnv61k1qr&dl=0>


    Sometimes the wipe path is the easier route, especially in this case
    when the WinRE partition build was showing and old o/s(unsupported long
    ago) build number.
     There were other ways to replace that Win8 era WinRE...as I said messy
     - one of which pulls/extracts the WinRE.wim file(using the DISM
    command) from an external(or mounted ISO) same o/s(as installed) media's install.wim file(not install.esd used in Media Creation tool media),
    copy  the winre.wim to the C:\..\Recovery folder allowing it be used
    when reaagentc is later enabled and moved to the newly created WinRE partition.


    I think what I did wrong during the reinstall was that I just refreshed
    the recovery partition instead of formatting it?
    Anyway, giving it back to the MIL as a spare today. Kind of a waste
    really. With a clean install now, instead of a Windows 8 upgrade
    install of Windows 10, it probably works better than it ever did. Since
    I already bought her the new system, this will just lay around and never
    get used. But, it was certainly interesting doing all this stuff.

    Thanks!

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to All on Mon Feb 19 18:07:50 2024
    On 2/17/2024 2:11 PM, ...w¡ñ§±¤ñ wrote:
    sticks wrote on 2/17/24 9:34 AM:
    On 2/16/2024 11:36 AM, ...w¡ñ§±¤ñ wrote:
    sticks wrote on 2/15/24 7:19 AM:

    Wtg!  Well done.
      You're welcome.

    You can rerun that earlier mentioned commane to see your current
    WinRE Service Pack build and dates etc.

    I had intended to do this and forgot before claiming it was all fixed.
    Nice catch.  When I checked, it was all the same build (2014) as
    before.   I had to go back and do the recreating of the partition, and
    renamed the .wim file in the recovery directory, re-enabling it, and I
    think it finally shows a current ReAgent!

    <https://www.dropbox.com/scl/fi/qb1aa61bhgdo5099bvpws/ReAgentNew.jpg?rlkey=jnhiz15sutdqm2cwsnv61k1qr&dl=0>

     That looks right for Win10.  Other Win10 devices Service Pack Build,
    date created can look different, some of which being dependent upon the version of or the point in time the Win10 media was created or downloaded.
     - e.g. Win10 22H2 was released in fall or 2022 but the Media Creation
    Tool and ISO have been updated with some new system files. Win11 WinRE
    System Build likewise can show variation in the Service Pack Build(e.g.
    3000 vs 3007 or higher)


    Sometimes the wipe path is the easier route, especially in this case
    when the WinRE partition build was showing and old o/s(unsupported
    long ago) build number.
      There were other ways to replace that Win8 era WinRE...as I said messy >>>   - one of which pulls/extracts the WinRE.wim file(using the DISM
    command) from an external(or mounted ISO) same o/s(as installed)
    media's install.wim file(not install.esd used in Media Creation tool
    media), copy  the winre.wim to the C:\..\Recovery folder allowing it
    be used when reaagentc is later enabled and moved to the newly
    created WinRE partition.


    I think what I did wrong during the reinstall was that I just
    refreshed the recovery partition instead of formatting it?

    Yes, wiping the disk, then following all the steps to create all 4 GPT partitions is the preferred approach.
    When clean installing Windows by booting the media I use the Advanced
    options mode allowing me command line control and access to Diskpart for running a Diskpart script(*.txt file). The script(while in Diskpart)
    isn't necessary since all commands can be entered/typed manually, but
    using the script ensures no errors(typing), streamlines the process and
    it's faster.
    - Here's an example script of all the steps for a device with a single
    256 GB SSD as Disk 0.
    **************
    rem DISKPART script
    rem Disk 0 with a single 256 GB SSD
    rem Creates GPT(EFI MSR Windows with 2 GB Recovery)
    rem Disk 0 OpSy Windows10 Pro 22H2
    rem Select Disk, wipe it empty, convert to GPT
    select disk 0
    clean
    convert gpt
    create partition efi size=100
    format quick fs=fat32 label="System"
    create partition msr size=16
    create partition primary
    shrink minimum=2048
    format quick fs=ntfs label="Windows10Pro"
    assign letter="W"
    create partition primary size=2048
    format quick fs=ntfs label="WinRE"
    set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
    rem Exit Diskpart
    rem written by winston
    exit
    ******************

    Once done(diskpart exited), all that remains is to continue clean
    installing Win10 22H2 to the Windows partition.


    Thanks!

     You're welcome


    Nice. I have archived this locally for the future just in case.

    Wife's laptop could really use this I think. The one I just finished
    runs so much better than it ever did, I suggested doing hers since she
    get occasional lockups. She passed on the offer, and I shrugged as I
    walked away.


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

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