Forum Discussion
Solved
Which update impact might Edge Enterprise have if running a non updated 'MicrosoftEdgeUpdate.exe'?
Hello, could anyone please be so kind to tell me something about which update impact might Edge Enterprise (Stable) have if on my OS there's still running a non updated version of 'MicrosoftEdgeU...
KenChong (again & other insiders interested as well...)
In addition to correcting my last week reply (Sep 18 2021 07:05 AM) with main KB article I was really considering with Edge known update statuses, I can finally confirm I found a definitive answer also to my last past assumption about the (annoying) always indefinitely rolling icon seen while 'Checking for updates' remained displayed forever.
That was indeed another issue and only today I also definitely discovered it was related to running a 'partially only' updated 'MicrosoftEdgeUpdate.exe' (again by 'partially only' I mean to indeed have previous 'MicrosoftEdgeUpdate.exe' v1.3.147.37 still running one together with only its main supporting DLL 'msedgeupdate.dll' correctly updated to v1.3.151.27 as expected, but nevertheless and strangely enough :-s 😛 inside 1st main log file listed below reported version is v1.3.151.27).
So for everyone's sake here's how I found it out and then finally & definitely solved it (apologies in advance if it may seem long, but I'm already summarizing all at my best).
At first I had to spent quite some time checking contents of the 2 main log files updated regularly (C:\ProgramData\Microsoft\EdgeUpdate\Log\MicrosoftEdgeUpdate.log) and only during updates (C:\Windows\Temp\msedge_installer.log) and since 1st file still continued to be updated properly even while 'Checking for updates' status never changed and I indeed received Edge updates, I decided to only focus on it.
So this (early) morning I found which component ('MicrosoftEdgeUpdate.exe' /broker) normally logging inside it, instead stopped updating it properly (since 08/20) even if it was still running since then (& probably simply just stuck in memory).
After checking all handles it had open (& luckily not locking itself either), I renamed it then copied its updated v1.3.151.27 version in same execution path (C:\Program Files (x86)\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe) and assigned same file ownership (SYSTEM) of old file, then manually forced closing all few handles it still had opened (those listed by handle64 SysInternals as File at 1st, then all remaining listed as Section) and finally forced closing it.
I was also quite surprised to see that it self-started running again for about 14minutes more, but this time it was indeed v1.3.151.27 updated version and at the end it also properly quitted from memory (as typically expectable and already done in the past).
At the end I started Edge (still v93.0.961.52) then opened Settings -> Help and feedback -> About Microsoft Edge and voilà 'Checking for updates' status changed almost immediately since it found a new update and started downloading it, so once it completed I pressed (expected) [ Restart ] button and so now I'm already on v94.0.992.31 😄 (but quite strangely enough new 'welcome tab' that self opened still looks empty).
Regards
Rob
SwimmeRM I can confirm your findings, that the copy of MicrosoftEdgeUpdate.exe is not the latest version (mine is 1.3.117.15) with the latest one resides in a folder, and the same is true for Google Update, so I will expect this is the default behavior. I have no problems updating both browsers so far, if you cannot update you may want to do a repair.
Process Explorer screenshot showing the MicrosoftEdgeUpdate.exe running.
Yes, Edge and Chrome are installed in "Program Files (x86)" while they are already 64-bit...
Regards,
Ken
KenChongOK, many thanks for confirming that what I reported seems to be normal (while it logically shouldn't :-)) ) and also that other effects I noticed were simply inherited from Chromium port).
About update delay to v93.0.961.44 I was experiencing, this morning I better verified what was preventing that to complete.
It was 'Startup boost' that even if already disabled and with only 'Use hardware acceleration when available' left enabled was leaving 2 msedge.exe instances still running and also creating a dump after I resumed my laptop that was only suspended in memory (and even before any MS Edge window was restarted), and about this I already sent 1 feedback (specific) and 1 also another (only minorly related to specific one).
Now about 'Use hardware acceleration when available' my very basic assumption and subsequent related understanding was that it simply meant 'OK, if any component you have has HW acceleration embedded just be ready to use it' (in my case it should just be laptop internal Realtek NIC card, and its NVIDIA GPU with its own 3GB DDR3 dedicated video memory for sure, but maybe also only minorly for its internal Intel Centrino Wi-Fi miniPCI card) while from such result its real meaning is 'OK, if any component you got has HW acceleration embedded then alway just start immediately using it without interruptions' but the problem is that from result I saw (and reported here) so far this setting is not aware of any already pending update needing to complete (at least until v93.0.961.38, with now correctly updated v93.0.961.44 I still have to check) and so it simply also prevented it to complete properly.
So now, if with v93.0.961.44 still hasn't happened, my hope is that that 'Startup boost' (disabled) with even just only 'Use hardware acceleration when available' enabled (maybe a slightly even better rewording would be 'Always use hardware acceleration when available') can soon be made fully Edge update aware so that it would also be able to switch to 'whenever an update is just pending MS Edge restart to complete, then temporarily close my background instances anyway' and then 'simply self-restart again my background boosting instances after some delay' while 'also making sure that pending version upgrade indeed took place as intended and expected'.
P.S. About 'MicrosoftEdgeUpdate.exe' I hope it can be fixed soon to ensure running version is updated correctly, I noticed v1.3.151.27 also comes with MicrosoftEdgeUpdateBroker.exe, MicrosoftEdgeUpdateComRegisterShell64.exe, MicrosoftEdgeUpdateCore.exe and MicrosoftEdgeUpdateOnDemand.exe additional components (& with very interesting names too) but for now I'll avoid to try to use them anyway (unless obviously anyone else might be willing :-)) to add just some little more basic details to let us all know about their intended proper usage...)
Regards
Rob
KenChong again
OK now I also made more tests with v93.0.961.44 and maybe I found a repro of what I indeed already saw earlier even with v93.0.961.38.
Now I started with all 'Startup boost' settings disabled, then enabled both 'Continue running background extensions and apps when Microsoft Edge is closed' and 'Use hardware acceleration when available' (and when this last one also displayed a [ Restart ] button below option I decided to restart immediately with it).
Then after restart (MS Edge indeed reopened into same edge://settings/system page) I only disabled 'Continue running background extensions and apps when Microsoft Edge is closed' and again left 'Use hardware acceleration when available' enabled (just like I did with v93.0.961.38 when I 1st succeeded in stopping new dump creation every time after my laptop resumed from suspension in memory) and then closed MS Edge again and immediately I verified that again it left no msedge.exe instances running.
But at this point I'm also wondering what reasons might have left those 2 running instances in the past.
Maybe it happened because at least 1 time when I closed MS Edge I may have left some tabs with my account authenticated and validated still opened (i.e. probably Outlook.com and MS Edge Insider Community ones even if they might temporarily been left in a suspended state because I set tabs to fade to sleep after '5 minutes of inactivity') and so MS Edge might have tried to always keep status for those validated sessions as still active even if later those tabs were already simply closed properly (so even if without really signing off my account).
So if this assumption might be correct (even partially) then when 'Continue running background extensions and apps when Microsoft Edge is closed' is disabled MS Edge should probably also need to receive some more specific user additional confirmation that he/she would still really want to continue to keep any validated session status as active even for those validated tabs that were already closed without their account signed-off properly.Regards
Rob
