The Instant Crash Log Reader: Bypassing the GUI

PowerShell Get-WinEvent Log Parsing & Event Viewer CLI Troubleshooting Guide

4 min. read

The Ticket: The Laggy Remote Session

You are remoted into a client workstation over a heavily congested network connection. The user reports their laptop unexpectedly hard crashed and rebooted during a client presentation an hour ago. You attempt to open the Windows Event Viewer to investigate, but the MMC snap-in hangs on "Reading data" for three solid minutes because the System log is bloated with thousands of entries. You do not have time to wait for a clunky graphical interface to parse XML files. We need to grab the most recent critical errors straight from the command line and get out.

Pre-Flight Check

• Permissions: Local Administrator rights. Standard users cannot read the System or Security event logs.
• Tools: PowerShell running as Administrator.
• Impact: Zero. This is a read-only command that simply queries existing log files.

[!WARNING] The Risk Factor: While running the script poses no risk to the machine, there is a high risk to your diagnostic time. Windows generates a lot of terrifying looking "Error" logs for things that do not matter, such as DCOM permissions (Event ID 10016). Do not fall down a rabbit hole chasing benign errors. Focus specifically on BugCheck, Kernel-Power, and disk-related IDs.

The Solution: The Filtered Log Pull

Taking a look at the script provided in image_672986.png, the logic is incredibly solid. However, there is a formatting trap waiting for you. Using Format-Table -AutoSize is great for short data, but the Message property of a crash log usually contains a massive paragraph of text and hexadecimal codes. If your console window is not wide enough, PowerShell will truncate the message and hide the exact bugcheck code you need.

We are going to modify the script to use Format-List instead, which stacks the output cleanly so you can read the entire error description without anything getting cut off.

PowerShell

# *** 404 & More: The Instant Crash Log Reader ***

# Pulls the 10 most recent Critical and Error logs from the System channel
Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2} -MaxEvents 10 | 
Select-Object TimeCreated, Id, ProviderName, Message | 
Format-List

The "Why" (Root Cause)

Why is the traditional Event Viewer GUI so painfully slow on older machines or over remote sessions? The eventvwr.msc console is a legacy Microsoft Management Console (MMC) snap-in. When you click on the System log, the GUI attempts to read, parse, and render massive raw .evtx files into an interactive list before applying any filters you have set. If a machine has been running for years without clearing the logs, that file can easily be gigabytes in size.

Under the Hood (Technical Deep Dive)

The secret to this script's speed is the -FilterHashtable parameter combined with the Get-WinEvent cmdlet.

Older guides often tell you to use Get-EventLog. You should avoid that cmdlet at all costs. Get-EventLog pulls the entire log file into your system memory first, and then pipes it to a Where-Object filter. It is wildly inefficient.

Get-WinEvent utilizes the modern Windows Event Log API. By passing a hashtable @{LogName='System'; Level=1,2}, you are instructing the Windows API to filter the XML data at the source level. PowerShell only retrieves the exact 10 records you asked for, completely bypassing the need to load the rest of the garbage data into RAM. (Note: Level 1 is Critical, Level 2 is Error).

RMM & Automation Tips

• The Post-Crash Alert: You can turn this into an automated diagnostic tool. Set up an alert in your RMM that triggers whenever a machine logs Event ID 41 (Kernel-Power). Have the RMM automatically execute this PowerShell script in the background and dump the output directly into the ticket notes. By the time your dispatcher assigns the ticket, the exact crash codes are already waiting for you.

Troubleshooting & Edge Cases

• Edge Case 1: The "No Events Found" Error. If the script runs successfully but returns absolute silence, there are no Critical or Error events in the recent log history. You can expand the net by changing -MaxEvents 10 to 50, or by adding Level 3 (Warnings) to the hashtable: Level=1,2,3.
• Edge Case 2: Identifying the BSOD. When parsing the output, look specifically for a ProviderName labeled Microsoft-Windows-WER-SystemErrorReporting or BugCheck (Event ID 1001). The Message field here will contain the actual hex code (like 0x000000EF) allowing you to pinpoint the exact driver failure.

If you want to see more guides, scripts, and technical deep dives just like this, make sure to follow us on Twitter, check out our Facebook page, and sign up for the weekly 404+ newsletter! ✌️