Ereignisanzeige mit PowerShell auslesen: Anleitung

Ein Programm stürzt ab, Windows startet unerwartet neu oder eine Anmeldung funktioniert nicht? Wenn Du die Windows Ereignisanzeige mit PowerShell auslesen möchtest, ist Get-WinEvent der richtige Befehl. Damit kannst Du gezielt nach Ereignisprotokolleinträgen suchen und auch die Ereigniseinträge exportieren.

Ereignisanzeige mit PowerShell auslesen: die Schnelllösung

Die folgenden Zeilen zeigen die 20 neuesten Einträge des Systemprotokolls einschließlich Zeitpunkt, Ereignis-ID, Ereignisebene, meldender Komponente und Beschreibung. Du führst sie in einer PowerShell-Konsole aus:

Get-WinEvent -LogName System -MaxEvents 20 |
    Format-List TimeCreated, Id, LevelDisplayName, ProviderName, Message

System bezeichnet das Protokoll, -MaxEvents 20 begrenzt die Ausgabe. Mit Format-List erscheinen die Angaben untereinander. Für die reine Anzeige brauchst Du weder eine Skriptdatei noch eine Änderung der PowerShell-Ausführungsrichtlinie. Wie Du ausschließlich Fehler, bestimmte Ereignis-IDs oder einen gewünschten Zeitraum abfragst, zeigen die nächsten Abschnitte.

Was liest Get-WinEvent aus der Windows-Ereignisanzeige aus?

Die Ereignisanzeige ist die grafische Oberfläche für Windows-Ereignisprotokolle. Windows-Komponenten, Dienste und Anwendungen schreiben dort strukturierte Meldungen hinein. PowerShell liest dieselben Protokolle aus und stellt die Einträge als Objekte bereit. Dadurch kannst Du einzelne Eigenschaften auswählen, Ergebnisse zählen und Berichte speichern.

Die grundlegende Aufteilung und Bedienung erklärt unser Überblick zur Windows-Ereignisanzeige. Für PowerShell sind insbesondere diese Protokollnamen wichtig:

Bereich	Protokollname für PowerShell	Typische Inhalte
System	System	Meldungen von Windows-Komponenten, Treibern und Diensten.
Anwendung	Application	Programmfehler und Meldungen installierter Anwendungen.
Sicherheit	Security	Überwachungsereignisse, etwa zu Anmeldungen, abhängig von der eingerichteten Überwachung.
Anwendungs- und Dienstprotokolle	Vollständiger Kanalname, beispielsweise Microsoft-Windows-WindowsUpdateClient/Operational	Komponentenspezifische Ereignisse, hier zum Windows Update Client.

Auch auf einem deutschen Windows heißt das Anwendungsprotokoll im Befehl Application, nicht Anwendung. Außerdem ist nicht jede technische Protokolldatei ein Ereignisprotokoll. Eine gewöhnliche Textdatei mit der Endung .log lässt sich nicht einfach an Get-WinEvent übergeben.

Get-WinEvent oder Get-EventLog: Welcher Befehl ist richtig?

Für neue Abfragen verwendest Du Get-WinEvent. Der ältere Befehl Get-EventLog beschränkt sich auf klassische Ereignisprotokolle und gehört nicht mehr zum regulären Befehlsumfang von PowerShell 7. Get-WinEvent unterstützt dagegen auch die modernen Ereigniskanäle unter Anwendungs- und Dienstprotokolle.

Die Beispiele dieser Anleitung sind für Windows PowerShell 5.1 und PowerShell 7 unter Windows gedacht. Get-WinEvent ist ein Windows-spezifischer Befehl. Die plattformübergreifende Verfügbarkeit von PowerShell 7 bedeutet nicht, dass diese Ereignisabfragen unverändert unter Linux oder macOS funktionieren.

Schritt für Schritt: Windows-Fehler der letzten 24 Stunden anzeigen

1. PowerShell mit passenden Berechtigungen starten

