Windows 11 25H2 (Build 26200): Komplette Freezes mit Blackscreen, GPU verschwindet (Code 31), LiveKernelEvent 141

Jetzt hat es funktioniert. Darin befinden sich mehrere Logs und Screens, aber keine memory.dmp, da es sich ausschließlich um harte Freezes handelt.

Sehr verwunderlich, dass du keine Dumps findest. Schau auch mal im Windows-Verzeichnis nach dem Unterverzeichnis LiveKernelReports, ob du dort oder in Unterverzeichnissen von LiveKernelReports Dumps findest.

Die Logs zeigen nur, dass es massive Probleme mit Prozessor, RAM, Grafikkarte und dem fTPM des Rechners gibt, ohne etwas über die möglichen Auslöser herzugeben. Dazu werden die Dumps gebraucht.

Sind BIOS, Chipsatz-und Geräte-Treiber des Aorus Elite X3D auf aktuellem Stand? Sind CPU, RAM bzw. Grafikkarte übertaktet? Sind RAM-Module verbaut, die auf der QVL-Liste von Gigabyte stehen? Findest du alles hier: https://www.gigabyte.com/de/Motherboard/X870E-AORUS-ELITE-X3D/support

Moin,

vielen Dank nochmal für die schnelle Rückmeldung. In besagtem Verzeichnis fand ich tatsächlich die WATCHDOG-20260105-1644.dmp-Datei. An der Stelle bitte ich noch einmal Verzeihung, wegen meiner Inkompetenz.

Ich habe die Datei unter folgendem Link bereitgestellt:

https://drive.google.com/drive/folders/1lz2_to-37x68Eez9nl2ZSesWUwlgmdgO?usp=sharing

Ich nutze das neueste UEFI-Update (F5), den neuesten Chipsatz-Treiber von AMD und auch die von GIGABYTE bereitgestellten anderweitigen Treiber. Sowohl der Prozessor, als auch die Grafikkarte sind nicht übertaktet. Für den RAM nutze ich hingegen das EXPO-1-Profil, welches ich testweise aber auch über längere Zeit deaktiviert habe. Auch laut Memtest86 scheint der RAM komplett intakt zu sein.

Leider kann ich dir aktuell nicht helfen. Die Dump-Datei kann vom Debugger wegen eines im Dump vorhandenen Verweises auf ein nicht vorhandenes Zertifikat nicht geöffnet werden:

Du schriebst eingangs, dass für die Grafikkarte der Fehler 31 (Windows kann den Treiber nicht laden / nicht finden) im Geräte-Manager angezeigt wird. Mehrere Einträge in den zuvor gesendeten Logs weisen ebenfalls auf Probleme mit der Grafik hin. Aus der Ferne kann ich dir nur (spekulativ) empfehlen, zumindest den Elite X3D von Gigabyte checken zu lassen. Vieles spricht für Hardwareprobleme, die sich in den meisten Fällen auch nicht aus einem Dump heraus erschließen.

Hallo und vielen Dank, dass du dir meine Logs und die bisherigen Dumps angesehen hast.

Ich wollte noch eine wichtige neue Beobachtung ergänzen, die eventuell hilft, das Problem besser einzugrenzen:

Ich habe inzwischen CrashOnCtrlScroll (erzwungener Kernel-BugCheck per Tastenkombination) konfiguriert, um einen sauberen memory.dmp zu erzeugen. Dabei zeigt sich jedoch ein auffälliges Verhalten:

• Die Tastenkombination wird angenommen

memory.dmp wird erstellt

es erscheint kein Bluescreen

stattdessen kommt es zu demselben vollständigen Freeze wie bei den spontanen Hängern

anschließend wird ein LiveKernelEvent a2000002 protokolliert

Das Verhalten ist reproduzierbar und entspricht exakt den Freezes, die im normalen Betrieb auftreten. Der Kernel scheint den BugCheck-Pfad zu beginnen, verhakt sich aber währenddessen offenbar in einem Deadlock.

Der neu erstellte memory.dmp ist daher vermutlich inkonsistent (Hang-Dump, kein klassischer BSOD-Dump). Mir ist bewusst, dass er sich ggf. nicht sauber im Debugger öffnen lässt – ich stelle ihn dennoch zur Verfügung, falls sich daraus blockierte Threads, Locks oder Hinweise auf GPU-/Power-/PCIe-Pfade ableiten lassen.

Die zuvor genannten Symptome bleiben bestehen:

komplette System-Freezes ohne BSOD

teilweise GPU-Ausfall nach Reboot (Geräte-Manager: Code 31)

LiveKernelEvent a2000002 / 141

unabhängig von Last oder Anwendung

Falls du dazu eine Einschätzung hast, ob dieses Verhalten eher auf einen Kernel-/WDDM-/Power-Management-Deadlock hindeutet oder ob es bekannte Regressionen in neueren 26200-Builds gibt, wäre ich für jede fachliche Rückmeldung dankbar.

Vielen Dank nochmals für deine bisherige Unterstützung.Hallo und vielen Dank, dass du dir meine Logs und die bisherigen Dumps angesehen hast.

Ich wollte noch eine wichtige neue Beobachtung ergänzen, die eventuell hilft, das Problem besser einzugrenzen:

Ich habe inzwischen CrashOnCtrlScroll (erzwungener Kernel-BugCheck per Tastenkombination) konfiguriert, um einen sauberen memory.dmp zu erzeugen.
Dabei zeigt sich jedoch ein auffälliges Verhalten:

