How to check Windows crash logs
Last updated on:In this page
What are Windows crash logs?
Windows crash logs are system-generated records that capture critical information about crashes, errors, or system failures that occur on a Windows machine. These logs are typically stored and can be accessed using the Event Viewer. Crash logs provide details such as the cause of the crash, the affected application or driver, and the system’s state at the time of failure.
Crash logs are essential for diagnosing and troubleshooting system issues, helping IT professionals and system administrators identify the root cause of problems such as blue screen of death (BSOD) errors, application crashes, or unexpected reboots. By analyzing these logs, users can pinpoint hardware or software issues, isolate malfunctioning components, and take corrective measures to prevent future crashes, ensuring system stability and performance. This article elaborates on the different ways of checking crash logs in Windows 11 and 10.
There are several types of crashes captured in Windows crash logs, including:
- System crashes (Blue Screen of Death—BSOD): Critical errors forcing a system restart, logged with STOP error codes and mini-dump files. Potential causes include faulty hardware or drivers.
- Application crashes: Failures in software programs due to bugs or memory issues, logging faulting modules and exception codes.
- Service failures: Crashes in Windows services caused by misconfigurations or resource issues, logging the service name and error message.
- Driver failures: Crashes due to faulty drivers, logging driver details and associated hardware.
- Kernel crashes: Errors in the OS kernel, often caused by hardware issues, logging kernel error codes and crash dumps.
Crash logs help you with:
- Root cause analysis: By analyzing error codes and event details, administrators can trace the underlying issue that led to a failure—hardware failure, driver malfunction, or software conflict.
- Preventive action: Regularly reviewing crash logs helps IT teams spot trends (e.g., frequent crashes tied to a specific driver or program) and apply fixes—such as updating drivers or removing faulty software—before major failures occur.
- Compliance and auditing: In some industries, crash logs provide records of system behavior that help organizations prove incidents were addressed and systems restored promptly.
How to view and access Windows crash logs in Windows 10 and 11?
This section elaborates on the ways to troubleshoot a Windows device or application crash using the Event Viewer, the command-line interface, and crash dumps.
1. Using the Event Viewer
The Event Viewer is the primary tool for checking crash logs in Windows. It provides an organized way to browse and filter system events. To check the crash logs in a Windows 10 or Windows 11 system:
- Open the Event Viewer by pressing Win + R, entering eventvwr in the Run command prompt, and pressing Enter.
- In the left-hand pane, expand Windows Logs and select System. The Actions Menu will display a list of events.
- Click the Filter Current Log button in the Actions Menu. In the Filter window, check the boxes for Critical and Error. Click OK to apply the filter. The list will now show only events related to crashes and critical errors.
- Look for crash-related event IDs, such as 1001 (BugCheck) or 41 (Kernel-Power), which indicate system crashes or unexpected shutdowns. Click any entry to view detailed information, including the time of the crash, error codes, and the source.


Create a custom view to see all crash logs
To bring every crash-related event into one focused view in Windows 11:
- Open Event Viewer: Press Windows + X and select Event Viewer, or press Windows + R, type eventvwr.msc, and press Enter.
- Navigate to Custom Views: Expand the Custom Views section in the left-hand panel.

- Create a new custom view: Right-click Custom Views and select Create Custom View.

- Set filter criteria in the Create Custom View window:
- Log: In the Event logs dropdown, check Windows Logs, then select both System and Application.
- Event level: Check Critical and Error.

- Event sources: For system crashes (e.g., BSOD), set the source to BugCheck. For application crashes, set it to Application Error.
- Time range: Optionally filter logs to a specific date and time range.

- Save the custom view: Click OK, name it something like Crash Logs, and click OK again.
- View crash logs: Select the saved view under Custom Views to see all critical and error events from both the System and Application logs. Double-click any entry for details.

2. Using the command-line interface
If you prefer using the command line, you can access crash logs via Command Prompt:
- Open Command Prompt or PowerShell as an administrator by pressing Win + X and selecting Command Prompt (Admin).
- Use the following command to display the last 10 crash events (event ID 1001) from the System logs:
wevtutil qe System /f:text /c:10 /q:"*[System[(EventID=1001)]]" - This command filters out crash events from the logs and provides a textual output. You can adjust the number of events (/c:10) as needed. The output will display event details, including the timestamp, the event ID, and error descriptions, allowing you to diagnose the problem without navigating through the Event Viewer.

3. Using PowerShell:
- Press Windows + X and select Terminal (Admin) or open PowerShell as an administrator.
- Run the following command to list system errors:
Get-EventLog -LogName System -EntryType Error | Out-GridView
- This command lists recent system errors from which you can filter and analyze the crashes.

