Collect recent system errors
Documentation: Microsoft Learn
Query recent System errors with a server-side Get-WinEvent filter. Inspect the event time, ID and provider to focus the investigation.
The script
Script reader
Inspect before you run
Inspect the script below. It does not run in this browser.
Inspection only — no command has run.
Show reference output
Inspect this example’s structure
Read the command and its supplied arguments. This example requires real PowerShell or its module; this diagram does not execute it.
Get-WinEvent -FilterHashtable @{LogName= "System";Level= 1 , 2;StartTime=(Get-Date).AddHours(-24)} | Select-Object TimeCreated,Id,ProviderName,Message- Stage 1Get-WinEvent
-FilterHashtable - Stage 2Select-Object
Positional values or no named parameters
How it works
Query recent System errors with a server-side Get-WinEvent filter. Inspect the event time, ID and provider to focus the investigation. LogName pins the channel, Level 1 and 2 select Critical and Error severities, and StartTime bounds the window using (Get-Date).AddHours(-24). Only matching records cross into PowerShell, and Select-Object projects the timestamp, event ID, provider name, and message body.
Adapting it
Widen or narrow the window by editing the AddHours value. Once the specific event is known, add an Id key to the same hashtable so the log service does the narrowing rather than a downstream filter.
Requirements
Local Administrators or Event Log Readers membership to read the System channel.
If the result is unexpected
The command returns "No events were found that match the specified selection criteria" as a red error, or it returns nothing at all on a server you know had trouble overnight.
Get-WinEvent treats an empty result as an error condition rather than an empty collection, so a quiet log produces a failure that halts the calling script. Scope is the other issue: the window is measured from the moment the command runs, and a log that has already rotated no longer holds the period being asked about. Restricting to Critical and Error also excludes Warning, where a lot of useful detail sits.
- Add -ErrorAction SilentlyContinue so an empty result stops aborting the surrounding script.
- Widen the window by increasing the AddHours value and check whether the events exist further back.
- Inspect retention with Get-WinEvent -ListLog System and read RecordCount against the configured maximum size.
- Add level 3 to the hashtable to include warnings when the errors alone explain nothing.
- Query the Application and Setup channels too, since the cause of a reboot is often recorded outside the System log.
Validate the result
The query returns records covering the incident window, and running the same line on a genuinely quiet host completes without writing an error.
Keep the check reliable
Raise the System log size on servers that matter, and always pair a filter hashtable query with an error action so an empty result is not treated as a failure.
