[German]The release of Microsoft Edge 102.0.1245.30 causes startup problems for some users, which are not fixed even in the successor versions, according to my knowledge. A blog reader has probably found the cause – it may be due to the "Hardware enforced stack protection" option, which causes problems on systems with AMD CPU. However, I also have reports that Intel machines are affected.
Since the Microsoft Edge 102.0.1245.30 was released, individual users have reported that the browser no longer wants to start. I had addressed the issue in the German blog post Microsoft Edge 102.0.1245.30 ff. öffnet sich nicht. The report went back to a thread in the Microsoft Answers forum, where Edge startup issues with Dell computers (with Intel CPU) were reported. There it was said that it only affected individual models, whereas other users named various Dell computers, HP ProBook G8, but also Lenovo ThinkPads. In the German blog post, reader Dietmar had reported in this comment also Edge browser instances not starting.
A user report
In my German blog post Microsoft Edge 102.0.1245.30 ff. öffnet sich nicht Michael Heinrich then reported with additional information in the following comment.
As already written in this Microsoft forum, I found the problem with the event log under Microsoft-Windows-Security-Mitigations/Kernel Mode with the event 12.
In our case our VMware DEM profile manager tries to load an unsigned DLL.Process '\Device\HarddiskVolume4\Program Files (x86)\Microsoft\Edge\Application\msedge.exe' (PID 15792) was blocked from loading the non-Microsoft-signed binary '\Program Files\Immidio\Flex Profiles\FlexHook64.dll'
I think for others it is other unsigned DLLs which have the problem here.
Update: The TeamViewer tv_x64.dll is also included.
In the Microsoft forum Michael Heinrich has posted detailed excerpts from the event logs and shows that DLLs are blocked there. Michael Heinrich suspects that apparently something has changed on Edge or Windows in an update on the subject of exploit protection, because nothing has changed on the VMware application, and it does not affect all clients. He describes here in the blog as a woraround to open the Edge once via this way:
"C:\Program Files (x86)\Microsoft\Edge\Application\102.0.1245.39\msedge.exe"
Afterwards Edge works temporarily (short term).
Hardware enforced stack protection
In an update to his comments, Michael Heinrich states that further tests have shown that possibly only the item:
""Enable hardware enforced stack protection" -> Status "Off".
in the Windows Exploit Protection has to be set. The problem could be created and bypassed reproducibly in such a way with him in the change. Furthermore, he suspects that the problem apparently only affects AMD devices of the latest generation. However, this is contrary to the user messages in this thread on the Microsoft Answers forum, where Intel systems are also affected. I have now escalated the thread on Microsoft Answers to the Microsoft moderators and asked them to inform the product group about the problem.
Michael Heinrich has added the following comment within my German blog (I've translated the text).
I can now say with certainty that in our case this was due to loading the usersettings when starting msedge.exe.
The VMware DEM has two possibilities to load usersettings as profile manager: Once when the user logs in or when the application is started.
These possibilities can be controlled in the VMware DEM Console depending on the application.
Here we had set as a trigger that the profile data is imported with the start of the application"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"
The DLL from VMware loaded with this function via Edge triggered the "Hardware enforced stack protection" and closed the EDGE application again.
It lies in the function of the thing, that naturally over this way (depending upon user also larger) data are reloaded.
Apparently exactly this is considered "suspicious" in the current Edge/Windows version.
I must say that the DirectFlex function of VMware has always worked very reliably. We have now switched to loading the settings at login as a workaround, so there was nothing more to complain about for the "hardware enforced stack protection".
I suspect in the other cases, that other applications which are loaded directly with the msedge.exe trigger the same effect.
Many thanks to Günter Born for the escalation on the MS Community page!
Cookies helps to fund this blog: Cookie settings