Die Tastenkombination wird angenommen

memory.dmp wird erstellt

es erscheint kein Bluescreen

stattdessen kommt es zu demselben vollständigen Freeze wie bei den spontanen Hängern

anschließend wird ein LiveKernelEvent a2000002 protokolliert

Das Verhalten ist reproduzierbar und entspricht exakt den Freezes, die im normalen Betrieb auftreten.
Der Kernel scheint den BugCheck-Pfad zu beginnen, verhakt sich aber währenddessen offenbar in einem Deadlock.

Der neu erstellte memory.dmp ist daher vermutlich inkonsistent (Hang-Dump, kein klassischer BSOD-Dump). Mir ist bewusst, dass er sich ggf. nicht sauber im Debugger öffnen lässt – ich stelle ihn dennoch zur Verfügung, falls sich daraus blockierte Threads, Locks oder Hinweise auf GPU-/Power-/PCIe-Pfade ableiten lassen.

Die zuvor genannten Symptome bleiben bestehen:

komplette System-Freezes ohne BSOD

teilweise GPU-Ausfall nach Reboot (Geräte-Manager: Code 31)

LiveKernelEvent a2000002 / 141

unabhängig von Last oder Anwendung

Falls du dazu eine Einschätzung hast, ob dieses Verhalten eher auf einen Kernel-/WDDM-/Power-Management-Deadlock hindeutet oder ob es bekannte Regressionen in neueren 26200-Builds gibt, wäre ich für jede fachliche Rückmeldung dankbar.

Unter dem Link kannst du nun auch die erzwungene memory.dmp-Datei finden:

https://drive.google.com/drive/folders/1lz2_to-37x68Eez9nl2ZSesWUwlgmdgO?usp=sharing

Vielen Dank nochmals für deine bisherige Unterstützung.

Der Fehler a20000002 deutet auf Probleme mit dem Grafiktreiber mit einem Blackscreen als Ergebnis hin. Da jedoch noch zahlreiche andere LiveKernel-Events gemeldet werden und das Schreiben des Dumps zu einem Blackscreen führt, tippe ich verstärkt auf ein HW-Problem.

Teste bitte, ob folgende Maßnahmen die Probleme beheben:

• Lade im BIOS (ggf. erneut) die Standardwerte für dein Board
• Deinstalliere im Geräte-Manager die Grafikkarte einschließlich der Treibersoftware und starte dann den Rechner neu.

Hey! Erst mal ein dickes Danke, dass ihr euch die Zeit nehmt und euch in mein Problem reinfuchst. Ich weiß das echt zu schätzen, da ich hier mittlerweile echt tief im Kaninchenbau stecke.

Um euch das Suchen zu ersparen, hier mal der aktuelle Stand meiner „Odyssee“. Ich habe versucht, wirklich alles auszuschließen – sogar Windows habe ich komplett frisch aufgesetzt.

Was ich schon alles durch habe:

Software & Windows:

Windows Clean Install: Komplett frisches System, keine Altlasten.

Treiber-Voodoo: Grafik- und Chipsatztreiber mehrfach mit DDU/AMD Cleanup Tool sauber entfernt und neu installiert (verschiedene Versionen probiert).

Hardware & BIOS:

BIOS-Check: Alles auf Standard (kein OC/PBO), neueste Version/AGESA ist drauf.

RAM: MemTest86 lief fehlerfrei durch; verschiedene Profile (EXPO/Auto) getestet.

PCIe-Bus: Fest auf Gen3, Gen4 oder Gen5 gestellt – leider ohne Erfolg.

Monitoring: Temperaturen und Spannungen sind absolut im grünen Bereich.

Warum ich glaube, dass es kein „normaler“ Hardware-Defekt ist:

Das Ganze verhält sich im Kernel-Kontext extrem seltsam. Es wirkt eher wie ein logischer Deadlock (ein „Sich-Verhaken“ der Komponenten):

LiveKernelEvents: Ich kriege ständig die IDs 141 und a2000002 (Blackscreens/Freezes).

Grafikkarten-Hänger: Nach dem Neustart zeigt der Geräte-Manager oft Fehler-Code 31 (GPU wird nicht initialisiert), bis ich den Treiber wieder anfasse.

Der „Crash-Test“ (CrashOnCtrlScroll): * Ich habe versucht, einen Absturz manuell zu erzwingen, um einen sauberen Dump zu bekommen.

Ergebnis: Kein Bluescreen! Stattdessen ein direkter Reboot oder ein kompletter Freeze.

Fehler 0x81: Die Dump-Erstellung bricht bei BugCheckProgress 0x81 ab. Das ist ein klares Zeichen, dass in dem Moment die Kommunikation mit der SSD/NVMe wegbricht.

Mein aktuelles Fazit:

Dass selbst ein manueller Absturz bei einem völlig frischen Windows nicht sauber durchläuft, sondern bei 0x81 hängen bleibt, deutet massiv auf einen Deadlock zwischen Kernel, Grafiktreiber und NVMe-Controller hin.

Da das Problem bei mir und meiner Freundin auf zwei unterschiedlichen AM5-Systemen (7800X3D & 7500F) fast identisch auftritt, vermuten wir inzwischen eher einen fiesen Bug in der aktuellen Plattform-Firmware oder eine Regression, als dass bei uns beiden gleichzeitig die Hardware stirbt.