Über die Windows-Suche findest Du Windows PowerShell. Bei Bedarf startest Du sie mit der Option Als Administrator ausführen. Alternativ kannst Du das Windows Terminal als Administrator starten und darin eine PowerShell-Registerkarte verwenden. Eine geöffnete CMD-Registerkarte ist dafür nicht geeignet.

Für einige Protokolle reichen normale Leserechte. Das Sicherheitsprotokoll und geschützte Kanäle können zusätzliche Berechtigungen erfordern. Auf einem verwalteten Firmenrechner bleiben die Vorgaben Deiner IT maßgeblich. Ein administrativ gestartetes Fenster ersetzt keine fehlende Zugriffsberechtigung.

Mit der folgenden Abfrage erkennst Du die Version der laufenden Sitzung. Weitere Varianten findest Du unter PowerShell-Version abfragen.

$PSVersionTable.PSVersion

2. Protokollnamen und vorhandene Einträge überprüfen

Zunächst lässt Du Dir die drei klassischen Windows-Protokolle anzeigen. Die Ausgabe zeigt auch, ob ein Protokoll aktiviert ist und wie viele Einträge darin vorhanden sind:

Get-WinEvent -ListLog System, Application, Security |
    Select-Object LogName, IsEnabled, RecordCount

-ListLog liest hier Informationen über die Protokolle, nicht deren einzelne Ereignisse. Für einen umfassenderen Überblick ist auch Get-WinEvent -ListLog * möglich. Dabei können Zugriffsfehler für geschützte Kanäle auftreten. Für die erste Fehlersuche ist eine gezielte Auswahl meist übersichtlicher.

3. Fehler und kritische Ereignisse zeitlich eingrenzen

Die folgende Abfrage erfasst Fehler und kritische Ereignisse aus System und Anwendung innerhalb der letzten 24 Stunden. Die gefundenen Objekte werden in $Ereignisse gespeichert. Diese Variable verwenden wir später für die Häufigkeitsauswertung und den CSV-Export weiter. Die zusammengehörigen Beispiele führst Du deshalb in derselben PowerShell-Sitzung aus.

$Jetzt = Get-Date

$Filter = @{
    LogName   = 'System', 'Application'
    Level     = 1, 2
    StartTime = $Jetzt.AddHours(-24)
    EndTime   = $Jetzt
}

$Ereignisse = @(Get-WinEvent -FilterHashtable $Filter)

$Ereignisse |
    Select-Object -First 30 TimeCreated, LogName, Id, LevelDisplayName, ProviderName |
    Format-Table -AutoSize

Die Abfrage übernimmt alle passenden, noch vorhandenen Ereignisse dieses Zeitfensters. Nur die anschließende Bildschirmausgabe ist auf 30 Zeilen begrenzt. Die Schreibweise @(...) sorgt dafür, dass die Variable eine Sammlung enthält, auch wenn lediglich ein Ereignis gefunden wird.

-FilterHashtable übergibt die Filterkriterien unmittelbar an die Ereignisabfrage. Bei größeren Protokollen vermeidest Du damit, zunächst sämtliche Einträge einzulesen und erst danach auszusortieren. Die Werte innerhalb von Level = 1, 2 sind Alternativen. Unterschiedliche Kriterien wie Ebene und Zeitraum müssen gleichzeitig passen.

Falls keine Einträge zum Filter passen, kann Get-WinEvent eine entsprechende Fehlermeldung ausgeben. Das ist nicht automatisch ein Defekt. Die gezielte Behandlung dieses Falls findest Du weiter unten. Eine leere Trefferliste allein beweist außerdem nicht, dass der Rechner vollständig fehlerfrei arbeitet.

4. Ereignisebenen und Meldungstexte richtig lesen

Die Zahl bei Level bezeichnet die Ereignisebene. Sie ist nicht mit der Ereignis-ID zu verwechseln. Für die üblichen Windows-Ereignisse gelten folgende Standardwerte:

