Wo finde ich das Fehlerprotokoll in Windows 11?

Drücken Sie Windows-Taste und R, geben Sie eventvwr.msc ein und bestätigen Sie. Das System-Protokoll liegt unter Windows-Protokolle. Windows-Update-Einträge finden Sie unter Anwendungs- und Dienstprotokolle, Microsoft, Windows, WindowsUpdateClient, Operational. Eine Zeitachse der Ausfälle zeigt perfmon /rel.

Reicht Event 41, um die Ursache eines Neustarts zu kennen?

In der Regel nicht. Microsoft schreibt, Event ID 41 enthalte für sich genommen oft nicht genug Information. Wichtig sind der BugcheckCode in den Details, die Uhrzeit und die Einträge davor. Ein Code ungleich 0 deutet auf einen Stoppfehler, lauter Nullen deuten laut Microsoft eher auf Strom- oder Hardwareprobleme.

Wie rechne ich den BugcheckCode aus Event 41 um?

Der Code steht dezimal im Eintrag. Öffnen Sie den Windows-Rechner, wählen Sie die Ansicht Programmierer, tippen Sie den Wert bei Dez ein und schalten Sie auf Hex. Microsofts Beispiel: 159 ergibt 0x9F. Mit dem Hexwert suchen Sie den Code in der Bug Check Code Reference.

Ist WHEA-Logger Event 17 gefährlich?

Der Text besagt, dass ein Hardwarefehler korrigiert wurde. Ob das harmlos ist, hängt von Häufigkeit und Begleitsymptomen ab. Einzelne Meldungen sind anders zu bewerten als eine Serie mit Abstürzen oder Hängern. Notieren Sie Komponente und Geräte-ID aus dem Eintrag. Die Protokollierung abzuschalten unterdrückt nur die Meldung, nicht die Ursache.

Warum fehlt Event 41 oder der Stoppcode?

Das kann passieren, wenn der Strom ausfiel, Windows den Fehlercode nicht mehr schreiben konnte oder der Rechner so schnell abschaltete, dass der Fehler nicht erfasst wurde. Steht zusätzlich ein Event 46 der Quelle volmgr im Protokoll, prüfen Sie die Auslagerungsdatei. Sehen Sie den Bluescreen nur kurz, schalten Sie den automatischen Neustart ab.

Kann ich ein Protokoll auf einem anderen Rechner auswerten?

Ja. Get-WinEvent liest gespeicherte Protokolldateien im Format evtx, wenn Sie den Pfad mit dem Parameter -Path angeben. Dieselben Filter wie beim laufenden System lassen sich anwenden.

Windows 11Redaktion Die Netzhandwerker · 13. November 2026 · 9 Min. Lesezeit

Windows 11 Fehler auslesen: Fehlerprotokoll lesen und Event-IDs dem Symptom zuordnen

Person sitzt in einem hellen Büro am Schreibtisch vor einem aufgeklappten Laptop, daneben ein Notizblock und eine Kaffeetasse, und sucht nach der Ursache eines Computerproblems.

Windows 11 schreibt jeden Absturz, jeden unsauberen Neustart und jeden gescheiterten Update-Versuch in ein Ereignisprotokoll. Sie lesen es mit der Ereignisanzeige (eventvwr.msc), dem Zuverlässigkeitsverlauf (perfmon /rel) oder per PowerShell mit Get-WinEvent aus. Entscheidend ist die Event-ID zusammen mit dem Zeitpunkt: Kernel-Power 41 und EventLog 6008 stehen für unerwartete Neustarts, 1001 für einen Bluescreen, disk 7 und 11 für Laufwerksprobleme, WHEA-Logger 17 für Hardwarefehler und WindowsUpdateClient 20 für gescheiterte Updates. Die Tabelle weiter unten ordnet jedem Symptom Protokoll, Quelle, Event-ID und den nächsten Prüfschritt zu.

Event 41Kernel-Power: Neustart ohne sauberes Herunterfahren, Stufe Kritisch

perfmon /relöffnet laut Microsoft den Zuverlässigkeitsverlauf

Level=1,2Filterwert für Kritisch und Fehler in Get-WinEvent

Stand 13.11.2026. Grundlage: Microsoft Learn (Get-WinEvent, perfmon, Event ID 41, Windows-Update-Fehlersuche, Zuverlässigkeitsverlauf), Microsoft Support zu Stoppcodefehlern sowie archivierte Microsoft-Seiten zu den Ereignissen 6008, 7 und 20.

