• "To finish updating, restart Microsoft Edge." in a loop!

    From Ant@21:1/5 to All on Wed Apr 10 02:07:17 2024
    My updated 64-bit W10 Pro.'s 64-bit Edge v122.0.2365.80 won't upgrade to
    v123. Everytime I restart Edge from the update, it quickly say the same
    thing at edge://settings/help screen. I rebooted W10 too.

    What's wrong? Thank you for reading and hopefully answering soon. :)
    --
    "Whatever you have learned or received or heard from me, or seen in me ??? put it into practice. And the God of peace will be with you." --Philippians 4:9. I need to practice and not be a fool boy.
    Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
    /\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
    / /\ /\ \ Please nuke ANT if replying by e-mail.
    | |o o| |
    \ _ /
    ( )

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Ant on Wed Apr 10 06:48:58 2024
    On 4/9/2024 10:07 PM, Ant wrote:
    My updated 64-bit W10 Pro.'s 64-bit Edge v122.0.2365.80 won't upgrade to v123. Everytime I restart Edge from the update, it quickly say the same
    thing at edge://settings/help screen. I rebooted W10 too.

    What's wrong? Thank you for reading and hopefully answering soon. :)


    The Win10 I got this from, hasn't seen Patch Tuesday yet, which
    is why the Updater version is that old. The updater is in charge
    of updating the main edge. And this could be in the loop for
    all I know.

    C:\ProgramData\Microsoft\EdgeUpdate\Log

    C:\Program Files (x86)\Microsoft\EdgeUpdate\1.3.185.21
    3/17/2024 8:49 PM 206288 MicrosoftEdgeUpdate.exe

    It's hard to say, whether the "obvious" controls will work.
    That's because the "Repair" button for the MSEdge browser package,
    actually triggers a dialog from MicrosoftEdgeUpdate.exe . Since
    your MicrosoftEdgeUpdate.exe is in an apparent loop, it might
    be "too stoopid to escape". You know how clever software design is.

    [Picture] "The naive repair routes..."

    https://i.postimg.cc/t4n75814/Win10-MSEdge-Repair-controls.gif

    A user here reports, one attempt to repair the naive way, did not
    work. And another attempt did work. Does not inspire confidence.
    But by using one of the Repair methods, I'm hoping to not disturb
    the stream yours is in. This is your best option at the moment.

    https://answers.microsoft.com/en-us/microsoftedge/forum/all/after-opening-edge-browser-it-starts-closses-and/b25aebf5-161b-4a78-b3aa-a5d6befd5564

    Some of the Microsoft installers have "loop breaking logic". The problem
    is, Microsoft is not very consistent, so some things will just
    loop forever.

    *******

    MicrosoftEdgeUpdate.exe has two ways to update.

    It can update a full version of an installer for usage. Maybe 172MB.
    Web articles refer to a location in AppData, where the download is.

    But for this particular update attempt, it downloaded a patch.diff
    and it did not stage it in Appdata. It put it in C:\Program Files (x86)
    area instead. Patch.diff means it is doing some kind of binary
    diff to a previous named version of browser, and bringing it
    from 122.x to 123.x . That is why some web articles which
    "recommend looking in a certain folder for an offline installer EXE"
    won't be working in this case. It's possible the patch.diff is stuck
    in a loop (patch diffs only work, if they do "find/replace" and the
    find locates the target - if the target is not present, the patch
    bombs out).

    Normal design technique for this would be, if a patch.diff fails,
    you download the full EXE installer and stop fooling around :-)
    That's what you're SUPPOSED to do.

    *******

    After looking at a number of other alternative methods, some
    of them seemed to involve the "Enterprise" version, where the
    DLL file was a different size, and I didn't feel comfortable
    sharing that with you. I'm trying to paint within the lines.

    And this is what happens, when Microsoft feels their update method "cannot fail".
    They leave nothing for the user to fix it! If they weren't using patch.diff,
    we could fix this. And no, if you use the old Powershell command
    for this, it digs up the defunct version (the before-Chrome version),
    which is no good. I checked that too.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ant@21:1/5 to Paul on Wed Apr 10 18:32:39 2024
    Full installer worked. Thanks.


    Paul <nospam@needed.invalid> wrote:
    ...
    The Win10 I got this from, hasn't seen Patch Tuesday yet, which
    is why the Updater version is that old. The updater is in charge
    of updating the main edge. And this could be in the loop for
    all I know.

    C:\ProgramData\Microsoft\EdgeUpdate\Log

    C:\Program Files (x86)\Microsoft\EdgeUpdate\1.3.185.21
    3/17/2024 8:49 PM 206288 MicrosoftEdgeUpdate.exe

    It's hard to say, whether the "obvious" controls will work.
    That's because the "Repair" button for the MSEdge browser package,
    actually triggers a dialog from MicrosoftEdgeUpdate.exe . Since
    your MicrosoftEdgeUpdate.exe is in an apparent loop, it might
    be "too stoopid to escape". You know how clever software design is.

    [Picture] "The naive repair routes..."

    https://i.postimg.cc/t4n75814/Win10-MSEdge-Repair-controls.gif

    A user here reports, one attempt to repair the naive way, did not
    work. And another attempt did work. Does not inspire confidence.
    But by using one of the Repair methods, I'm hoping to not disturb
    the stream yours is in. This is your best option at the moment.

    https://answers.microsoft.com/en-us/microsoftedge/forum/all/after-opening-edge-browser-it-starts-closses-and/b25aebf5-161b-4a78-b3aa-a5d6befd5564

    Some of the Microsoft installers have "loop breaking logic". The problem
    is, Microsoft is not very consistent, so some things will just
    loop forever.

    *******

    MicrosoftEdgeUpdate.exe has two ways to update.

    It can update a full version of an installer for usage. Maybe 172MB.
    Web articles refer to a location in AppData, where the download is.

    But for this particular update attempt, it downloaded a patch.diff
    and it did not stage it in Appdata. It put it in C:\Program Files (x86)
    area instead. Patch.diff means it is doing some kind of binary
    diff to a previous named version of browser, and bringing it
    from 122.x to 123.x . That is why some web articles which
    "recommend looking in a certain folder for an offline installer EXE"
    won't be working in this case. It's possible the patch.diff is stuck
    in a loop (patch diffs only work, if they do "find/replace" and the
    find locates the target - if the target is not present, the patch
    bombs out).

    Normal design technique for this would be, if a patch.diff fails,
    you download the full EXE installer and stop fooling around :-)
    That's what you're SUPPOSED to do.

    *******

    After looking at a number of other alternative methods, some
    of them seemed to involve the "Enterprise" version, where the
    DLL file was a different size, and I didn't feel comfortable
    sharing that with you. I'm trying to paint within the lines.

    And this is what happens, when Microsoft feels their update method "cannot fail".
    They leave nothing for the user to fix it! If they weren't using patch.diff, we could fix this. And no, if you use the old Powershell command
    for this, it digs up the defunct version (the before-Chrome version),
    which is no good. I checked that too.

    Paul

    --
    "This is love: not that we loved God, but that he loved us and sent his Son as an atoning sacrifice for our sins." --1 John 4:10. Slammy Tuesday.
    Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
    /\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
    / /\ /\ \ Please nuke ANT if replying by e-mail.
    | |o o| |
    \ _ /
    ( )

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