Level	Bedeutung	Einordnung
0	LogAlways	Keine übliche Schweregradzuordnung, beispielsweise bei bestimmten Überwachungsereignissen.
1	Kritisch	Schwerwiegendes Ereignis, das näher untersucht werden sollte.
2	Fehler	Eine Komponente meldet ein Problem.
3	Warnung	Hinweis auf ein mögliches oder bevorstehendes Problem.
4	Information	Statusmeldung oder protokollierter Ablauf.
5	Ausführlich	Detaillierte Diagnoseinformationen.

Für eine Suche einschließlich Warnungen änderst Du die Filterzeile auf Level = 1, 2, 3. Zahlenwerte sind für solche Abfragen zuverlässiger als ein Vergleich mit übersetzten Bezeichnungen wie Fehler oder Error.

Eine Tabelle eignet sich für den Überblick, kann lange Inhalte aber abschneiden. Die ausführlichen Meldungen der ersten drei Treffer erhältst Du so:

$Ereignisse |
    Select-Object -First 3 |
    Format-List TimeCreated, LogName, Id, LevelDisplayName, ProviderName, Message

ProviderName nennt die meldende Komponente. Message enthält die Beschreibung. Für eine brauchbare Diagnose betrachtest Du diese Angaben gemeinsam mit dem Zeitpunkt. Eine Ereignis-ID allein ist nicht systemweit eindeutig: Unterschiedliche Anbieter können dieselbe Nummer für verschiedene Ereignisse verwenden.

Ereignisanzeige nach Ereignis-ID, Zeitraum und Text filtern

Eine bestimmte Ereignis-ID mit dem passenden Provider suchen

Nach einem unerwarteten Neustart ist beispielsweise Ereignis 41 des Providers Microsoft-Windows-Kernel-Power interessant. Diese Abfrage sucht solche Einträge im Systemprotokoll der vergangenen sieben Tage:

Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-Kernel-Power'
    Id           = 41
    StartTime    = (Get-Date).AddDays(-7)
} |
    Format-List TimeCreated, Id, ProviderName, Message

Ereignis 41 bedeutet, dass Windows nach einem nicht ordnungsgemäßen Herunterfahren wieder gestartet wurde. Es beweist weder einen Netzteildefekt noch einen bestimmten Treiberfehler. Der Eintrag entsteht beim anschließenden Start und nennt nicht zwingend den exakten Zeitpunkt der ursprünglichen Störung.

Mehrere IDs lassen sich als Zahlenliste angeben, etwa Id = 41, 42. Dabei sollten die ausgewählten Nummern zum angegebenen Provider passen. Die Unterschiede zwischen Befehlsparametern und ihren Werten erläutert unser Leitfaden zu PowerShell-Parametern.

Ein enges Zeitfenster statt eines ganzen Tages untersuchen

Kennst Du die ungefähre Uhrzeit des Problems, ist ein kleines Zeitfenster hilfreicher als eine große Fehlerliste. Im folgenden Beispiel werden Systemereignisse des heutigen Tages zwischen 10:00 und 10:30 Uhr abgefragt. Die Uhrzeiten sind Beispielwerte, die Du an Deinen Vorfall anpasst.

$Beginn = (Get-Date).Date.AddHours(10)
$Ende = $Beginn.AddMinutes(30)

Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    StartTime = $Beginn
    EndTime   = $Ende
} |
    Sort-Object TimeCreated |
    Format-List TimeCreated, Id, ProviderName, Message

Hier wird bewusst nicht nach der Ereignisebene gefiltert. Auch eine Informationsmeldung kann zeigen, welcher Dienst kurz vor der Störung gestartet wurde. Die Sortierung stellt den Ablauf vom früheren zum späteren Ereignis dar.

(Get-Date).Date steht für den heutigen Tagesbeginn. Das unterscheidet sich von einem zurückliegenden Zeitraum von 24 Stunden. Die Filter erhalten echte Datumsobjekte statt mehrdeutiger Datumszeichenfolgen. Bei unplausiblen Zeitangaben solltest Du auch Datum und Uhrzeit unter Windows 11 überprüfen.

Nach einem Programmnamen im Meldungstext suchen

