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)
