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| |
\ _ /
( )

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

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| |
\ _ /
( )