Für eine freie Textsuche grenzt Du zunächst Protokoll und Zeitraum ein. Erst anschließend durchsucht Where-Object die Beschreibungen. Das folgende Beispiel sucht nach Meldungen zum klassischen Outlook anhand des Programmnamens OUTLOOK.EXE:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    StartTime = (Get-Date).AddDays(-7)
} |
    Where-Object { $_.Message -like '*OUTLOOK.EXE*' } |
    Format-List TimeCreated, Id, ProviderName, Message

Der Suchtext lässt sich durch einen anderen Programmnamen, Dateipfad oder Fehlertext ersetzen. Die Sternchen erlauben zusätzlichen Text vor und hinter dem Begriff. Der Vergleich mit -like unterscheidet hier nicht zwischen Groß- und Kleinschreibung. Laufende Programme und ihre Prozessnamen kannst Du ergänzend mit PowerShell Get-Process untersuchen.

Wichtig: Ein vorangestelltes -MaxEvents 100 würde die Textsuche auf die zuletzt abgerufenen 100 Ereignisse begrenzen. Ältere Treffer innerhalb der sieben Tage könnten dadurch fehlen. Außerdem ist Message kein allgemeiner Volltextschlüssel für FilterHashtable. Für diesen Anwendungsfall bleibt die Kombination aus Vorfilterung und Where-Object sinnvoll.

Windows Update und fehlgeschlagene Anmeldungen auslesen

Das Ereignisprotokoll des Windows Update Clients anzeigen

Bei Update-Problemen lohnt sich ein Blick in den passenden Dienstkanal. Zunächst kannst Du Dir die dazugehörigen Protokollnamen anzeigen lassen:

Get-WinEvent -ListLog '*WindowsUpdate*' |
    Select-Object LogName, IsEnabled, RecordCount

Die letzten 30 Einträge des üblichen Windows-Update-Kanals rufst Du anschließend mit dessen vollständigem Namen ab:

Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 30 |
    Format-List TimeCreated, Id, LevelDisplayName, Message

Das sind Ereignisse des Windows Update Clients, kein vollständiger Ersatz für alle Installations- und Diagnoseprotokolle. Ein nicht vorhandener oder deaktivierter Kanal lässt sich nicht durch einen anderen Filter reparieren. Auch nach einer Aktivierung werden zuvor nicht aufgezeichnete Vorgänge nicht nachträglich ergänzt.

Fehlgeschlagene Anmeldungen mit Ereignis-ID 4625 finden

Fehlgeschlagene Anmeldungen können im Sicherheitsprotokoll als Ereignis 4625 erscheinen. Voraussetzung ist, dass die passende Überwachung aktiviert war und Du das Protokoll lesen darfst. Die Abfrage erfolgt auf dem Rechner, auf dem der Anmeldeversuch stattgefunden hat:

Get-WinEvent -FilterHashtable @{
    LogName      = 'Security'
    ProviderName = 'Microsoft-Windows-Security-Auditing'
    Id           = 4625
    StartTime    = (Get-Date).AddDays(-1)
} -MaxEvents 20 |
    Format-List TimeCreated, Id, Message

Hier gehört kein zusätzlicher Filter Level = 2 hinein. Ereignis 4625 verwendet Level 0. Der fehlgeschlagene Überwachungsvorgang wird anders gekennzeichnet als ein gewöhnlicher Fehler aus dem Systemprotokoll.

In der Beschreibung sind unter anderem das betroffene Konto, die Anmeldeart und die Fehlerangaben interessant. Nicht jeder Datensatz enthält eine aussagekräftige IP-Adresse. Ein einzelner fehlgeschlagener Versuch beweist außerdem noch keinen Angriff. Bei Domänenkonten helfen ergänzend die PowerShell-Befehle für Active Directory, den Kontozustand zu untersuchen.

Häufige Ereignisse mit PowerShell zählen

Eine lange Trefferliste wird verständlicher, wenn Du wiederkehrende Ereignisse zusammenfasst. Dieses Beispiel verwendet die zuvor gespeicherte Variable $Ereignisse aus der 24-Stunden-Abfrage. Es gruppiert nach Protokoll, Provider und ID und zeigt die zehn häufigsten Kombinationen:

$Ereignisse |
    Group-Object -Property LogName, ProviderName, Id |
    Sort-Object Count -Descending |
    Select-Object -First 10 Count, Name

Count enthält die Anzahl, Name die zusammengefassten Gruppenmerkmale. Gezählt werden ausschließlich die zuvor abgerufenen Datensätze, nicht automatisch sämtliche Ereignisse des Rechners. Da unsere Ausgangsabfrage keine Gesamtbegrenzung verwendet, entsteht hier keine Auswertung einer bloßen 30-Zeilen-Vorschau.

Eine hohe Anzahl hilft bei der Priorisierung, ist aber kein Beweis für die Ursache Deines Problems. Hundert Wiederholungen eines Folgefehlers können weniger aussagekräftig sein als ein einzelner Eintrag unmittelbar vor dem Ausfall.

Ereignisanzeige mit PowerShell als CSV exportieren

Für einen Bericht übergibst Du die Ereignisobjekte an Export-Csv. Das folgende Beispiel exportiert die erfolgreich geladenen Daten aus $Ereignisse. Es legt im Benutzerprofil einen Berichtsordner an, verwendet einen Dateinamen mit Zeitstempel und verhindert das Überschreiben einer bereits vorhandenen Datei.

if ($Ereignisse.Count -gt 0) {
    $Zielordner = Join-Path $env:USERPROFILE 'Ereignisberichte'
    New-Item -Path $Zielordner -ItemType Directory -Force -ErrorAction Stop |
        Out-Null

    $Dateiname = 'Ereignisse-{0}.csv' -f (Get-Date -Format 'yyyyMMdd-HHmmss')
    $Datei = Join-Path $Zielordner $Dateiname

    $Codierung = if ($PSVersionTable.PSVersion.Major -ge 6) {
        'utf8BOM'
    } else {
        'UTF8'
    }

    $Ereignisse |
        Select-Object MachineName, LogName, RecordId, TimeCreated,
            Id, LevelDisplayName, ProviderName, Message |
        Export-Csv -Path $Datei -Delimiter ';' -NoTypeInformation -Encoding $Codierung -NoClobber -ErrorAction Stop

    Write-Output "CSV gespeichert: $Datei"
} else {
    Write-Warning 'Keine geladenen Ereignisse zum Exportieren vorhanden.'
}

Die Codierung berücksichtigt den Unterschied zwischen Windows PowerShell 5.1 und PowerShell 7. Beide Varianten erzeugen hier UTF-8 mit einer Byte-Reihenfolge-Markierung, kurz BOM. Das erleichtert Programmen wie Excel die Erkennung von Umlauten. Das Semikolon trennt die Spalten.

Beim Weiterarbeiten kannst Du die CSV-Datei in Excel übernehmen. Falls alle Inhalte in einer einzigen Spalte landen, wählst Du beim Import ausdrücklich das Semikolon als Trennzeichen. Für andere Empfänger lässt sich das CSV-Trennzeichen auf ein Komma umstellen, indem Du im Exportbefehl -Delimiter ',' verwendest.

Vor Export-Csv gehört weder Format-Table noch Format-List. Diese Befehle erzeugen Formatierungsinformationen für die Bildschirmausgabe statt der gewünschten Ereignisobjekte. Select-Object ist dagegen richtig, wenn Du die Spalten des Berichts festlegen möchtest.

Ereignisberichte können Benutzernamen, Rechnernamen, Dateipfade und Netzwerkadressen enthalten. Für die Speicherung ist ein zugriffsgeschützter Bereich sinnvoll. Vor einer Weitergabe sollten vertrauliche Angaben entfernt werden. Eine CSV-Datei enthält außerdem nur die ausgewählten Eigenschaften. Sie ist keine vollständige Archivkopie des Ereignisprotokolls.

EVTX-Dateien exportieren und mit Get-WinEvent auslesen

Für eine spätere Untersuchung eignet sich das native Ereignisformat EVTX. Aus einer PowerShell-Konsole kannst Du dafür das integrierte Windows-Werkzeug wevtutil aufrufen. Das folgende Beispiel exportiert das vorhandene Systemprotokoll ins Benutzerprofil und liest danach zehn Einträge aus der erzeugten Datei:

$EvtxName = 'System-{0}.evtx' -f (Get-Date -Format 'yyyyMMdd-HHmmss')
$EvtxDatei = Join-Path $env:USERPROFILE $EvtxName

wevtutil.exe epl System "$EvtxDatei"

if ($LASTEXITCODE -ne 0) {
    throw 'Der EVTX-Export ist fehlgeschlagen.'
}

Get-WinEvent -Path $EvtxDatei -MaxEvents 10 |
    Format-List TimeCreated, Id, ProviderName, Message

Dieser Export enthält das Systemprotokoll ohne den zuvor verwendeten 24-Stunden- oder Fehlerfilter. Er ist unabhängig von $Ereignisse. Für eine bereits vorhandene Datei übergibst Du ihren tatsächlichen Pfad an -Path. Die Endung einer CSV-Datei lediglich in EVTX zu ändern, erzeugt dagegen kein lesbares Ereignisarchiv.

Auf einem anderen Rechner können die Ereignisdaten vorhanden sein, während die lesbare Beschreibung fehlt. Dann fehlen möglicherweise die passenden Meldungsressourcen des Providers. Das Archiv ist deshalb nicht zwangsläufig beschädigt. Für die weitere Untersuchung sind die strukturierten Ereignisdaten besonders wichtig.

Ereignisanzeige eines anderen Computers per PowerShell auslesen

Mit -ComputerName fragst Du einen erreichbaren Windows-Rechner im Netzwerk ab. Im folgenden Beispiel ersetzt Du PC-01 durch den tatsächlichen Computernamen:

Get-WinEvent -ComputerName 'PC-01' -FilterHashtable @{
    LogName   = 'System'
    Level     = 1, 2
    StartTime = (Get-Date).AddDays(-1)
} -MaxEvents 30 |
    Select-Object MachineName, TimeCreated, Id, ProviderName, Message

Get-WinEvent verwendet bei dieser Variante den Remotezugriff auf den Windows-Ereignisprotokolldienst. Der Befehl benötigt dafür kein aktiviertes PowerShell-Remoting über WinRM. Erforderlich sind jedoch passende Rechte auf dem Zielrechner und die dafür vorgesehenen Firewallfreigaben zur Remote-Ereignisprotokollverwaltung.

Bei der Meldung Der RPC-Server ist nicht verfügbar kommen unter anderem Namensauflösung, Erreichbarkeit, Dienstzustand und Firewallregeln infrage. Ein erfolgreicher Ping allein beweist nicht, dass der Ereignisprotokollzugriff funktioniert. Die Firewall pauschal abzuschalten ist keine geeignete Lösung.

Für ein anderes berechtigtes Konto kannst Du zusätzlich -Credential (Get-Credential) angeben. Das Kennwort wird dann abgefragt und nicht als Klartext in den Befehl geschrieben. Zugangsdaten allein setzen allerdings keine Netzwerksperre oder fehlende Berechtigung außer Kraft.

Get-WinEvent funktioniert nicht: typische Fehler gezielt eingrenzen

Keine Ereignisse gefunden: Filter prüfen und Fehler unterscheiden

Eine Meldung über fehlende Treffer kann bei einer korrekten Abfrage auftreten. Vielleicht liegt das Problem außerhalb des Zeitfensters, der Providername passt nicht oder der betreffende Vorgang wurde gar nicht protokolliert. Deshalb solltest Du nicht jeden Abfragefehler pauschal mit SilentlyContinue ausblenden.

Für wiederverwendbare Abfragen lässt sich der konkrete Fall NoMatchingEventsFound gesondert behandeln. Dieses Beispiel ist unabhängig von den zuvor angelegten Variablen:

$Suchfilter = @{
    LogName   = 'System'
    Level     = 1, 2
    StartTime = (Get-Date).AddHours(-1)
}