Kurzantwort: Welches Werkzeug wann
Die Befehlsfolge: von der Übersicht zum gefilterten Protokoll
Symptom, Protokoll, Quelle und Event-ID auf einen Blick
Einen Eintrag richtig lesen
Die Fälle in sinnvoller Reihenfolge
Wenn es komplizierter wird
Grenzen der Angaben und Vorbeugung

Kurzantwort: Welches Werkzeug wann

Für ein unklares Problem bewährt sich diese Reihenfolge, vom Groben zum Feinen:

Zuverlässigkeitsverlauf (perfmon /rel): zeigt einen Stabilitätsindex und ausgewählte Ereignisse auf einer Zeitachse. Sie sehen schnell, an welchem Tag und zu welcher Uhrzeit etwas schiefging.
Ereignisanzeige (eventvwr.msc): das vollständige Protokoll mit Details zu jedem Eintrag. Hier lesen Sie die Event-ID, die Quelle und die Detaildaten.
PowerShell (Get-WinEvent): filtert nach Zeitraum, Stufe und Event-ID. Sinnvoll, wenn die Ereignisanzeige mit tausenden Einträgen unübersichtlich wird.

Eine Event-ID allein ist kein Urteil

Microsoft weist selbst darauf hin, dass Event ID 41 für sich genommen oft nicht ausreicht, um zu erklären, was passiert ist. Es kommt darauf an, was zum Zeitpunkt des Neustarts sonst geschah, etwa ein Stromausfall oder ein Stoppfehler.

Die Befehlsfolge: von der Übersicht zum gefilterten Protokoll

Öffnen Sie mit Windows-Taste und R das Ausführen-Fenster und geben Sie nacheinander diese Befehle ein. Die PowerShell-Befehle starten Sie in einem Fenster mit Administratorrechten, sonst meldet PowerShell bei manchen Protokollen, dass es keine Informationen abrufen kann.

# 1. Zuverlässigkeitsverlauf öffnen (Zeitachse der Ausfälle)
perfmon /rel

# 2. Ereignisanzeige öffnen (vollständiges Protokoll)
eventvwr.msc

# 3. PowerShell: Kritische Einträge und Fehler der letzten 24 Stunden im System-Protokoll
$seit = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{ LogName='System'; Level=1,2; StartTime=$seit } |
  Format-Table TimeCreated, Id, ProviderName, Message -AutoSize -Wrap

# 4. PowerShell: gezielt nach den Kennungen aus der Tabelle suchen (letzte 7 Tage)
$woche = (Get-Date).AddDays(-7)
Get-WinEvent -FilterHashtable @{ LogName='System'; Id=41,6008,1001,7,11,17; StartTime=$woche } |
  Format-Table TimeCreated, Id, ProviderName, Message -AutoSize -Wrap

# 5. PowerShell: Windows-Update-Fehler der letzten 7 Tage
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-WindowsUpdateClient/Operational'; Level=1,2; StartTime=$woche } |
  Format-Table TimeCreated, Id, Message -AutoSize -Wrap

Was die Befehle tun, und worauf Sie achten sollten:

perfmon /rel startet laut Microsoft den Reliability Monitor, auf Deutsch Zuverlässigkeitsverlauf. Mit /res, /report und /sys starten andere Ansichten desselben Programms.
-FilterHashtable akzeptiert unter anderem die Schlüssel LogName, ProviderName, Id, Level und StartTime. Microsoft dokumentiert diese Filter als effizienter als das nachträgliche Aussortieren mit Where-Object, weil sie schon beim Abrufen greifen.
Die Stufen sind Zahlen: 1 steht für Kritisch, 2 für Fehler, 3 für Warnung, 4 für Informationen. Kernel-Power 41 führt Microsoft als Stufe Kritisch, deshalb enthält der Filter 1 und 2. Meldungen auf Stufe Warnung fängt er nicht ein. Falls ein Eintrag wie WHEA-Logger 17 als Warnung geführt wird, finden Sie ihn mit Befehl 4, der nach der Kennung statt nach der Stufe sucht.
Die Kennungen 7, 11, 17 und 1001 kommen auch bei anderen Quellen vor. Prüfen Sie in der Spalte ProviderName, ob die Quelle zur Tabelle passt.
Bleibt die Ausgabe leer oder meldet PowerShell, es gebe keine passenden Ereignisse, ist im gewählten Zeitraum nichts protokolliert. Vergrößern Sie dann den Zeitraum.
Standardmäßig liefert Get-WinEvent die neuesten Einträge zuerst. Mit -MaxEvents 20 begrenzen Sie die Menge.

