How to Check Windows Crash or BSOD Logs

A sudden Blue Screen of Death (BSOD) can be one of the most frustrating experiences for any Windows 11 user. The system freezes, the screen flashes blue with an error code, and your computer reboots before you can even read what happened.

Fortunately, Windows automatically keeps detailed crash logs every time this occurs. These logs can help you identify what went wrong — whether it’s a faulty driver, bad hardware, or a misbehaving update.

In this guide, we’ll show you how to check Windows crash or BSOD logs using built-in tools and interpret the results to troubleshoot the root cause.

What You’ll Need

Before you start, make sure you have the following:

You’ll need administrator access to your Windows 11 PC and a stable system (one that at least boots properly). You won’t need any third-party software for this guide — just Windows’ built-in tools like Event Viewer, Reliability Monitor, and the BlueScreenView utility if you want deeper insight.

Tip: If your system keeps restarting after a BSOD, you can temporarily disable automatic restart under System Properties → Advanced → Startup and Recovery to read the stop code on-screen next time.

Step 1: Use Event Viewer to Find Crash Logs

Windows Event Viewer is the primary tool for examining BSOD and crash reports. It records every system and application event, including fatal system errors.

  1. Press Windows + X and select Event Viewer.
  2. In the left pane, expand Windows Logs → System.
  3. Click Filter Current Log from the right panel.
  4. In the filter window, check Critical and Error under Event Level.
  5. Click OK to display only relevant crash events.

Look for entries with Event ID 41 (Kernel-Power) or Event ID 1001 (BugCheck) — these typically indicate system crashes or BSODs.

To view details, double-click an entry. The “General” tab gives a summary, while the “Details” tab shows additional diagnostic data such as the stop code and the bugcheck string.

Step 2: Check the Reliability Monitor for Crash History

If Event Viewer feels overwhelming, Windows also includes a simpler graphical tool called Reliability Monitor. It presents system stability and crash data in an easy-to-read timeline.

  1. Press Windows + R, type perfmon /rel, and hit Enter.
  2. Wait a few seconds for the Reliability Monitor window to load.
  3. Look for red “X” marks on the graph — these represent critical events.
  4. Click a red X to view more details about that specific crash or system failure.

You can see the exact date and time of the BSOD, the affected program or driver, and links to Microsoft’s online troubleshooting recommendations.

Step 3: Analyze the Dump Files in File Explorer

When a crash occurs, Windows saves diagnostic information in dump files. These files contain a snapshot of your system’s memory at the moment of the crash.

By default, dump files are located at:

C:\Windows\Minidump

and

C:\Windows\MEMORY.DMP

To access them:

  1. Open File Explorer and navigate to C:\Windows\Minidump.
  2. Each file will have a timestamp in its name (e.g., Mini1108-01.dmp).
  3. You can open these files using third-party tools like BlueScreenView or WinDbg Preview for detailed analysis.

If the Minidump folder is empty, it may be because dump logging is disabled. To turn it on, go to Control Panel → System → Advanced system settings → Startup and Recovery, and under Write debugging information, choose Automatic memory dump.

Step 4: Use BlueScreenView for Easier Analysis

While Windows’ built-in tools are useful, they can be technical. If you want a simpler way to read BSOD details, use NirSoft’s BlueScreenView.

  1. Download it from https://www.nirsoft.net/utils/blue_screen_view.html.
  2. Launch the utility (it doesn’t need installation).
  3. It will automatically detect your Minidump folder and list recent crashes.

BlueScreenView displays the crash date, bug check code, and the driver or file that caused the error. The bottom pane highlights the specific file names linked to the crash — often a good indicator of whether it’s a driver or system file issue.

Step 5: Use PowerShell to Generate Crash Reports

If you prefer a command-line approach, you can use PowerShell to extract crash details.

  1. Open PowerShell as Administrator.
  2. Run the following command: Get-WinEvent -FilterHashtable @{LogName='System'; Level=1} | Format-List TimeCreated, Message

This command filters the System event log to show only critical crash events, along with their time and messages. It’s useful for quick summaries or automated logging scripts.

Step 6: Interpret the Crash Codes

Each BSOD or system crash includes a stop code — a specific identifier for what went wrong. Some common ones include:

  • IRQL_NOT_LESS_OR_EQUAL – Usually indicates a bad or outdated driver.
  • PAGE_FAULT_IN_NONPAGED_AREA – Often related to faulty RAM or driver issues.
  • SYSTEM_SERVICE_EXCEPTION – Can be triggered by software conflicts or corrupted system files.
  • DRIVER_POWER_STATE_FAILURE – Usually appears during sleep or hibernation transitions due to driver problems.

Once you know the code, search Microsoft’s official documentation or community forums for more detailed explanations and targeted fixes.

Step 7: Check for Hardware and Driver Problems

If you’ve identified a driver or hardware-related stop code, verify your system components.

  1. Run Device Manager and look for yellow warning icons next to drivers.
  2. Right-click and select Update driver.
  3. For memory-related errors, open Windows Memory Diagnostic by typing mdsched in the Start menu and pressing Enter.
  4. For storage-related issues, run chkdsk /f in Command Prompt.

These checks often resolve recurring BSODs caused by corrupted drivers or bad hardware sectors.

Wrapping Up

Blue screens and sudden crashes can feel unpredictable, but the truth is, Windows always leaves clues. By reviewing your system’s crash logs using Event Viewer, Reliability Monitor, or Minidump files, you can quickly identify the root cause and take action — whether that means updating a driver, replacing faulty RAM, or repairing corrupted files.

Once you get comfortable reading these logs, a BSOD stops being a mystery and becomes just another problem to solve. And while it’s never fun watching your screen go blue, at least now you’ll know where to start digging when it does.

Posted by Arpita

With a background in Computer Science, she is passionate about sharing practical programming tips and tech know-how. From writing clean code to solving everyday tech problems, she breaks down complex topics into approachable guides that help others learn and grow.

X