[English]Ich stelle mal einen Leserbericht über Probleme mit Windows hier im Blog ein, in der Hoffnung auf weiteres Feedback, ob das auch beobachtet wurde. Der Leser betreibt verschiedene Hardware mit unterschiedlichen Windows-Systemen. Er hat sich zum 24. Juni 2025 gemeldet, weil plötzlich einzelne System mit BlueScreens (WHEA_UNCORRECTABLE_ERROR) aussteigen.
Anzeige
Plötzlich BSODs Stop-Code 0x00000124 in Windows
Marc schrieb mir auf Mastodon, dass sie ~4000 Windows-Installation bei Kunden betreuen. Zum 24. Juni 2025 sind ihm mehrere Windows-Systeme mit dem gleichen BlueScreen-Fehler WHEA_UNCORRECTABLE_ERROR ausgestiegen.
Der BSOD WHEA_UNCORRECTABLE_ERROR steht für den Stop-Code 0x00000124. Ich hatte 2018 mal im Blog-Beitrag Windows 10: Abstürze bei HP ProBook 455 G4 (0x00000124) etwas zu diesem Fehler geschrieben. Dieser BSOD bedeutet, dass ein schwerwiegender Hardwarefehler aufgetreten ist.
Ausgelöst wird das Ganze von der Windows Hardware Error Architecture (WHEA). Wenn man nicht postuliert, dass jetzt plötzlich Hardware kaputt geht, deutet der Stop-Code auf Treiber-Probleme (ggf. verursacht durch ein Update) hin.
Uneinheitliche Hardware und Windows-Versionen
Aktuell liegen mir noch keine Informationen über solche Treiber-Updates durch Windows Update vor. Der Leser schrieb mir, dass eine ziemlich gemischte Hardware (Clients und Server) betroffen sei:
Anzeige
2x Lenovo Workstations
2x HP Workstations
1x Lenovo ThinkPad-Notebook T590
Und das Verrückte ist, dass auf diesen fünf betroffenen Systemen durchaus unterschiedliche Windows-Versionen laufen. Marc gibt folgende Versionen an:
Windows Server 2019
Windows 10 Clients
Windows 11 Clients
Später meldete er sich, dass er noch drei Maschinen im Büro hatte, die ebenfalls auf diesen Fehler liefen.
Quick & Dirty-Workaround
Der Quick & Dirty-Workaround, der die betroffenen Systeme zum Laufen brachte, war laut Leser, dass Tool Driver Easy zu verwenden, um einen Scan durchzuführen und dann die Treiber der Maschinen zu aktualisieren.
Weiterer Fund im Internet
Die Frage an die Leserschaft lautet nun, ob dies ein bedauerlicher Einzelfall war (bei acht Systemen eigentlich unwahrscheinlich), als Zufall einzustufen ist, oder ob es mehr Administratoren gibt, die BSODs mit obigem Stop-Code beobachtet haben.
Ich habe mal eine kurze Internetsuche versucht, bin aber auf kaum aktuelle Treffer von Juni 2025 gestoßen. Es gibt lediglich den Microsoft Answers-Forenthread WHEA uncorrectable error BSOD 2025 vom 8. Juni 2025 zu Windows 11, wo so etwas beschrieben wird. Dort kam Driver Booster zum Einsatz – und das Tool ist für Probleme bekannt (es waren wohl veraltete Treiber die Ursache).
Was mir in diesem Kontext auch noch im Kopf herum geht: Kann der BSOD durch das Tool Driver Easy verursacht worden sein? Mir geht mein Beitrag Digitales Schlangenöl: Registry-Cleaner, Driver-Updater & PUPs aus 2013 gerade im Kopf herum.
Anzeige
Gemischte Hardware könnte irrelevant sein. Mögliche Gemeinsamkeiten (ohne weitere Informationen!):
Selber RAM, insbesondere wenn die Workstations Tiny/Mini Ausgaben sind
Selbe CPU
Unterschiedliche CPU/Selber Grafikchip
Selber dedizierter Grafikchip
Selber Audiochip
Selbe sonstige verbaute Chips/Hardware
Selbe Stromversorgung/Netzteil
Selbe angeschlossene Hardware/-Verbindung
_________________________________________
Wenn man die "verrückten" Systeme anschaut, würde ich vom Zeitpunkt her prüfen ob die Clients Einstellungen haben für (weiß nicht ob man das alles trennen kann!):
Automatisch Vorab Updates Installieren
Automatisch Optionale (OS) Updates Installieren
Automatisch Optionale Treiber Updates Installieren
Kürzlich selber Fehler – hier irgendwas mit Intel Chipsatz (Defekt/Treiberproblem?):
[ (spanisch) https://answers.microsoft.com/es-es/windows/forum/all/error-0x00000124-solo-ocurre-en-vrchat/518cce51-22d7-45eb-b029-00eace0826fd ]
Kürzlicher Windows Insider WHEA-Fehler (ohne angegebenen Code!):
[ (englisch) https://www.reddit.com/r/windowsinsiders/comments/1l2bo9o/windows_insider_green_screen/ ]
_________________________________________
Infos:
[ (deutsch) https://learn.microsoft.com/de-de/windows-hardware/drivers/debugger/bug-check-0x124—whea-uncorrectable-error ]
[ (englisch) https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x124—whea-uncorrectable-error ]
_________________________________________
Support:
[ (englisch) https://www.techsolutions.support.com/how-to/fix-the-0x00000124-whea-uncorrectable-error-bsod ]
Habe einen HP Z4G4 der seit der Installation der Juni Updates mit verschiedensten BSODs und verschiedenen Systemstein aussteigt
IRQL not less or equal
System Service exception
critical process died
…
im abgesicherten Modus läuft er stabil, da kann es auch nur Treiber sein.
aber den zu identifizieren ist aufgrund der absolut zufälligen systemdatei die im bsod angezeigt wird keine Freude…
Was auch eigenartig ist, lässt man den Client im Sperrbildschirm stehen, bleibt er online, sobald ich mich anmelde *boom* BSOD.
mit Autoruns schon alles aus dem Systemstart entfernt was geht, sfc und chkdsk finden keinen Fehler…
bin ratlos, was ich machen soll.
Versuch mal neue Chipsatz- und Prozessortreiber zu installieren. Veraltete Treiber werfen hier gerne „bunte" Bluescreens.
Eventuell kannst du auch etwas in den Dumpfiles finden. Die Microsoft-App zur Auswertung heißt WinDbg und ist im Microsoft Store verfügbar.
Liebe Grüße
Bei HP-Hardware deaktiviere ich -sofort vor allen MS-Upddates- immer dieses hier (*siehe Bild) und so nie Probleme, da dann diese ganzen "HP-Telemetrie-Drv's" usw. erst gar nicht installiert werden.
https://jmp.sh/s/fEXiyPGR3idKwsi0sXwg
BSOD Meldungen ohne den Dump sind leider ziemlich wertlos, man muss schon im Detail mit WinDBG schauen, was genau die Ursache je System war.
Tools wie Driver Easy würde ich jedenfalls nie anfassen, leider schiebt ja manchmal auch Windows Update alte Treiber unter, habe sogar schon erlebt, dass neuere korrekte Treiber durch ein Update durch alte ersetzt wurden die Probleme machten.
Ich behaupte, 99 % der Leute können mit WinDBG nicht arbeiten – ich habe das vor vielen Jahren aufgegeben, weil es abseits von Trivialfällen (die ich mit Nirsoft BlueScreen-Viewer auch auflösen konnte) extrem schwierig ist, die Ursache zu finden. Oft braucht man einen vollen Dump – den ich hier im Blog auch nicht einstellen will. WinDGB habe ich deshalb seit ewigen Zeiten nicht mehr auf meinen Systemen installiert. Und die Person, die mal Bücher über BSOD-Analyse geschrieben hat, ist leider vor einigen Jahren (kurz nach Renteneintritt) verstorben.
Das Beste, was bleibt: Der Blog-Beitrag triggert X Meldungen "hier, sind auch betroffen" – oder lässt am Ende des Tages den Schluss zu, dass das Treiber-Update-Tool die Ursache war, weil nicht kompatible Treiber-Versionen auf die Maschinen gedengelt wurden. Der Betroffene liest vermutlich hier mit und wird sich ggf. zu äußern können. Dann wäre es am Ende des Tages auch wieder eine hilfreiche Erkenntnis "für die Leserschaft" – imho.
Hm das mit WinDBG würde ich so nicht unterschreiben, während alle BSOD Viewer einen nur in die richtige Richtung führen, sieht man mit WinDBG wenigstens welche Datei schuld war.
Ich hatte zuletzt mal Abstürze und hätte ohne WinDBG nicht gesehen, dass es nun am Nvidia oder Intel WiFi Treiber lag, auch in Hilfeforen wird fast immer ein Dump gefordert wenn jemand nach Hilfe fragt.
Aber gut, dass ein Dump von Firmengeräten nicht gerne veröffentlicht wird, ist nachvollziehbar.
Aber wenn nun ein gemeinsam genutzter Drucker und dessen Treiber nun die Ursache währen, wie soll man das ohne genaue Analyse herausfinden?
Ich hatte jedenfalls schon viel zu häufig allgemeine Fehlermeldungen im Bluescreen stehen, die zwar nach Treiber riechen aber welcher es genau war, erforderte dann immer WinDBG und das Handling ist eigentlich ziemlich easy
Wenn Du in der Lage bist, a) den WinDGB mit den richtigen Symboldateien auf deinem Windows aktuell und funktional zu halten und b) auch den Disassembler mit den Stack-Aufrufen "richtig" zu verstehen, bin ich bei dir. Ich persönlich habe diese Fähigkeiten nicht mehr (in den 80er Jahren konnte ich um Mitternacht geweckt Maschinencode interpretieren). Nur grob die Abrufketten zu verfolgen und zu hoffen, dass die zuletzt benannten Dateien die Übeltäter sind, hilft manchmal, aber nicht immer.
Es gibt von mir aus 2012 die Artikelreihe zur BlueScreen-Analyse:
1: Windows BlueScreen-Analyse – Teil 1
2: Windows BlueScreen-Analyse – Teil 2
3: Windows BlueScreen-Analyse – Teil 3
die eine Anlaufstelle sein kann. Aus meiner Zusammenarbeit mit dem zwischenzeitlich verstorbenen Michael Bormann weiß ich, dass der Teufel oft im Detail liegt und die Ursache an ganz anderer Stelle liegt – speziell, wenn Chipsatz-Treiber dazwischen funken, und Windows an einem anderen Treiber dann den WHEA-BSOD wirft. Von daher lasse ich "das Handling ist eigentlich ziemlich easy" hier einfach mal offen. Interessierte Leser haben mit den obigen drei Links einen ersten Anlaufpunkt. Wenn die es dann als "easy" erachten – fein. Ich ziehe mich diesbezüglich auf die Position des Theoretikers zurück und überlasse den Praktikern aus dem Feld zu Niederungen der Fehlersuche ;-).
Seitdem es die App von "WinDbg" gibt ist das einfacher geworden. Wenn man diese Installiert verknüpft sie Windows automatisch mit dem Dateitype ".dmp" Ein doppelklick öffnet die "WinDbg" App.
Das manuelle festlegen von "Symbol Search Path" entfällt. Der Befehl "!analyze -v" wird in vielen fällen als Hyperlink angeboten.
richtig und ein kurzes .symfix und .reload vor dem !analyze -v aktualisiert notfalls auch schnell die Symbollinks, falls damit was schiefläuft
Ist hier wegen fehlendem Store und fehlendem winget nicht so trivial – daher Debugger-freie Zone ;-)
*ttps://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx
*ttps://aka.ms/Microsoft.VCLibs.x86.14.00.Desktop.appx
*ttps://github.com/microsoft/microsoft-ui-xaml/releases/download/v2.8.6/Microsoft.UI.Xaml.2.8.x64.appx
*ttps://github.com/microsoft/microsoft-ui-xaml/releases/download/v2.8.6/Microsoft.UI.Xaml.2.8.x86.appx
*ttps://learn.microsoft.com/de-de/troubleshoot/developer/visualstudio/cpp/libraries/c-runtime-packages-desktop-bridge#how-to-install-and-update-desktop-framework-packages
*ttps://github.com/microsoft/winget-cli/releases/tag/v1.11.400
https://store.rg-adguard.net
:) *gg
WHEA Meldungen mit Angabe der betroffenen Treiber finden sich im Ereignisprotokoll.
Bis jetzt hat mir eigentlich immer Bluescreen View von Nir Sofer genügt. Das Teil sieht sich die Minidumpdateien an und zeigt dann ziemlich zuverlässig, bei welchem Treiber Windows ausgestiegen ist: https://www.nirsoft.net/utils/blue_screen_view.html
Liebe Grüße
Ich kann dir ja mal testweise einen Minidump geben und du sagst mir – nur mithilfe von BlueScreenView – was den Absturz verursacht hat.
Hier der Link:
https://mega.nz/file/UYF0gAAA#-N2JnnkUULX9zR7aKR46auQISRuMAquMwX0nFV9MQuo
Kann ich so bestätigen, auch bei unseren Kunden bei 4 Windows 10-Maschinen der Fall, 3x betrifft es Terra Workstations, 1x ein HP Notebook.
Bei keinem war allerdings ein Programm wie Driver Booster oder ähnliches installiert.
Was uns allerdings aufgefallen ist, dass in allen 4 Fällen kein Dump erstellt werden konnte. In der Ereignisanzeige findet sich folgender Eintrag:
Fehler; Quelle: volmgr; Ereignis-ID: 161; Meldung: Erstellung einer Abbilddatei aufgrund eines Fehlers beim Erstellen der Abbildkopie fehlgeschlagen.
Das könnte sich mit dem spanischen Link, den ich ober angegeben hatte decken, wenn aufgrund eines (Treiber-)Fehlers beim Chipsatz-/Speichercontroller eben nicht auf die Platte geschrieben werden kann.
das hatten wir mal bei frischen Dell Systemen …
Ursache war die NVMe SSD (daher auch kein Dump nach Bluescreen).
Erst ein Bios / Firmwareupdate lieferte Abhilfe.
Ich vermute hier den PCIe Bus …
Baugleiche Systeme mit SATA SSD waren NICHT betroffen …
Nachtrag: wichtig bei dem Fehler sind die angefügten Parameter zur Analyse:
https://learn.microsoft.com/de-de/windows-hardware/drivers/debugger/bug-check-0x124—whea-uncorrectable-error
Wir haben ein paar Dell-Notebooks die seit dem Patchday mit Bluescreen crashen, laut der Meldung mit dem Treibernamen scheint es am Intel Grafik Treiber zu liegen, wir testen das gerade.
Danke für die Info. Vielleicht gelingt es ja doch den Verursacher heraus zu filtern.
Am 24.6. wurden die Preview Updates veröffentlicht.
Wurden diese installiert oder nicht?
Falls ja, warum?
Auf Produktionsrechner sollten nie Preview-Updates installiert werden, schon gar nicht auf Servern.
Bleibt das Problem bestehen, wenn man das letzte Update mit Hilfe der Wiederherstellungspartition wieder deinstalliert?
Tritt der WHEA Fehler beim Booten auf oder erst nach dem Start im Betrieb nach einer variablen Zeit?
Was meldet die Startprotokollierung?
entweder mit msconfig einschalten oder mit Konsole:
bcdedit /set {current} bootlog Yes
An dieser Stelle würde Linux seine Vorteile zeigen können, denn während des Bootens wird detailliert angezeigt, was gerade geladen wird und wenn er stehen bleibt sieht man in der letzten Zeile woran es liegt.
Die Windows-Startprotokollierung sollte das aber auch können, man muss es aber erstmal einschalten.
Enthalten die Updates neue Chipsatz-Treiber?
WHEA ist vermutlich CPU oder PCI-Bus Fehler und sowas wird durch Chipsatztreiber verursacht.
Zitat:
"Der Quick & Dirty-Workaround, der die betroffenen Systeme zum Laufen brachte, war laut Leser, dass Tool Driver Easy zu verwenden, um einen Scan durchzuführen und dann die Treiber der Maschinen zu aktualisieren."
Das ist so ungenau.
Es wäre hier wichtig zu wissen, welcher Treiber aktualisiert worden ist und welche Treiberversion funktioniert.
Zitat:
"Lenovo Workstations
HP Workstations"
Auch das ist viel zu ungenau.
Welches Modell, welche CPU etc?
Haben alle NVME-SSDs?
Der Fehler verschwindet vermutliczh in wenigen Tagen von alleine, denn die überlegene Microsoft-Telemetrie wird das Problem erkennen und KIR-Updates verschicken.
Bei meinem Vater kommt ein Bluescreen seit den letzten Windows 10 – Updates, auf einem alten Rechner. Allerdings kommt der Bluescreen erst wenn er den Rechner herunterfährt. Also stört es nicht den Betrieb und habe ich mir aus Zeitmangel daher auch noch nicht angesehen.
Auch deswegen wollte ich da auch noch nicht mit Windebug ran, weil es doch recht aufwendig ist. Ich habe das mal auf einem eigenen uralten Rechner (als ich noch Windows nutzte) verwendet und mit dem notwendigen Download diverser Header und zusätzlichen Befehlssätzen (die an den Computer angepasst sein müssen), wurde es nicht ganz einfach. Aber ich konnte damals das Problem in einem defekten Speicher finden..
WHEA Meldungen mit Angabe der betroffenen Treiber finden sich im Ereignisprotokoll.
Komischerweise auch nicht immer – leider schon oft genug erlebt. 🤷♂️
Die Frage ist doch wieviel Zeit wird da versenkt mit ner Ursachenforschung? Hab ich früher auch gemacht, mittlerweilen spiel ich innerhalb weniger Minuten ein System Abbild wieder ein und gut ist. Alte Platte raus neue rein, so hat man man dann doch noch die Möglichkeit zur Analyse.
Wenn das nicht hilft kann ich immer noch auf Fehlersuche gehen… aber Zeit vertrötteln?
Dafür ist das Leben zu kurz!
Kommt darauf an, was alles auf der Kiste ist.
In der Regel versuchen wir es max. 20 Minuten, wenn nicht, dann neu installieren.
bei uns ist ein Terra Server nicht mehr hochgekommen.. Problem ließ sich nicht lösen, Backup eingespielt (danke Veeam)