Fehler in der Ereignisanzeige findest du am schnellsten so: Windows-Taste + R, eventvwr.msc eingeben, links Windows-Protokolle → System öffnen und rechts Aktuelles Protokoll filtern… anklicken. Dort die Ebenen auf Kritisch und Fehler begrenzen und den Zeitraum auf die Stunde des Störfalls setzen. Von jedem übrig gebliebenen Eintrag notierst du Quelle und Ereignis-ID – dieses Paar führt zur Ursache, die Nummer allein nicht.
Die Bedienung ist unter Windows 10 und Windows 11 identisch; Windows 11 26H2 kommt im Herbst 2026 als Enablement-Paket auf derselben Basis wie 25H2 und ändert an der Ereignisanzeige nichts. Beruhigend nebenbei: Im Event Viewer wird nur gelesen. Filtern, sortieren und exportieren verändert weder Protokolle noch System.
Ereignisanzeige öffnen – und wann du Adminrechte brauchst
Drei Wege, alle landen im selben Fenster:
- Ausführen-Dialog: Windows-Taste + R,
eventvwr.msceintippen, Enter. Der schnellste Weg. - Suche: Windows-Taste drücken, Ereignisanzeige tippen, Treffer anklicken.
- Startmenü-Rechtsklick: Rechtsklick auf das Windows-Symbol in der Taskleiste, dort Ereignisanzeige wählen.
Für das Sicherheitsprotokoll brauchst du Administratorrechte. Wenn dieser Zweig leer aussieht oder beim Anklicken eine Zugriffsmeldung erscheint, schließe das Fenster und starte die Ereignisanzeige per Rechtsklick auf den Suchtreffer als Administrator – System- und Anwendungsprotokoll lesen sich dagegen auch mit normalem Konto.
Anzeige
Welches Protokoll ist für deinen Fehler zuständig?
Links im Baum unter Windows-Protokolle liegen vier Protokolle, die den Großteil aller Alltagsprobleme abdecken:
- System: Windows selbst – Treiber, Dienste, Hardware, Neustarts. Erste Anlaufstelle bei Abstürzen, Boot-Problemen und Geräten, die sporadisch verschwinden.
- Anwendung: Meldungen installierter Programme. Hier steht, wenn eine Software abstürzt, meist samt Name der verantwortlichen Programmdatei oder DLL (eine DLL ist ein ausgelagerter Programmbaustein, den mehrere Programme gemeinsam nutzen).
- Sicherheit: An- und Abmeldungen, Rechteänderungen, Kontosperrungen. Nur mit Adminrechten sichtbar und für gewöhnliche Fehlersuche selten nötig.
- Setup: Installationen und Windows-Updates – der richtige Ort, wenn ein Update scheitert oder ein Feature-Upgrade zurückrollt.
Weiter unten stehen die Anwendungs- und Dienstprotokolle. Dort protokolliert jede Windows-Komponente in einen eigenen Kanal (Technik dahinter: ETW, die Ereignisablaufverfolgung von Windows). Das lohnt sich, wenn du ein bestimmtes Feature untersuchst – etwa den Windows-Update-Client oder eine Bluetooth-Verbindung –, weil dort Meldungen landen, die es nie ins Systemprotokoll schaffen.
Die Ereignisebenen und ihre Nummern
Jeder Eintrag hat eine Ebene. Die Nummer dahinter brauchst du später beim Filtern per PowerShell:
| Ebene | Nummer | Bedeutung |
|---|---|---|
| Kritisch | 1 | Schwerer Fehler, meist Absturz oder unerwarteter Neustart. Immer ansehen. |
| Fehler | 2 | Eine Funktion oder ein Dienst konnte nicht ausgeführt werden. |
| Warnung | 3 | Noch kein Ausfall, aber ein Hinweis, der sich auswachsen kann – etwa knapper Speicherplatz. |
| Informationen | 4 | Normalbetrieb, ein Dienst wurde gestartet. Der Großteil aller Einträge. |
| Ausführlich | 5 | Detail-Meldungen, standardmäßig kaum genutzt. |
Fehler in der Ereignisanzeige gezielt filtern
Sich durch tausende Zeilen zu scrollen ist verlorene Zeit. Mit dem Filter bist du in Sekunden beim Wesentlichen:
- Links das Protokoll anklicken – meist System, bei einem abgestürzten Programm Anwendung.
- Rechts im Aktionsbereich Aktuelles Protokoll filtern… wählen.
- Bei Ereignisebene die Haken nur bei Kritisch und Fehler setzen.
- Unter Protokolliert einen Zeitraum wählen, der zum Störfall passt – etwa Letzte 24 Stunden oder über Benutzerdefinierter Bereich exakt die Stunde des Absturzes.
- Optional eine konkrete Ereignis-ID eintragen, wenn du schon eine Nummer verfolgst. Mehrere trennst du mit Komma:
41,6008. - Mit OK bestätigen. Über Filter löschen kommst du jederzeit zur vollständigen Liste zurück.
Der wichtigste Handgriff kommt vor dem Filtern: Notiere dir die Uhrzeit, zu der das Problem auftrat. Ein Eintrag, der auf die Minute zum Absturz passt, ist deutlich verdächtiger als eine Meldung, die seit Monaten stündlich auftaucht. Und der Filter gilt immer nur für das gerade markierte Protokoll – wer im Systemprotokoll filtert und dann im Anwendungsprotokoll nichts findet, hat dort schlicht noch keinen Filter gesetzt.
Ereignis-ID und Quelle richtig deuten
Ein Eintrag besteht aus mehr als der Fehlermeldung. Drei Angaben im unteren Detailbereich bringen dich weiter:
- Quelle: Welche Komponente den Eintrag geschrieben hat, etwa
Microsoft-Windows-Kernel-PoweroderApplication Error. - Ereignis-ID: Die Nummer des Ereignistyps – eindeutig nur innerhalb dieser Quelle.
- Meldungstext: Die eigentliche Beschreibung, oft mit Datei-, Dienst- oder Modulnamen.
Daraus folgt die wichtigste Regel für die Recherche: immer Quelle + ID + Meldungstext zusammen suchen, nie die Nummer allein. Die 1000 bedeutet bei Application Error etwas völlig anderes als bei einer anderen Quelle. Ein paar Nummern begegnen dir im Systemprotokoll immer wieder:
| Ereignis-ID | Quelle | Bedeutung |
|---|---|---|
| 41 | Kernel-Power | Der Rechner startete neu, ohne sauber heruntergefahren zu sein – Stromverlust, Bluescreen oder Hard Hang. |
| 6008 | EventLog | Das vorherige Herunterfahren war unerwartet. Taucht meist zusammen mit ID 41 auf und nennt den Zeitpunkt. |
| 6006 | EventLog | Windows wurde ordnungsgemäß beendet. Nützlich als Gegenprobe: fehlt der Eintrag, war es kein normales Herunterfahren. |
| 1074 | User32 | Ein Programm oder ein Benutzer hat den Neustart bzw. das Herunterfahren ausgelöst – inklusive Name und Grund. |
| 1000 | Application Error | Ein Programm ist abgestürzt. Der Meldungstext nennt die verantwortliche Datei oder DLL. |
| 7031 / 7034 | Service Control Manager | Ein Dienst wurde unerwartet beendet – die Spur, wenn eine Funktion sporadisch ausfällt. |
Diese IDs sind Anhaltspunkte, keine Diagnose. Wer ein 41 findet, weiß, dass der Rechner hart ausging – nicht warum. Die Antwort steckt in den Einträgen unmittelbar davor und in den Detaildaten des Eintrags selbst.
Beispiel: Was hinter Ereignis-ID 41 wirklich steckt
Klick den Eintrag an und wechsle im Detailbereich auf den Reiter Details. Unter EventData stehen die Felder, die Microsoft in seiner Doku zu drei Fällen zusammenfasst:
BugcheckCodeist nicht 0: Der Neustart kam von einem Stoppfehler, also einem Bluescreen. Der Wert steht dezimal, die Bluescreen-Dokumentation arbeitet hexadezimal – 159 entspricht zum Beispiel 0x0000009f. Mit dem Hex-Wert suchst du weiter.PowerButtonTimestampist nicht 0: Jemand hat den Einschaltknopf gedrückt und gehalten. Dann liegt das eigentliche Problem davor: Der Rechner hing.- Beide Werte sind 0 oder es gibt gar kein Ereignis 41: Windows kam nicht mehr dazu, etwas zu schreiben. Typisch für Stromverlust, defektes oder zu schwaches Netzteil, leeren Akku und harte Hänger. Lohnt sich hier: nach Ereignis-ID 46 der Quelle
volmgrsuchen – die meldet, dass das Absturzabbild nicht initialisiert werden konnte, was auf eine fehlende oder zu kleine Auslagerungsdatei hindeutet.
Die Details dazu stehen im Microsoft-Supportartikel zu Ereignis-ID 41 (englisch), inklusive der Umrechnung von Dezimal- in Hex-Werte.
Wenn der Filter nichts Verdächtiges zeigt
Nicht jeder Fehler in der Ereignisanzeige gehört zu deinem Problem, und manchmal steht die entscheidende Meldung eben nicht im gefilterten Protokoll. Drei Wege bringen dich dann weiter.
1. Zuverlässigkeitsverlauf als Übersicht. Windows-Taste + R, perfmon /rel eingeben. Windows zeigt eine grafische Zeitleiste mit Abstürzen, fehlgeschlagenen Updates und Installationen der letzten Wochen – die Historie reicht bis zu einem Jahr zurück. Wer nur wissen will, wann es anfing, ist damit schneller als mit jedem Filter und kann anschließend gezielt im Protokoll nachschlagen.
2. Benutzerdefinierte Ansicht statt Einmal-Filter. Rechtsklick auf Benutzerdefinierte Ansichten im linken Baum, dann Benutzerdefinierte Ansicht erstellen…. Hier kombinierst du Ebenen, Zeitraum und mehrere Protokolle in einem gespeicherten Filter – praktisch, wenn du System- und Anwendungsprotokoll parallel im Blick behalten willst. Die Ansicht bleibt erhalten und lässt die Originalprotokolle unangetastet.
3. PowerShell, wenn es reproduzierbar sein soll. Die kritischen und Fehler-Einträge des Systemprotokolls der letzten sieben Tage holst du dir so (Level 1 = Kritisch, 2 = Fehler):
Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2; StartTime=(Get-Date).AddDays(-7)}
Und wenn du wissen willst, welcher Fehler am häufigsten auftritt, gruppierst du nach ID und Quelle:
Get-WinEvent -LogName System | Group-Object Id, ProviderName | Sort-Object Count -Descending
Welche Schlüssel -FilterHashtable sonst noch kennt – etwa ProviderName oder ID –, zeigt die PowerShell-Dokumentation zu Get-WinEvent. Der Umweg lohnt sich vor allem, weil die Abfrage jederzeit identisch wiederholbar ist.
Soll jemand anderes draufschauen, exportierst du das Protokoll im Originalformat mit dem Bordmittel wevtutil – die Datei lässt sich auf jedem anderen Windows-Rechner in der Ereignisanzeige öffnen:
wevtutil epl System C:\Temp\System.evtx
Der Ordner muss vorher existieren, sonst bricht der Befehl mit einer Pfadmeldung ab.
Hintergrund: Warum Windows überhaupt alles protokolliert
Die Ereignisanzeige ist im Kern eine zentrale Sammelstelle. Statt dass jedes Programm und jeder Treiber seine Meldungen irgendwo in eine eigene Textdatei schreibt, melden alle an denselben Dienst – den Windows-Ereignisprotokolldienst. Der legt die Einträge strukturiert in .evtx-Dateien ab, aus denen die Ereignisanzeige liest.
Genau dieses gemeinsame Format macht die Suche nach Fehlern in der Ereignisanzeige erst möglich: Weil Treiber, Dienste und Programme dieselben Ebenen und Zeitstempel benutzen, kannst du protokollübergreifend filtern und sehen, was zeitgleich passiert ist. Für die Fachinformatiker-Ausbildung ist das ein Klassiker – die Ereignisanzeige ist das erste Diagnosewerkzeug, zu dem man bei einem Windows-Störfall greift, lange bevor irgendein Tool eines Drittanbieters installiert wird.
Zwei Grenzen solltest du kennen: Protokolle sind Ringspeicher mit fester Maximalgröße – ist sie erreicht, überschreibt Windows die ältesten Einträge, weshalb sehr alte Vorfälle irgendwann verschwinden. Und viele Meldungen im Anwendungsprotokoll stammen von Software, die schlicht gesprächig ist. Wiederkehrende Einträge, die zeitlich exakt zum Störfall passen, bleiben das verlässlichste Signal.
Häufige Fragen
Wie öffne ich die Ereignisanzeige am schnellsten?
Windows-Taste + R drücken, eventvwr.msc eintippen, Enter. Alternativ die Windows-Taste drücken, Ereignisanzeige tippen und den Treffer öffnen. Für das Sicherheitsprotokoll den Treffer per Rechtsklick als Administrator starten.
In welchem Protokoll stehen Abstürze?
Abstürze von Windows selbst, Treiber- und Dienstprobleme stehen im Protokoll System. Stürzt ein einzelnes Programm ab, findest du den Eintrag im Protokoll Anwendung, meist mit Namen der fehlerhaften Datei.
Was bedeutet Ereignis-ID 41?
Quelle Kernel-Power: Der Rechner wurde neu gestartet, ohne sauber herunterzufahren. Im Reiter Details verrät ein BugcheckCode ungleich 0 einen Bluescreen, ein PowerButtonTimestamp ungleich 0 den gehaltenen Einschaltknopf. Sind beide 0, deutet das auf Stromverlust oder Hänger.
Sind alle rot markierten Einträge ein Problem?
Nein. Viele Fehler sind einmalig oder harmlos. Relevant sind Einträge, die wiederkehren oder zeitlich genau zum Störfall passen. Deshalb immer zuerst auf den Zeitpunkt des Problems filtern.
Wie lese ich die Protokolle per PowerShell aus?
Mit Get-WinEvent -FilterHashtable @{LogName=’System‘; Level=1,2; StartTime=(Get-Date).AddDays(-7)} holst du kritische und Fehler-Einträge der letzten sieben Tage. Level 1 steht für Kritisch, 2 für Fehler.
