Die Ereignisanzeige von Windows 11 kann den Zeitpunkt und die Art eines Absturzes eingrenzen, liefert aber selten mit einem einzigen roten Eintrag die fertige Ursache. Öffne zuerst das Systemprotokoll, grenze den Zeitraum auf wenige Minuten rund um den Ausfall ein und werte Quelle, Ereignis-ID sowie Detailtext gemeinsam aus. Besonders aussagekräftig sind BugCheck-Ereignisse nach einem Bluescreen, WHEA-Logger-Meldungen zu erkannten Hardwareproblemen und wiederkehrende Datenträger- oder Controllerfehler. Ein kritisches Kernel-Power-Ereignis mit der ID 41 belegt dagegen zunächst nur, dass Windows nicht ordnungsgemäß heruntergefahren wurde.
Die zuverlässigste Diagnose entsteht durch eine Ereigniskette: Was wurde unmittelbar vor dem Ausfall protokolliert, welcher Eintrag beschreibt den Neustart und welche Meldung erscheint nach dem Hochfahren? Einzelne Warnungen, die schon seit Wochen ohne sichtbare Störung auftreten, sind meist weniger bedeutsam als mehrere zeitlich passende Fehler derselben Quelle.
Den Absturzzeitpunkt eingrenzen, bevor du Fehler öffnest
Starte die Ereignisanzeige mit eventvwr.msc über das Fenster Ausführen, das du mit Windows-Taste und R öffnest. Klappe links Windows-Protokolle auf und wähle zuerst System. Dieses Protokoll enthält unter anderem Meldungen zu Kernel, Stromversorgung, Treibern, Datenträgern und Hardwarefehlern. Für den Absturz eines einzelnen Programms ist anschließend Anwendung der passendere Bereich.
Notiere möglichst genau, wann der Rechner eingefroren ist, einen Bluescreen gezeigt oder selbstständig neu gestartet hat. Schon eine Abweichung von zehn Minuten kann dazu führen, dass du eine harmlose Warnung mit dem Ausfall verwechselst. Sortiere die Liste über die Spalte Datum und Uhrzeit und suche den passenden Zeitraum.
Bei umfangreichen Protokollen wählst du rechts Aktuelles Protokoll filtern. Begrenze den Zeitraum und markiere zunächst Kritisch sowie Fehler. Warnungen solltest du erst einbeziehen, wenn die erste Auswertung keinen brauchbaren Hinweis liefert. Sie treten im normalen Betrieb häufig auf und erzeugen sonst viel Nebengeräusch.
Die Ansicht Administrative Ereignisse bündelt kritische Ereignisse, Fehler und Warnungen aus mehreren Protokollen. Sie eignet sich zur Orientierung, ist für die eigentliche Diagnose aber oft zu breit. Wechsle für die Auswertung immer in das ursprüngliche Protokoll des Ereignisses, damit zeitlich benachbarte Meldungen sichtbar bleiben.
Diese fünf Angaben machen einen Ereigniseintrag verwertbar
Die Farbe und Ebene eines Eintrags reichen nicht aus. Öffne das Ereignis per Doppelklick und erfasse fünf Informationen:
- Protokollname: Er zeigt, aus welchem Bereich die Meldung stammt, beispielsweise System oder Anwendung.
- Quelle: Der Anbieter des Ereignisses ist meist aussagekräftiger als die ID allein, etwa Kernel-Power, WHEA-Logger, BugCheck oder Application Error.
- Ereignis-ID: Sie ordnet den Meldungstyp innerhalb dieser Quelle ein. Dieselbe Zahl kann bei einer anderen Quelle etwas anderes bedeuten.
- Zeitstempel: Er muss zum beobachteten Ausfall passen. Prüfe auch die Minuten unmittelbar davor und danach.
- Beschreibung und Ereignisdaten: Dort stehen Fehlercodes, betroffene Komponenten, Dateinamen oder zusätzliche Statuswerte.
Unter Details kannst du zwischen einer aufbereiteten und einer XML-Ansicht wechseln. Die XML-Ansicht ist hilfreich, wenn die allgemeine Beschreibung einen Wert verkürzt darstellt oder du Einträge miteinander vergleichen möchtest. Felder wie Anbietername, Ereignis-ID, Zeitpunkt und Ereignisdaten lassen sich dort eindeutig zuordnen. Lange Zahlenfolgen solltest du jedoch nicht ohne Kontext als defektes Bauteil interpretieren.
Bluescreen, Stromverlust oder erzwungener Neustart unterscheiden
Nach einem plötzlichen Neustart stehen häufig Kernel-Power 41 und EventLog 6008 im Systemprotokoll. Beide Einträge beschreiben die Folge eines nicht ordnungsgemäßen Herunterfahrens. Sie können nach einem Stromausfall, einem Reset, einem vollständigen Einfrieren, einem Bluescreen oder dem langen Drücken des Netzschalters erscheinen.
Kernel-Power mit Ereignis-ID 41
Kernel-Power 41 ist kein automatischer Beweis für ein defektes Netzteil. Öffne den Eintrag und prüfe im Reiter Details insbesondere, ob ein Bugcheck-Code enthalten ist. Ein von null abweichender Wert kann darauf hindeuten, dass Windows zuvor einen Stoppfehler registriert hat. Der angezeigte Wert allein ersetzt jedoch nicht die Auswertung des zugehörigen BugCheck-Ereignisses oder einer Speicherabbilddatei.
Steht kein verwertbarer Bugcheck-Code im Ereignis, bleiben mehrere Möglichkeiten offen: Die Stromversorgung wurde unterbrochen, der Rechner hing so vollständig, dass Windows nichts mehr protokollieren konnte, oder ein Hardware- beziehungsweise Firmwareproblem löste den Reset aus. Suche in den Sekunden und Minuten vor Ereignis 41 nach WHEA-Logger-, Datenträger-, Controller- oder Treibermeldungen. Fehlen solche Vorläufer vollständig, beweist auch das noch keinen Stromversorgungsfehler.
BugCheck mit Ereignis-ID 1001
Ein Eintrag der Quelle BugCheck mit der ID 1001 ist wesentlich ergiebiger. Er bestätigt, dass Windows einen Stoppfehler verarbeitet hat, und enthält üblicherweise den Bugcheck-Code sowie Parameter. Häufig wird außerdem ein Pfad zu einer Speicherabbilddatei genannt. Der Code grenzt die Fehlerklasse ein, benennt aber nicht in jedem Fall den verantwortlichen Treiber oder das Bauteil.
Findest du Kernel-Power 41, EventLog 6008 und BugCheck 1001 rund um denselben Zeitpunkt, behandle den Vorgang als Bluescreen-Diagnose. Ist nur Kernel-Power vorhanden und das Bild wurde schlagartig schwarz, richtet sich die weitere Prüfung eher auf Stromversorgung, Überhitzung, Firmware, instabile Hardwareeinstellungen oder ein vollständiges Systemhängen. Die Ereignisanzeige kann diese Möglichkeiten priorisieren, aber nicht allein abschließend trennen.
WHEA-Logger richtig als Hardwarehinweis lesen
WHEA steht für Windows Hardware Error Architecture. Ereignisse der Quelle WHEA-Logger entstehen, wenn Windows eine von Hardware oder Firmware gemeldete Fehlerbedingung verarbeitet. Solche Einträge verdienen besondere Aufmerksamkeit, wenn sie unmittelbar vor einem Absturz auftreten oder unter Last wiederkehren.
Die Ereignis-ID kann Hinweise auf korrigierte oder schwerwiegende Fehlerklassen geben, sollte aber nicht isoliert ausgewertet werden. Öffne die Beschreibung und achte auf Begriffe wie Processor Core, Memory, PCI Express, Cache Hierarchy oder Bus/Interconnect. Diese Bezeichnungen kennzeichnen den gemeldeten Bereich, nicht zwingend das Bauteil, das tatsächlich ausgetauscht werden muss.
- Ein wiederkehrender Prozessor- oder Cache-Hinweis kann mit CPU, Spannungsversorgung, BIOS-Einstellungen, Temperatur oder instabilen Takt- und Spannungswerten zusammenhängen.
- Ein PCI-Express-Hinweis kann von einer Erweiterungskarte, einem NVMe-Laufwerk, dem Steckplatz, einem Treiber oder der Plattform-Firmware ausgelöst werden.
- Ein Speicherhinweis kann RAM betreffen, aber auch Speichercontroller, Kontaktprobleme oder instabile Einstellungen einschließen.
Die passende Gegenprobe richtet sich nach dem Fehlerbereich. Setze manuelle Übertaktungs-, Undervolting- oder Speicherprofile testweise auf stabile Standardwerte zurück, sofern du solche Einstellungen bewusst aktiviert hast. Prüfe danach, ob derselbe WHEA-Eintrag unter vergleichbarer Belastung erneut erscheint. Änderungen im BIOS oder UEFI solltest du dokumentieren und nicht mehrere Parameter gleichzeitig verändern.
Ein einzelner korrigierter WHEA-Eintrag ohne Absturz ist noch kein sicherer Defektnachweis. Häufen sich identische Meldungen jedoch in zeitlicher Nähe zu Neustarts, Freezes oder Bluescreens, ist das ein belastbarer Anlass für gezielte Hardwaretests. Bei einem Firmen-PC oder einem Gerät mit Garantie ist eine dokumentierte Liste aus Zeitpunkt, Quelle, Ereignis-ID und gemeldetem Bereich besonders nützlich für den Support.
Datenträger- und Controllerfehler nicht vorschnell dem Laufwerk zuordnen
Speicherprobleme zeigen sich im Systemprotokoll unter verschiedenen Quellen. Dazu können unter anderem Disk, Ntfs, stornvme, storahci oder storport gehören. Welche Quelle erscheint, hängt vom Laufwerk, Controller, Treiber und Übertragungsweg ab.
Wiederkehrende Disk-Ereignisse wie ID 7 oder 51 können auf Lese-, Schreib- oder Übertragungsprobleme hinweisen. Ein storport-Ereignis 129 beschreibt typischerweise, dass ein Speichergerät beziehungsweise der zugehörige Pfad zurückgesetzt wurde, nachdem eine Operation nicht rechtzeitig abgeschlossen werden konnte. Ereignis 153 kann auf eine erneut ausgeführte Ein-/Ausgabeoperation hinweisen. Solche Einträge sind relevant, wenn gleichzeitig kurze Hänger, sehr lange Ladezeiten, verschwundene Laufwerke oder Abstürze auftreten.
Der Provider und der vollständige Meldungstext entscheiden über die Bedeutung. Ein Controller-Reset beweist nicht automatisch, dass die SSD selbst defekt ist. Als Ursachen kommen je nach System auch Treiber, Firmware, Kabel, Stromversorgung, Controller oder ein problematisches externes Gehäuse infrage.
Enthält die Beschreibung einen Gerätenamen wie \Device\Harddisk0\DR0, entspricht die Nummer nicht sicher dem im Explorer sichtbaren Laufwerksbuchstaben. Öffne die Datenträgerverwaltung über einen Rechtsklick auf die Startschaltfläche und vergleiche Datenträgernummer, Größe, Partitionen und Modell. Beginne bei wiederkehrenden Ein-/Ausgabefehlern mit einer Datensicherung, bevor du Belastungstests oder Reparaturversuche startest.
Programmabstürze im Anwendungsprotokoll zuordnen
Schließt sich nur eine Anwendung, während Windows weiterläuft, findest du den besseren Ansatz unter Windows-Protokolle und Anwendung. Häufig erscheint dort ein Ereignis der Quelle Application Error mit der ID 1000. Die Beschreibung kann den Namen der abgestürzten Anwendung, das fehlerhafte Modul, einen Ausnahmecode und einen Fehleroffset enthalten.
Der Modulname hilft bei der Abgrenzung. Verweist er direkt auf eine Datei der Anwendung, liegt der nächste Prüfpunkt bei dieser Software und ihren Erweiterungen. Taucht stattdessen wiederholt eine Grafiktreiber-, Audio-, Sicherheitssoftware- oder Laufzeitkomponente bei verschiedenen Programmen auf, spricht das eher für eine gemeinsam genutzte Komponente. Ein einmalig genannter Modulname ist dennoch kein sicherer Schuldnachweis.
Ein zeitlich passendes Ereignis von Windows Error Reporting, häufig mit der ID 1001, kann zusätzliche Signaturen und einen Berichtsnamen enthalten. Die ID 1001 hat hier eine andere Bedeutung als bei der Quelle BugCheck. Genau deshalb müssen Quelle und Ereignis-ID immer zusammen gelesen werden.
Aus einzelnen Meldungen eine belastbare Ereigniskette bilden
Für die Auswertung eines Neustarts solltest du nicht bei der ersten kritischen Meldung stehen bleiben. Verwende eine feste Reihenfolge, die Ursache und Folge voneinander trennt:
- Bestimme den letzten Zeitpunkt, an dem der PC noch normal reagierte, und den Zeitpunkt des Neustarts.
- Suche im Systemprotokoll nach Kernel-Power 41, EventLog 6008 oder BugCheck 1001, um die Art des Abbruchs einzugrenzen.
- Gehe vom Neustart aus einige Minuten zurück und prüfe wiederkehrende WHEA-, Datenträger-, Controller-, Grafik- oder Treiberereignisse.
- Vergleiche den Fund mit früheren Abstürzen. Gleiche Quelle, gleiche ID und ähnliche Detaildaten erhöhen die Aussagekraft erheblich.
- Führe nur eine passende Gegenprobe durch und kontrolliere beim nächsten Auftreten, ob sich die Ereigniskette verändert hat.
Ein typisches Beispiel ist eine Folge aus mehreren Controller-Zeitüberschreitungen, einem Datenträgerfehler und dem anschließenden unerwarteten Neustart. Diese Reihenfolge macht den Speicherpfad verdächtiger als Kernel-Power 41 allein. Erscheint dagegen vor dem Neustart ein WHEA-Logger-Eintrag mit wiederholt demselben gemeldeten Bereich, erhält die Hardware- oder Firmwareprüfung höhere Priorität.
Fehlt vor Kernel-Power 41 jede passende Meldung, ist das ebenfalls ein Ergebnis: Windows konnte die Ursache möglicherweise nicht mehr protokollieren. Dann sind Beobachtungen außerhalb der Ereignisanzeige entscheidend, etwa ein sofort schwarzer Bildschirm, weiterlaufende Lüfter, ein vollständiger Stromverlust oder ein reproduzierbarer Ausfall nur unter hoher Last.
Alte Warnungen und echte Absturzspuren auseinanderhalten
Die Ereignisanzeige enthält auch auf einem funktionierenden Windows-11-PC zahlreiche Warnungen und Fehler. Relevanz entsteht erst durch zeitliche Nähe, Wiederholbarkeit und einen plausiblen Zusammenhang mit dem Symptom. Ein Fehler, der täglich beim Start protokolliert wird, obwohl der Rechner monatelang stabil läuft, erklärt einen einzelnen Absturz nur selten.
Nutze ergänzend den Zuverlässigkeitsverlauf, den du über die Windows-Suche mit Zuverlässigkeitsverlauf anzeigen öffnest. Er ordnet Anwendungsfehler, Windows-Fehler, Hardwarefehler und Installationen nach Tagen. Damit lässt sich schnell prüfen, ob ein Treiber- oder Softwareereignis seit einer bestimmten Änderung gehäuft auftritt. Für technische Details wechselst du anschließend wieder zur Ereignisanzeige.
Lösche die Protokolle nicht zu Beginn der Fehlersuche. Dabei gehen Vergleichsdaten verloren, die zeigen könnten, ob ein Ereignis neu ist oder schon lange ohne Auswirkungen auftritt. Wenn du einen sauberen Beobachtungszeitraum benötigst, speichere das betreffende Protokoll zuerst über Alle Ereignisse speichern unter. Notiere zusätzlich die Uhrzeit und beobachte den Rechner weiter, statt vorhandene Spuren vorschnell zu beseitigen.
Wann die Ereignisanzeige für die Diagnose nicht ausreicht
Bei einem Bluescreen führt ein vorhandenes Speicherabbild meist weiter als der Ereigniseintrag allein, weil es Informationen zum Systemzustand beim Stoppfehler enthalten kann. Bei abruptem Stromverlust, einem Reset durch Schutzschaltungen oder einem vollständigen Hardwarestillstand bleibt dagegen unter Umständen kein vorheriger Fehler im Protokoll zurück.
Beende Selbstversuche und sichere wichtige Daten, wenn Datenträgerfehler zunehmen, Laufwerke zeitweise verschwinden, WHEA-Fehler in kurzer Folge auftreten oder Windows nicht mehr zuverlässig startet. Bei Geruch, ungewöhnlicher Hitze, sichtbaren Schäden oder elektrischen Auffälligkeiten sollte der Rechner ausgeschaltet bleiben. Die Ereignisanzeige kann in solchen Fällen die Übergabe an Reparatur oder Support verbessern: Exportiere den relevanten Protokollabschnitt und ergänze Zeitpunkt, beobachtetes Verhalten sowie die zuletzt vorgenommene Änderung.
Für eine tragfähige Bewertung zählt am Ende nicht die Anzahl roter Symbole, sondern die passende Kombination aus Symptom, Zeitpunkt, Quelle, Ereignis-ID und wiederkehrenden Detaildaten. Kernel-Power beschreibt häufig nur den abgebrochenen Systemzustand; BugCheck, WHEA-Logger sowie Datenträger- und Controllerereignisse liefern die spezifischeren Spuren, sofern sie zeitlich zur Störung passen.