try {
    Get-WinEvent -FilterHashtable $Suchfilter -ErrorAction Stop |
        Format-List TimeCreated, Id, ProviderName, Message
}
catch {
    if ($_.FullyQualifiedErrorId -like 'NoMatchingEventsFound*') {
        Write-Output 'Keine passenden Ereignisse im gewaehlten Zeitraum gefunden.'
    } else {
        throw
    }
}

Andere Fehler werden weitergemeldet. Dadurch bleibt beispielsweise ein Berechtigungsproblem sichtbar, statt als scheinbar ereignisloser Zeitraum durchzugehen. Für regelmäßig benötigte Abfragen kannst Du die Befehle später in einem PowerShell-Skript speichern.

Ein Protokoll oder der Befehl wird nicht gefunden

Bei einem unbekannten Protokollnamen liefert die Abfrage mit ListLog den tatsächlich registrierten Namen. Ein sichtbarer Kategoriename aus der Ereignisanzeige ist nicht zwangsläufig bereits der vollständige Kanalname. Auch installierte Programme und Windows-Rollen beeinflussen, welche Kanäle vorhanden sind.

Wird Get-WinEvent selbst nicht erkannt, kannst Du mit Get-Command Get-WinEvent prüfen, ob der Befehl in der aktuellen PowerShell verfügbar ist. Eine Eingabeaufforderung, eine Sitzung auf einem anderen Betriebssystem oder eine eingeschränkte Verwaltungsumgebung sind keine gleichwertigen Ausführungsorte.

Die Ereignisbeschreibung fehlt

Bei fehlendem Meldungstext kannst Du die XML-Darstellung eines Ereignisses untersuchen. Dieses Beispiel verwendet den neuesten Eintrag des lokalen Systemprotokolls:

$Eintrag = Get-WinEvent -LogName System -MaxEvents 1
$Eintrag.ToXml()

Die XML-Daten enthalten die strukturierten Ereigniseigenschaften. Für spätere Skripte ist es sinnvoll, benötigte Felder anhand ihrer Namen auszuwerten. Eine feste Position wie Properties[5] kann bei einem anderen Ereignistyp oder einer anderen Ereignisversion etwas völlig anderes enthalten.

Praxistipp: Aus einer Ereignisliste eine nachvollziehbare Diagnose machen

Angenommen, eine Anwendung hängt jeden Morgen kurz nach der Anmeldung. Die größte Fehlerzahl im gesamten Wochenprotokoll ist dann nicht automatisch der beste Ausgangspunkt. Notiere zunächst den Zeitpunkt und die konkrete Aktion. Anschließend vergleichst Du die unmittelbar davor und danach entstandenen Ereignisse.

Achte darauf, welche Meldung zuerst erscheint und welche Einträge lediglich darauf folgen. Bei einem noch laufenden Problem ergänzt der Ressourcenmonitor unter Windows 11 die historischen Protokolle um die aktuelle Systemaktivität. So kannst Du Beobachtungen aus unterschiedlichen Perspektiven zusammenführen.

Erst nach dieser Eingrenzung leitest Du eine passende Maßnahme ab. Danach wiederholst Du denselben Vorgang und vergleichst ein entsprechend neues Zeitfenster. Eine Ereignisanzeige ohne rote Einträge ist kein Selbstzweck. Entscheidend ist, ob die tatsächliche Störung verstanden und behoben wurde.

FAQ: Häufige Fragen zum Auslesen der Ereignisanzeige mit PowerShell

Fazit: Ereignisprotokolle gezielt statt vollständig durchsuchen

Wenn Du die Ereignisanzeige mit PowerShell auslesen möchtest, dann verwende bitte den Befehl „Get-WinEvent“. Wichtig ist, dass Du die richtigen Daten der Ereignisprotokolleinträge auswählst, damit Du zu einem guten Ergebnis kommst. Oftmals ist es auch besser, die Daten in eine CSV-Datei oder in ein EVTX-Archiv zu exportieren und diese dann ggf. mit Excel weiter zu untersuchen.