In der Ereignisanzeige selbst erreichen Sie dasselbe über einen Rechtsklick auf das Protokoll und die Funktion „Aktuelles Protokoll filtern“. Das System-Protokoll finden Sie unter „Windows-Protokolle“. Das Update-Protokoll liegt unter „Anwendungs- und Dienstprotokolle“, dann „Microsoft“, „Windows“, „WindowsUpdateClient“ und „Operational“. Dieser Pfad steht so in der Microsoft-Anleitung zur Update-Fehlersuche.

Symptom, Protokoll, Quelle und Event-ID auf einen Blick

Die Tabelle fasst zusammen, welcher Eintrag zu welchem Symptom gehört und was Sie als Nächstes prüfen. Die Angaben stammen aus den unten genannten Microsoft-Seiten. Wo Microsoft nur ältere Dokumentation oder Community-Beiträge bereitstellt, steht das im Abschnitt zu den Grenzen.

Symptom	Protokoll und Quelle	Event-ID	Nächster Prüfschritt
PC startet unerwartet neu oder war plötzlich aus	System, Microsoft-Windows-Kernel-Power (Stufe Kritisch)	41	Details-Tab öffnen und BugcheckCode ansehen. Ungleich 0: Stoppfehler, Code umrechnen. 0 mit gesetztem PowerButtonTimestamp: Einschaltknopf gehalten. Alles 0: Stromversorgung und Hardware prüfen.
Windows meldet nach dem Start einen unsauberen Shutdown	System, Quelle EventLog (Stufe Fehler)	6008	Einträge kurz vor dem genannten Zeitpunkt im System- und im Anwendungsprotokoll lesen. 6006 bedeutet sauberes Herunterfahren, 1074 einen gewollten Neustart durch Programm oder Benutzer.
Bluescreen mit anschließendem Neustart	System, Microsoft-Windows-WER-SystemErrorReporting	1001	Stoppcode aus dem Text notieren, auf den Hinweis zur gespeicherten Dumpdatei achten. Der Code erscheint auch in Event 41. Weiter mit der Bluescreen-Anleitung.
Laufwerk meldet defekten Block	System, Quelle disk (Stufe Fehler)	7	Daten sichern. Dann `chkdsk` mit `/r` auf der genannten Partition ausführen. Tritt die Meldung weiter auf, Laufwerk und Controller mit der Herstellerdiagnose prüfen.
Laufwerkstreiber meldet Controllerfehler	System, Quelle disk	11	Auf Häufigkeit und Begleitsymptome achten. Bei Wiederholung dieselbe Laufwerksprüfung wie bei Event 7. Die Ursache ist nicht immer ein Hardwaredefekt.
Hardwarefehler, Hänger oder Abstürze ohne klaren Auslöser	System, Microsoft-Windows-WHEA-Logger	17	Im Eintrag stehen Komponente (etwa PCI Express Root Port) und Geräte-IDs. Notieren Sie, welches Bauteil gemeldet wird und wie oft. Einzelne Meldungen sind anders zu bewerten als eine Häufung mit Abstürzen.
Windows-Update scheitert	Anwendungs- und Dienstprotokolle, Microsoft, Windows, WindowsUpdateClient, Operational	20	Update und Fehlercode aus dem Text ablesen. Erst neu starten, dann den Code in der Microsoft-Fehlerliste nachschlagen. Weiter mit der Update-Anleitung.

Einen Eintrag richtig lesen

Drei Schritte machen aus einer Meldung eine brauchbare Spur.

Zeitpunkt eingrenzen

Suchen Sie im Zuverlässigkeitsverlauf den Tag mit dem Einbruch und notieren Sie die Uhrzeit. In der Ereignisanzeige betrachten Sie dann die Einträge kurz davor. Microsoft empfiehlt bei einem unerwarteten Shutdown ausdrücklich, im System- und im Anwendungsprotokoll nach auffälligen Ereignissen vor dem Zeitpunkt zu suchen, den Event 6008 nennt. Die Ursache steht oft vor dem Neustart, nicht beim Neustart.

Event 41 im Detail lesen

Doppelklicken Sie den Eintrag und öffnen Sie den Reiter „Details“. Microsoft beschreibt dort die Felder BugcheckCode, die Parameter 1 bis 4 und PowerButtonTimestamp. Der Stoppcode steht dezimal im Eintrag, in der Fachliteratur aber hexadezimal. Zum Umrechnen öffnen Sie den Windows-Rechner, schalten auf „Programmierer“ und tippen den Dezimalwert ein. Microsofts Beispiel: 159 ergibt 0x9F. Mit dem Hexwert suchen Sie den Stoppcode in der Bug Check Code Reference von Microsoft.

Begleitende Einträge einordnen

6006: Windows wurde ordnungsgemäß beendet.
1074: ein Programm, ein Benutzer über das Startmenü oder Strg+Alt+Entf hat Herunterfahren oder Neustart ausgelöst. Der Neustart war also gewollt.
6008: der letzte Shutdown war unerwartet.
41: Windows startete neu, ohne vorher sauber heruntergefahren zu sein.

Die Fälle in sinnvoller Reihenfolge

Einfachster Fall zuerst: War der Neustart gewollt?

Ein Neustart durch ein Update oder eine Installation erzeugt Event 1074 und anschließend ein sauberes Herunterfahren. Findet sich 1074 kurz vor dem Neustart, war es kein Fehler. Dann hilft ein Blick in den Update-Verlauf.

Unerwarteter Neustart: Event 41 und 6008

Microsoft unterscheidet drei Fälle. Enthält Event 41 einen Stoppcode, war ein Stoppfehler die Ursache und Sie verfolgen den Code weiter. Ist PowerButtonTimestamp ungleich 0, haben Sie den Einschaltknopf gehalten, etwa bei einem hängenden Rechner. Stehen alle Werte auf 0 oder fehlt Event 41 ganz, deutet das laut Microsoft auf Strom- oder Hardwareprobleme hin. Dazu zählen ein entfernter oder leerer Akku, ein gezogener Stecker, ein Stromausfall oder ein zu schwaches oder defektes Netzteil.

Bluescreen: Event 1001

Event 1001 der Quelle WER-SystemErrorReporting nennt den Stoppcode und, falls geschrieben, den Ort der Speicherabbilddatei, in einem Beispiel aus Microsoft Q&A C:\Windows\MEMORY.DMP. Der Beitrag stammt aus der Community und nicht aus der offiziellen Dokumentation, zeigt aber den typischen Aufbau. Wie Sie mit dem Stoppcode weiterarbeiten, steht in unserer Anleitung zum Bluescreen unter Windows.

Festplattenfehler: disk 7 und 11

Die Meldung zu Event 7 lautet sinngemäß, das Gerät habe einen defekten Block. Microsoft empfiehlt, chkdsk mit der Option /r auf der genannten Partition auszuführen. Meldet chkdsk nichts, die Meldung kehrt aber wieder, sollen Laufwerk und Controller mit Hardwarediagnose geprüft werden, gegebenenfalls ist ein Austausch nötig. Sichern Sie vorher Ihre Daten. Event 11 („Der Treiber hat einen Controllerfehler erkannt“) ist weniger eindeutig: In einem Microsoft-Q&A-Beitrag berichten Teilnehmer von dieser Meldung in virtuellen Clustern ohne erkennbaren Hardwaredefekt. Bei einem normalen PC ist die Häufigkeit entscheidend. Eine einzelne Meldung ist anders zu werten als eine Serie.

Hardwarefehler: WHEA-Logger 17

WHEA steht für Windows Hardware Error Architecture, Microsofts Verfahren zum Melden und Behandeln von Hardwarefehlern. Event 17 trägt den Text „A corrected hardware error has occurred“, der Fehler wurde laut Meldung also korrigiert. Der Eintrag nennt die betroffene Komponente, im Microsoft-Q&A-Beispiel ein PCI Express Root Port, sowie Hersteller- und Geräte-ID. Als Erfahrungsberichte aus diesem Beitrag: Ein Nutzer hatte die PCIe-Geschwindigkeit im BIOS zuvor auf GEN1 begrenzt. Nach der Umstellung auf GEN2 verschwanden die Meldungen. Ein anderer stellte die Energieoption „Link State Power Management“ auf „Aus“. Beides sind Einzelfälle, keine Herstellerempfehlung. Das Abschalten der Protokollierung per Registry unterdrückt nur die Meldung und beseitigt die Ursache nicht.

Update scheitert: WindowsUpdateClient 20

Event 20 lautet „Installation failure: Windows failed to install the following update with error ...“ und nennt Update und Fehlercode. Event 19 zeigt umgekehrt eine erfolgreiche Installation. Microsoft rät, zuerst nach ausstehendem Neustart zu schauen und diesen auszuführen, dann den Fehlercode in den Microsoft-Listen zu Windows-Update-Fehlern nachzuschlagen. Konkrete Codes behandeln wir in der Anleitung zu Windows-Update-Fehlern.

Wenn es komplizierter wird

Manche Fälle lassen sich mit dem Protokoll allein nicht abschließen:

Event 41 mit lauter Nullen: Windows konnte keinen Fehlercode schreiben. Microsoft nennt als Prüfpunkte Übertaktung (zurücknehmen), Arbeitsspeicher (mit einer Speicherprüfung testen), Netzteil (reicht die Leistung für alle eingebauten Teile?) und Überhitzung. Bei Stromunterbrechungen kommt laut Microsoft eine unterbrechungsfreie Stromversorgung in Frage.
Event 46 der Quelle volmgr („Crash dump initialization failed“): Erscheint er zusammen mit einem Event 41 voller Nullen, prüfen Sie die Auslagerungsdatei. Der Stoppcode konnte dann womöglich nicht festgehalten werden, obwohl ein Stoppfehler vorlag.
Stoppcode sichtbar, aber nicht in Event 41: Schalten Sie in den erweiterten Systemeinstellungen unter „Starten und Wiederherstellen“ den automatischen Neustart ab. Dann bleibt der Bluescreen stehen und Sie können den Code ablesen.
Mehrere Ursachen gleichzeitig: Wenn Laufwerks-, WHEA- und Neustart-Einträge im selben Zeitraum auftreten, lässt sich die Reihenfolge ohne tiefere Analyse schwer klären.

Für solche Fälle finden Sie weitere Hinweise unter Windows-Probleme.

Grenzen der Angaben und Vorbeugung

Dokumentationsstand. Zu Event 41 und zum Befehl Get-WinEvent gibt es aktuelle Microsoft-Seiten. Die Angaben zu Event 6008, 7 und 20 stammen aus archivierten Microsoft-Seiten, geschrieben für ältere Windows-Versionen. Event 1001, WHEA 17 und disk 11 belegen wir mit Microsoft-Q&A-Beiträgen aus der Community. Die Bedeutung der Kennungen ist in der Praxis stabil, aber Wortlaut und Zusatzfelder können in Windows 11 abweichen. Die Tabelle ist deshalb ein Wegweiser und kein Gutachten.

Protokolle sichern und prüfen. Get-WinEvent liest auch gespeicherte Protokolldateien (.evtx), etwa mit Get-WinEvent -Path 'C:\Pfad\datei.evtx'. So lassen sich Protokolle eines Rechners auf einem anderen auswerten.

Vorbeugung. Microsoft empfiehlt gegen Stoppfehler, Windows-Updates einzuspielen und 10 bis 15 Prozent des Laufwerks frei zu halten. Neue Hardware, die kurz vor den ersten Abstürzen eingebaut wurde, entfernen Sie testweise. Prüfen Sie zusätzlich im Geräte-Manager, ob Geräte mit Ausrufezeichen auftauchen.

Passend dazu

Wer dieselben Meldungen auf mehreren Rechnern im Betrieb immer wieder von Hand heraussuchen muss, spart mit einer automatischen Auswertung Zeit. Genau dafür gibt es unsere Windows-Diagnosen als eigenes Werkzeug.

Mehr dazu: Windows-Diagnosen als eigenes Werkzeug

Quellen

Microsoft Learn: Get-WinEvent, learn.microsoft.com
Microsoft Learn: perfmon, learn.microsoft.com
Microsoft Learn: Event ID 41 The system has rebooted without cleanly shutting down first, learn.microsoft.com
Microsoft Learn (Archiv): Event ID 6008 troubleshooting, learn.microsoft.com
Microsoft Learn (Archiv): Event 7, device has a bad block, learn.microsoft.com
Microsoft Learn: Guidance for troubleshooting Windows Server update, learn.microsoft.com
Microsoft Learn (Archiv): Event ID 20 WUA Update Installation, learn.microsoft.com
Microsoft Learn: Reliability Monitor shows no information, learn.microsoft.com
Microsoft Support: Problembehandlung bei unerwarteten Windows-Neustarts und Codestoppfehlern, support.microsoft.com
Microsoft Q&A: BSOD Event 1001 Bugcheck, learn.microsoft.com
Microsoft Q&A: WHEA-Logger Event ID 17 issue, learn.microsoft.com
Microsoft Q&A: Event 11 disk, controller error, learn.microsoft.com
Microsoft Learn: Windows Hardware Error Architecture (WHEA) Design Guide, learn.microsoft.com

Alle Quellen gelesen am 13.11.2026.

Erstellt von der Redaktion Die Netzhandwerker mit KI-Unterstützung. Die Sachangaben wurden vor der Veröffentlichung automatisch gegen die genannten Quellen geprüft.