4. Crash log analysis with WinDbg
- Windows creates minidump files whenever it crashes. These files contain a snapshot of the memory at the time of the crash and are located at C:\Windows\Minidump. InsertA full memory dump may also be available at C:\Windows\MEMORY.DMP.
- If basic crash log analysis doesn’t provide enough insight, use WinDbg, a debugging tool from Microsoft, for a more detailed examination.
- Download and install the Windows Debugging Tools (part of the Windows SDK) from Microsoft’s website.

- Open WinDbg and configure the symbol path, which allows WinDbg to map memory addresses to function names and variables for better crash data interpretation, by entering the following command in the console:
.sympath SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
- This command tells WinDbg to use Microsoft’s symbol server for crash analysis.
- In WinDbg, go to File > Open Crash Dump and select the Minidump file. Type !analyze -v in the command window to run a detailed analysis of the crash dump.
- WinDbg will display information about the crash, including the BugCheck code and the faulty driver or component that caused the crash.


As an alternative to WinDbg, you can also inspect the dump files (in C:\Windows\Minidump or C:\Windows\MEMORY.DMP) with third-party utilities such as BlueScreenView, which present the same crash data in a simpler interface.
- Event ID 41 (Kernel-Power): Indicates an unexpected system shutdown, often due to power supply issues or hardware failure.
- Event ID 6008: Indicates that the system shut down unexpectedly, which could be due to power failure or forceful shutdowns.
- Windows critical reports: Highlights critical events, including crashes, based on severity and trends.
- Windows system events: Monitors system crashes related to startup, shutdown, updates, and software installations.
- Application crashes: Tracks failures like BSOD, application hangs, and system errors.
Analyzing crash logs
Crash logs may not directly point to software installations or updates as the cause of crashes. While logs indicate issues, investigating recent installations or updates is necessary to identify potential conflicts, even if not explicitly mentioned in the logs.
Steps to take and their impact
Updating drivers: After crash logs indicate hardware issues like faulty drivers, updating drivers for components like graphics cards, network adapters, and storage controllers should be your first step. Not updating drivers may result in recurring crashes and hardware failures.
Running diagnostic tools: If hardware issues are suspected but not clearly indicated by the logs, running diagnostic tools like MemTest86 for RAM and SMART diagnostics for hard drives helps to confirm or rule out hardware malfunctions. Skipping this may cause persistent crashes if faulty hardware is involved.
Considering software installations or updates: If no clear hardware fault is found, review recent software installations or updates. Even though crash logs might not always pinpoint problematic software directly, issues can still arise from them, and rolling back could resolve conflicts. Ignoring this step might leave underlying software issues unaddressed.
Running sfc /scannow: If system file corruption is suspected based on event logs or unexplained crashes, this command should be run to repair those files. Skipping this step could leave system-level issues unresolved, resulting in ongoing instability.
Performing a clean boot: Perform this if crash logs suggest conflicting background services or applications but do not identify the exact cause. A clean boot will help isolate the problematic services or applications. If this step is skipped, identifying the root cause may become more challenging, prolonging the instability.
Common Windows crash events
Once the crash logs are located, event IDs and error messages need to be interpreted to understand the cause. Here are some common event IDs associated with crashes:
For each event, Windows logs additional data that includes error codes or driver details, helping to determine if the issue is hardware-related, software-related, or due to external factors.
How EventLog Analyzer facilitates Windows crash log analysis
While manually checking the Event Viewer and dumps can be a starting point for troubleshooting Windows crashes, these methods may be less efficient due to the lack of centralized search capabilities and a user-friendly interface. Alternatively, ManageEngine EventLog Analyzer, comprehensive log management and IT compliance software, centrally collects and analyzes event logs from all Windows servers and workstations in your network, ensuring that crash events are captured effectively from multiple sources.
After analyzing the logs, EventLog Analyzer provides you with instant reports on Windows device and application crashes. These detailed reports indicate when and why the application crashed, identify any errors, and determine why critical device crashes like BSOD occurred. EventLog Analyzer's real-time alerting console allows you to get notified about critical application or server crashes, and it also comes with an intuitive search console that allows you to easily search through centralized Windows event logs to effectively conduct root cause analysis.
EventLog Analyzer also offers an out-of-the-box widget to track and analyze top crash events across your network, letting you drill down into raw logs for detailed troubleshooting, and it supports proactive monitoring by identifying patterns in crashes to help prevent future incidents. Specific Windows device reports that track crash logs include:











