[English]Blog-Leser haben auf ein Problem mit dem Microsoft Edge-Browser ab Version 151.x hingewiesen. In bisher nicht näher eingrenzbaren Szenarien stürzt der Browser unter diversen Windows-Versionen nach dem Start ab, während er in anderen Systemen weiter läuft. Ergänzung: Es gibt möglicherweise einen Workaround.
Microsoft Edge Version 151.x
Der Microsoft Edge Version 151.x wurde laut dieser Microsoft Release-Notes-Seite zum 30. Juli 2026 mit zahlreichen Neuerungen veröffentlicht. Die Kollegen von deskmodder.de haben zum 1. August 2026 in diesem Beitrag das Rollout der Version 151.0.4129.59 angesprochen.
In diesem reddit.com-Post merkt jemand an, dass der Microsoft Edge 151 die Hardwarebeschleunigung bei Intel HD Graphics zu deaktivieren scheint. Könnte ein erster Hinweis auf die nachfolgend beschriebenen Probleme sein.
Windows 10 2016 LTSB: Erster Leserhinweis zu Abstürzen
Blog-Leser Ronni hat zum zum 4. August 2026 im Diskussionsbereich gemeldet und berichtet von Absturzproblemen. Ich ziehe die Information nach hier, da ich den Diskussionsbereich zyklisch aufräume. Aussage des Lesers war: "Bei unseren Windows 10 2016 LTSB stürzt der Edge-Browser seit Version 151.x nach dem Start nach ca. 5 Sek. wieder ab. Bei 2019 LTSC und Win 11 tritt das nicht auf. Der Leser verwies auf die nachfolgende Diskussion bei Microsoft und fragte: "Noch jemand das Problem und ggf. einen Workaround (ohne Rollback zu 150.x)?".
Gleiches Problem mit Windows 10 Pro mit ESU
Blog-Leser ChristophH hat sich in einer Antwort auf obigen Post mit "Gleiches Problem hier mit Edge auf Windows 10 Pro mit ESU" gemeldet. Der Leser schreibt, dass der
Edge Stable 64-bit Version 151.0.4129.59 kurz einige Edge-Prozesse startet. Diese werden nach wenigen Sekunden wieder beendet, und die Browser-UI wird nicht sichtbar.
Temp-Profil hilft nicht
Der Leser hat versucht, ob ein Temp-Profil hilft, aber das funktioniert auch nicht. Nur Downgrade auf Version 150.0.4078.110 hat geholfen. Das Problem ist auf diesem Rechner nachvollziehbar, denn ein erneutes Update auf den Edge 151.0.4129.59, und das Problem ist wieder da.
Microsoft hat diesen Artikel mit allgemeinen Hinweisen zur Problemdiagnose von Edge-Abstürzen veröffentlicht. Dieser schlägt auch ein Temp-Profil und weitere Maßnahmen vor, die aber nicht zu helfen scheinen.
Admin-Rechte helfen
Das Problem tritt laut Leser bei einem Standard-Nutzer ohne Administrator-Rechte auf. Interessant ist die Beobachtung von Christoph: Meldet sich der Benutzer interaktiv mit einem Admin-Konto am Rechner an, funktioniert der Edge 151.0.4129.59.
Tritt nicht auf allen Rechnern auf
Blog-Leser ChristophH schreibt, dass die betroffene Edge Version 151.0.4129.59 auf dem betroffenen Rechner mit Windows 10 22H2 am 31.7.2026 installiert wurde. Das Problem wurde erst zum 4. August 2026, beim Login des Anwenders am Wochenanfang wirksam.
Laut Blog-Leser gibt es in seinem Umfeld aber hier Windows 10 Pro Maschinen (22H2) mit vergleichbarem Setup und dort funktioniert die Edge Version 151.0.4129.59 klaglos. Der Leser schließt daraus, dass noch ein weiterer, bisher unbekannter Faktor eine Rolle spielen muss, damit es zu diesem Fehlerbild kommt.
Diskussion in der Techcommunity zur Beta
Blog-Leser Ronni wies in seinem Kommentar auf die Diskussion Edge beta crashes after 5 seconds on some old versions of Windows 10 vom 20. Juli 2026 hin. Dort schrieb der Thread-Starter:
We have problems with Edge Beta versions 151.0.4129.15, 151.0.4129.21 and 151.0.4129.35.
On launch Microsoft Edge briefly opens and then closes (like in 5 seconds) on Windows 10 RS1/RS2/RS3. I can't reproduce problem on other versions of Windows 10, such as TH1 or RS4
Im Verlauf des Threads bestätigen weitere Nutzer das Problem. Ein Administrator schrieb, dass das gleiche Problem tritt auch bei der neuesten Edge-Version 151.x vom 31. Juli2026 auftritt. Dort sind 300 Geräte mit Windows 10 LTSB 1607 sind betroffen. Ein MSFT-Ticket wurde vom Poster erstellt und Crash-Dumps wurden an Microsoft übermittelt.
Meldung eines Betroffenen bei deskmodder.de
Bei den Kollegen von deskmodder.de hat sich ein Nutzer ebenfalls zum 4. August 2026 mit diesem Kommentar gemeldet und bestätigt die obigen Absturzmeldungen. Der Poster schreibt, dass sie in einem VW / Audi-Autohaus unter anderem noch ein paar Werkstatt-Tester mit Windows 10 Enterprise 2016 LTSB einsetzen. Dort stürzt der Edge nach 5 Sekunden ab und schließt sich.
Das Problem haben mittlerweile auch andere Händlerkollegen laut Poster bestätigt. Ebenso lässt sich die Fahrzeugdiagnose Software ODIS vom VW Konzern auf diesen Systemen nicht starten, wenn das aktuellste Edge WebView in der Version 151 installiert ist. Da hilft momentan nur ein Rollback auf die letzte Edge 150er Version.
Ein möglicher Workaround
Ergänzung: Beachtet als Betroffene diesen Kommentar von Thomas Buttinger weiter unten. Dessen Aussage ist, dass es an einer neuen TPM basierten Funktion liegt, die auf betroffenen Systemen nicht per DLL aufgelöst werden kann. Workaround ist, eine "neuere" tbs.dll nach
C:\Program Files (x86)\Microsoft\Edge\Application
zu kopieren – und bei Verwendung von Edge WebView2 auch ins Verzeichnis
C:\Program Files (x86)\Microsoft\EdgeWebView\Application\151.0.4129.59
einzustellen. Thomas hat eine DLL aus Windows Server 2019 verwendet.
MVP: 2013 – 2016
Läuft hier "rockstable" unter Win10 IoT Enterprise 2021 LTSC 21H2 & Win10 Professional 22H2 ESU jeweils aktuelle July Patchstände… sowohl mit Admin und ohne Adminrechte.
ESET Endpoint Security
Hallo!
Auch bei uns in der Firma ist auf diversen Laptops W10 Enterprise LTSB 2016 laufen und alle haben das Problem. Bis auf ein Gerät konnte ich auf den Edge 150.* downgraden, sodass die Software wieder lief.
Bei diesem verlangt der Installer eine msi Datei, aber egal welche Version – er mag diese nicht.
Interessant ist, dass die Software eigentlich auf Webview2 zurückgreift. Diese war noch auf 150 und der Edge schon auf 151 und die Software lief noch.
Zu Glück nutzt die Software wohl den Edge für die Darstellung, wenn Webview2 nicht zur Verfügung steht. Einen Download für Webview2 150.* ließ sich nicht installieren.
Wir sind ebenfalls betroffen. VW ODIS Tester mit WIN10 Enterprise 2016 LTSB. Edge stürzt nach ca. 5 Sekunden ab.
Ist eh zum 13.10.26 EoL mit der 2016 LTSB?
Ich würde die Extended Stable Version vom Edge verwenden.
Meldungen bei Reddit zu diesem Problem, ohne Ursache und ohne Lösung:
"Edge closing on its own."
*https://www.reddit.com/r/MicrosoftEdge/comments/1vd2w3k/edge_closing_on_its_own/
"is it just me or is this release very unstable and laggy"
*https://www.reddit.com/r/MicrosoftEdge/comments/1vcik8k/comment/p13u1h7/
—
GB: Danke für die Links
Absturzberichte (Dumps) werden in folgendem Ordner gespeichert:
C:\Users\UserName\AppData\Local\Microsoft\Edge Dev\User Data\Crashpad\reports
Anschauen kann man sich diese Absturzberichte im Edge mit folgendem Befehl:
edge://crashes/
Wenn Edge allerdings abstürzt, dann kann man sich diese Absturzberichte so nicht anschauen.
Bei mir stürzt Edge 151.0.4129.59 nicht ab auf LTSC 2021 (eingeschränkter Standardbenutzer, also keine Adminrechte) und der Reports-Ordner ist leer.
Ich habe allerdings in den Edge-Einstellungen (Zahnrad oben rechts) die Inhalte, Feeds, Direktlinks und Hintergrund abgeschaltet und im Gruppenrichtlinieneditor einige GPOs zur Unterdrückung von unerwünschtem Verhalten aktiviert bzw deaktiviert.
Zum Beispiel Synchronisierungen, Verlauf-Uploads, Telemetrie-Uploads, Kampagnen, Shopping etc.
Eventuell haben die Abstürze mit solchen Funktionen etwas zu tun, etwa ein verseuchter Feed, der nur für einen auserwählten Kundenkreis angezeigt wird oder es ist eine experimentelle Kampagne?
Was steht denn im Event-Log?
%windir%\system32\eventvwr.msc
Edge benutze ich normalerweise nicht, sondern den Firefox 140 ESR.
Im Event-Viewer:
Windows-Protokolle,
Anwendung,
Spalte "Quelle": edge
Da müsste eigentlich irgend eine Fehlermeldung stehen bei dem betreffenden Datum und Uhrzeit, wo der Absturz passierte.
Danke für die Rückmeldung. Im Eventlog stand nicht viel brauchbares dazu drin (war schon spät gestern und aktuell habe ich keinen Zugriff darauf). Versuche dann heute Abend Eventlog und Crashpad-Ordner auszuwerten. Das könnte funktionieren wenn man nach dem Crash dem betroffenen User temporär lokale Admin-Rechte gibt, da Edge gemäss Versuch von gestern mit dem lokalen Adminkonto startete.
Bisher nur 1 von 60 PCs betroffen. Windows 11 25h2.
Endlich kommt etwas Bewegung rein. Bei uns ist das Fehlerbild auf allen Server 2016 reproduzierbar, während die PCs mit Windows 11 25H2 keine Probleme aufzeigen.
Welcher Fehler steht im Event-Viewer oder im Crashpad-Report?
Hallo zusammen,
wir hatten das gleiche Problem, sich schließender Edge nach etwa 5 Sekunden, aber nur auf Windows Server 2016 (1607). Neuere OS sind nicht betroffen. Wir konnten das Problem mit Hilfe einer Analyse von Claude Code lösen. Das Problem liegt wohl an einer neuen TPM basierten Funktion.
Zitat von Claude: "Zum Mechanismus: Der abstürzende Pfad ist die TPM-Schlüssel-Attestierung über ncrypt.dll/tbs.dll. Beide DLLs existieren auf Server 2016 und werden auch geladen — der Absturz kommt daher, dass Edge per LoadAllImportsForDll alle Delay-Load-Importe dieser DLL auf einmal auflöst. Fehlt davon auch nur ein einziger Export im 14393-Stand von ncrypt.dll (die Attestierungs-APIs wurden nach 1607 erweitert), schlägt der komplette Delay-Load fehl → Failure-Hook → CHECK-Abbruch."
Unser Fix, bis MS das Problem adressiert, ist, eine "neuere" tbs.dll nach "C:\Program Files (x86)\Microsoft\Edge\Application" zu kopieren. (Wir haben uns an einem Windows Server 2019 in C:\Windows\system32 bedient). Da Programme i.d.R. erst in ihrem eigenen Directory nach DLLs suchen, wird die richtige gezogen. Problem ist damit erst mal behoben. Wer Edge WebView2 verwendet, muss das gleiche machen und die tbs.dll ins Verzeichnis "C:\Program Files (x86)\Microsoft\EdgeWebView\Application\151.0.4129.59" kopieren.
Viele Grüße
Thomas
—
GB: Danke, habe mal am Artikelende und im englischen Beitrag darauf hingewiesen.
Hallo Thomas B.!
Ich habe das mit der tbs.dll gleich mal probiert und das mit Erfolg. Nun läuft die Software (@Jens Donath: auch ODIS) wieder. Auch der Edge bleibt scheinbar offen.
Ich habe erst einmal den Updateserver mittels DNS Sperre für den Edge gesperrt, sodass sich nicht ein erneutes Update einspielt.
Hierzu habe ich einfach folgende Server umgeleitet:
edge.microsoft.com
msedge.update.microsoft.com
Vorsicht: Dadurch werden auch andere Funktion beschränkt (z.B. Translator)
Grüße und nochmal Danke!
Thomas H.
Danke für den Hinweis auf die tbs.dll.
Ich habe mal die tbs.dll mittels folgendem Befehl für unterschiedliche Windows-Varianten verglichen:
dumpbin.exe /exports tbs.dll
Das Tool dumpbin stammt von dort:
*https://github.com/Delphier/dumpbin/releases/tag/v14.50.35722
Die Windows-Varianten sind:
A) Windows 10 Enterprise LTSC 2021, x64, Build 10.0.19041.7548 (Juli 2026)
B) Windows 10 Enterprise LTSB 2016 (English) x64, Build 10.0.14393.0
C) Windows Server 2016 (Build 14393.0) RTM
Variante A hat tatsächlich 2 Funktionen mehr in der tbs.dll im Vergleich zu B und C (wobei B und C absolut identisch sind):
Tbsi_Get_TCG_Log_Ex
Tbsip_TestInterruptInformation
Insgesamt hat A 21 Funktionen und B und C haben jeweils nur 19 Funktionen.
Mit A funktioniert der Edge 151.0.4129.59, mit B und C funktioniert Edge nicht.
Es sollte für Microsoft kein Problem sein, diese beiden Funktionen für B und C nachzurüsten.
In der Datei msedge.dll
im Ordner
c:\Program Files (x86)\Microsoft\Edge\Application\151.0.4129.59\
findet man tatsächlich einen Aufruf der Funktion "Tbsi_Get_TCG_Log_Ex"
aus der tbs.dll.
(das kann man ganz einfach im Total Commander mit der F3-Taste (für "Anzeigen") im Binär-Modus und dann STRG+F für "suchen" finden oder mit jedem anderen Hex-Editor)
Wenn diese Funktion in der tbs.dll fehlt dann kracht der Edge an dieser Stelle zusammen.
Die andere Funktion
"Tbsip_TestInterruptInformation"
hingegen wird in der msedge.dll nicht aufgerufen.
Damit ist alles auf eine einzige Funktion eingegrenzt:
"Tbsi_Get_TCG_Log_Ex"
—
Diese Funktion macht folgendes:
"Gets the Windows Boot Configuration Log (WBCL), also referred to as the TCG log, of the specified type."
*https://learn.microsoft.com/en-us/windows/win32/api/tbs/nf-tbs-tbsi_get_tcg_log_ex
Dort steht auch die minimale Betriebssystemversion, wo es diese Funktion gibt:
"Minimum supported client Windows 10, version 1803 [desktop apps only]
Minimum supported server Windows Server [desktop apps only]"
Hier macht Microsoft einen weiteren Fehler, denn bei Server fehlt die konkrete Angabe der Version, da es diese Funktion für "2016" nicht gibt, wie wir hier selber herausfinden mussten.
Egal wo man auch hinschaut, Microsoft macht überall nur noch Fehler.
Funktion fehlt und die Dokumentation der Funktion ist auch noch fehlerhaft.
—
Das BSI meint zu dieser Funktion:
"In the context of the Windows loader, the TPM is used for integrity measurement and BitLocker operations.
The TPM stores the hashes calculated in the pre-OS environment and related data into a context known as the WBCL or "Windows Boot Configuration Log". A new WBCL is generated at every system startup since this is when new integrity measurements are made."
*https://www.bsi.bund.de/EN/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/AP5/SiSyPHuS_AP5.html
Ich verstehe deine Analyse nicht so ganz:
Zitat:
"Fehlt davon auch nur ein einziger Export im 14393-Stand von ncrypt.dll (die Attestierungs-APIs wurden nach 1607 erweitert), schlägt der komplette Delay-Load fehl → Failure-Hook → CHECK-Abbruch." "
—
Wenn die Funktionen der ncrypt.dll Schuld sind, warum reicht dann ein Austausch der tbs.dll, ohne auch die ncrypt.dll auszutauschen?
Oder habe ich dich falsch verstanden und die ncrypt.dll muss ebenfalls ausgetauscht werden?
Anderes Problem: wenn die Edge Security Baselines aktiviert sind, kann nicht mehr gedruckt werden.
Zwei der hinzugefügten Registry-Einträge sind hierfür verantwortlich. Falls jemand nicht so lange suchen möchte, wie wir :)
Es wäre gut, wenn du die beiden Registry-Einträge dazuschreiben würdest.
Moin,
wir hatten auch dieses Problem und nach einen Tag suchen, habe ich diese beiden Reg Einträge aus der Baseline von Edge entfernt, danach war das Drucken aus dem Edge wieder möglich.
Software\Policies\Microsoft\Edge\ApplicationBoundEncryptionEnabled
Software\Policies\Microsoft\Edge\DynamicCodeSettings
Grüße
Kai
Ja die wüsste ich auch gerne, suche schon seit Montag nach ner Ursache. ^^
Moin,
wir hatten auch dieses Problem und nach einen Tag suchen, habe ich diese beiden Reg Einträge aus der Baseline von Edge entfernt, danach war das Drucken aus dem Edge wieder möglich.
Software\Policies\Microsoft\Edge\ApplicationBoundEncryptionEnabled
Software\Policies\Microsoft\Edge\DynamicCodeSettings
Grüße
Kai
Moin,
ja wunderbar, es hat gereicht, einen der beiden Werte auf "0" zu ändern.
Ein direktes Löschen war nicht notwendig.
FG
Chris
Die von Thomas B. beschriebene Lösung für Server 2016 funktioniert nicht für Windows 10 Pro 22H2. Die Datei tbs.dll ist auf allen Systemen mit gleicher OS-Version und Patch-Level identisch. Betroffen ist aber bisher nur ein System. Auf den anderen Systemen funktioniert die Version 151.x.
Das Windows Eventlog hilft nicht weiter. Dem betroffenen Benutzerkonto temporär Admin-Rechte geben auch nicht. Crash-Dump ist jetzt an Microsoft übermittelt. An Browser-Erweiterungen scheint es auch nicht zu liegen.
Was man noch versuchen könnte: was passiert wenn man auf einem betroffenen System einen neuen lokalen Benutzer (ohne Admin-Rechte) eröffnet. Funktioniert dann 151.x oder nicht? Mir fehlt jetzt gerade die Zeit das auch noch zu prüfen.
Es bleibt nur der Downgrade auf 150.x und abwarten was die nächste Version nach 151.0.4129.59 bringt.
Windows Server 2019 gibt es als Core-, Standard- und Datacenter-Edition. Von welcher Edition stammen die korrekten Dateien? Wie lauten die SHA256-Prüfsummen? Danke.
Die tbs.dll ist bei allen 4 Indizes (Varianten in der ISO) identisch (Index 1 = Core, Index 2 = Standard, Index 3 = Datacenter Core, Index 4 = Datacenter).
Die sha256-Checksumme ist auch egal, denn die ändert sich mit dem Patchlevel bzw der Buildnummer, aber bereits ab dem niedrigsten Patchlevel ist die tbs.dll gut genug und der Funktionsumfang ist identisch mit Variante A (Windows 10 Enterprise 2021 LTSC, siehe oben).
Nimm irgend eine tbs.dll vom Server 2019 oder höher oder von Win10 ab 1803 oder LTSC 2021, die passen alle auf jeden Fall bezüglich Funktionsumfang.
Natürlich ist ein möglichst hoher Patchlevel bzw Buildnummer besser bezüglich gefixten Sicherheitslücken.
Bisheriges Zwischen-Fazit:
1. [gelöstes Problem]
"Server 2016" und "Windows 10 LTSB 1607" sind betroffen, weil es die Funktion "Tbsi_Get_TCG_Log_Ex" erst ab Windows-Version 1803 in der tbs.dll gibt.
Die Datei tbs.dll in höherer Version in den Edge-Ordner oder WebView-Ordner kopieren und dieses Poblem #1 ist erledigt.
2. [bestehendes Problem]
Der Workaround mit den Administrator-Rechten hat mit der fehlenden Funktion in der zu alten tbs.dll gar nichts zu tun, sondern das ist dann ein weiterer Bug, dessen genaue Ursache wir bisher noch nicht kennen.
3. [bestehendes Problem]
Es muss noch einen dritten bisher unbekannten Bug geben, denn der bleibt bestehen, obwohl man die tbs.dll ausgetauscht hat und obwohl man Administrator-Rechte hat.
4.
Nach Möglichkeit sollte man auf Edge verzichten und einen funktionierenden stabilen Browser wie den Firefox ESR verwenden.
5.
Die Masse an Bugs in Windows und der dadurch entstehende Arbeitsaufwand, um Workarounds zu finden, ist im Prinzip Vergeudung von Arbeitskraft, denn ohne die Microsoft-Produkte hätte man alle diese Probleme gar nicht.
Deswegen sollte man nach Möglichkeit nicht nur auf Edge verzichten, sondern auch auf Windows.
Mit jeder kleinen Patchlevel-Erhöhung könnte Microsoft einfach mal eine neue Funktion irgendwo aus irgend einer der tausenden verstreuten dll benutzen, die vorher nicht benutzt wurde und in zu alten dlls auch gar nicht vorhanden ist und dann sucht man sich einen Wolf nach der Ursache für die plötzliche Verhaltensänderung und nach einem Workaround.
Inzwischen braucht man schon KI-Tools (Claude Code), um die Ursache auf einen Heuhaufen (dll) eingrenzen zu können. Dann braucht man zusätzliche Tools (Dumpbin und Hex-Editor und evtl noch Debugger wie IDA), um die Funktion in der dll zu identifizieren.
Danach erfolgt Studium der Microsoft-Dokumentations-Artikel, um die Version von Windows herauszubekommen, ab der es dann passen soll für den neuen Edge und in diesen Artikeln findet man dann auch noch weitere Fehler.
Wenn man sowas nicht als Hobby macht, dann ist die Toleranzschwelle überschritten.
Vernünftig und problemlos arbeiten kann man mit Windows so nicht mehr.
Mit LTSC 2021 und Firefox ESR geht es noch, aber das ist von Microsoft nicht erwünscht für Endkunden.
Auf meinem privaten Notebook, das auf Windows 10 IoT Enterprise LTSC läuft, ist mir der EDGE tatsächlich nach dem Start abgeschmiert. Dachte mir nix weiters dabei, Reboot, ging wieder. Läuft übrigens auch eine VW Diagnose drauf, aber die für Hobbyschrauber und kleine Werkstätten, namens VCDS…
Sonst keine Probleme, wir haben beim Kunden sogar noch einen Server 2016, sonst alles auf W11 25H2 umgestellt.
Moin, wir haben die tbs.dll aus einem 10 LTSC aus Windows\System32 geholt und dem LTSB-Edge untergeschoben. Für WebView steht es noch aus.
Ist es so umständlich bzw. zu viel, dem Edge-Update noch eine Prüfung des Zielsystems mitzugeben?
VG Steffen
Mit dem EWV funktioniert es ebenso. Bei uns kam noch hinzu, dass wir kurz vorm Auftreten des Problems Update für W10 losgelassen haben.
Schauen wir mal, wie lange der Tanz anhält.
Hallo,
ich habe leider auch das Problem auf mehreren Windows 10 LTSC Clients.
Jetzt wollte ich das Workaround mit der tps.dll anwenden, nur leider finde ich diese auf verschiedene Server Versionen nicht.
Könnt ihr bitte helfen. Danke.
VG
Bei meinem WSE 2016 trat das Problem auch auf und konnte durch die tbs.dll von einem Windows 10 LTSC 2021 genau wie beschrieben gelöst werden. Vielen Dank für den Tipp!
https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel#version-1510412972-august-06-2026-stable
Version 151.0.4129.72: August 06, 2026 (Stable)
Fixed various bugs and performance issues.
Ob dieses Problem damit behoben ist, kann ich nicht sagen da wir nicht davon betroffen sind
Ich konnte das Problem ebenfalls mit dem einfügen der tbs.dll aus einer Windows 11 Pro Version 10.0.26200 Build 26200 beheben. Edge stürzt jetzt nicht mehr ab und ODIS ebenfalls nicht mehr. Vielen Dank für die Hilfe!
Bei mir weicht allerdings der Pfad beim EdgeWebView ab:
C:\Users\\xxxxxx\\AppData\\Local\\Microsoft\\EdgeWebView\\Application\\151.0.4129.59\
Laut unseren Support wurde mit der EDGE Version 151.0.4129.72 das Problem gefixt.
Kann ich bestätigen. Danke Jens fürs Testen und Bescheidgeben.
Bei uns konnte das Problem mit dem einen Windows 10 22H2-Rechner, wo auch nur ein Benutzerprofil betroffen war, nicht mit dem Update auf die Version 151.0.4129.72 gelöst werden. Am Ende hat ein Update der NVIDIA-Grafiktreiber auf eine aktuelle Version geholfen. Nun läuft auch Edge Version 151.0.4129.72. Es scheint so, dass Edge 150.x noch mit einigen Bugs (oder fehlenden Features) im Grafiktreiber klar kam, 151.x aber nicht mehr. In den Release-Notes zu Edge 151.x gibt es auch Hinweise das es Änderungen im Bereich Grafik/GPU gab.
Tipp:
Wer immer noch auf vereinzelten Rechner 151.x nicht zum Laufen bekommt, schaut ganz am Ende einer Edge Crashpad-Datei (.dmp) mit einem Editor rein. Auch wenn das meiste Binary-Hieroglyphen sind, am Ende stehen ein paar Zeilen im Klartext drin. In unserem Fall gab die Zeile
"exception_code 0xc0000005 exception_module_path6 C:\Program Files\NVIDIA Corporation\nview\nViewH64.dll" den Hinweis wo das Problem zu suchen war.
Ergänzung: am 9.8.2026, später Abend, wurde die Version 151.0.4129.78 freigegeben. Diese ist jetzt hier installiert, nicht .72 vom 6.8.26.