How to Read a Windows Crash Log in Event Viewer (October 2026)

Windows does write crash logs, in two separate places: text entries inside Event Viewer and memory dump files on your disk. To read a Windows crash log, you press Win+R, type eventvwr, then open the System log for blue screens or the Application log for a program that keeps quitting. From there you read the faulting module and event ID, which usually names the exact driver or app to fix. The whole first pass takes about two minutes.

That distinction matters more than people expect. Most of the top results for this question are forum threads where users paste raw dumps and ask strangers to decode them, and the two polished guides that rank are written for programmers and IT admins rather than for the person whose laptop just restarted itself. Below is the process end to end, including the part nobody else covers: what to do once you know what broke.

Everything here applies to Windows 11 and Windows 10. Labels drift a little between releases, so a menu might read View or Actions depending on the build, but nothing here depends on a specific update.

What You Need

You need three things, and only one of them is a purchase decision.

• Administrator access. Event Viewer itself opens as a standard user, but the Minidump folder and the System log will not open without it. Right-click the Start button, choose Terminal (Admin) or Command Prompt (Admin), and accept the prompt.
• A timestamp. Even an approximate one. The whole log set runs to tens of thousands of entries, and knowing the crash was around 9:40pm turns an hour of scrolling into ten seconds.
• The built-in tools. Event Viewer and Reliability Monitor ship with Windows. Optional extras, both free, are NirSoft’s BlueScreenView for reading blue screen dumps and Microsoft’s WinDbg for when BlueScreenView is not enough.

One setting decides whether a dump file gets written at all, so check it before you go hunting. Search for sysdm.cpl, open the Advanced tab, go to Startup and Recovery, then Settings. The Startup write type should be Small memory dump (256 KB) or Automatic memory dump, and the dump directory should point at the system drive. Leave it alone if those are already set, because a bad change here is how people end up with no evidence at all.

You do not need to change anything to read Event Viewer entries. The dump settings only matter if you plan to analyse a .dmp file later.

Step-by-Step: How to Read a Windows Crash Log

Step 1: Note the Symptom and When the Crash Happened

Write down four things before you open anything: roughly when it happened, what you were doing, what you saw, and whether the machine restarted on its own.

A blue screen with a stop code is the easiest case, because the crash wrote a proper record. A hard freeze that you held the power button on is the hardest, since Windows may only have time to log the fact that it came back up. An app that closed with a has stopped working dialog is the middle case, and it produces its own dump file in a different folder.

That distinction saves time later, because a forced power-off often means no dump exists and you are working from Event Viewer entries alone.

Step 2: Open Windows Event Viewer

Press Win+R, type eventvwr.msc and hit Enter. That is the fastest route and it works on every modern Windows release. The longer paths are the same place: Start, search for Event Viewer, or Control Panel, Administrative Tools, Event Viewer.

On Windows 11 the console opens narrow and the tree may show only a handful of folders. Click View in the menu bar and choose Show more options, or press Alt+V, to expand the full list. You are looking for Windows Logs, which contains System, Application, Security, Setup and Forwarded Events.

Text entries are not the only crash records on the machine. Dump files live on disk, and these are the paths worth typing into File Explorer:

Path	What it holds	What it tells you
C:WindowsMinidump	One small .dmp per blue screen, named like 071026-14328-01.dmp	The actual crash state, small enough to upload
C:WindowsMEMORY.DMP	The full memory dump from the most recent blue screen	Everything, but several gigabytes
%LOCALAPPDATA%CrashDumps	Dumps for individual apps that quit unexpectedly	Which module inside that app failed
%PROGRAMDATA%MicrosoftWindowsWER	Windows Error Reporting reports, stored in ReportQueue and ReportArchive	Full text crash reports per incident
C:WindowsLiveKernelReports	Reports from live kernel events, such as a display driver hang	GPU, storage and chipset faults that never blue-screened

Paste the first four into the address bar of File Explorer and they expand on their own. This is the answer to where Windows keeps crash logs that most guides skip.

Step 3: Find the Event That Matches the Crash

Pick the log that matches the kind of crash, then narrow it down. Opening the wrong log is the most common wasted minute in this whole process.

Crash type	Log to open	What to look for
Blue screen or unexpected restart	Windows Logs, System	Event ID 1001 from Windows Error Reporting, plus 41 from Kernel-Power
App closed with an error	Windows Logs, Application	Event ID 1000 from Application Error, or 1001 from Windows Error Reporting
Display or GPU fault	Windows Logs, System	Event ID 4101 from Display, and WHEA-Logger entries
Unauthorised access or sign-in problem	Windows Logs, Security	Failed logons and audit events
Failed or rolled-back update	Windows Logs, System and Setup	Windows Update entries

With the right log selected, click Filter Current Log in the right-hand pane. Tick Critical and Error, set the date range to the day of the crash, and press OK. If you know the event ID already, type it into the search box on the main pane instead.

These are the event IDs that carry real diagnostic weight on this topic:

Event ID	Source	Plain-English meaning
41	Kernel-Power	The system rebooted without a clean shutdown. A symptom, not a cause.
1001	Windows Error Reporting	A bug check occurred. The entry lists the stop code and its four parameters.
1000	Application Error	An application crashed. Names the faulting application and faulting module.
1002	Application Hang	An application stopped responding and was closed.
6008	EventLog	The previous shutdown was unexpected, with the date and time logged.
161	volmgr	Windows could not create the dump file. Common after a disk fills up.
7	Disk	A bad block was found on the drive.
51	Ntfs or volmgr	Paging or file system I/O errors, frequently a failing drive.
55	Ntfs	File system structure damage on the volume.
4101	Display	The display driver stopped responding and Windows reset the GPU.
17, 18	WHEA-Logger	A hardware error was recorded by the machine’s error reporting hardware.

Event 41 is the one that causes the most wasted evenings. It does not say why the machine went down, only that it came back up without a clean shutdown. When you see 41, immediately search forward a few seconds for the 1001 entry that carries the real reason.

Step 4: Read the General and Details Tabs

Click the event, then read the General tab in the lower pane. On an Application Error entry you will find fields that decode like this:

• Faulting application name the program that died, for example chrome.exe.
• Faulting module name the library inside it that threw the error. A Windows system DLL here is often a victim, not the cause.
• Exception code the machine-level reason. 0xc0000005 is an access violation, meaning something tried to read or write memory it did not own, and it makes up the large majority of app crashes.
• Exception offset a hex address inside the module. Useful when you hand the report to support.
• Bucket ID a hash Windows groups similar crashes under. Two crashes with the same bucket are the same problem.

On a 1001 entry from Windows Error Reporting you get the stop code instead, followed by four parameters. Those four values identify the faulting address, the object involved and sometimes the process or driver, and Microsoft publishes what each one means per stop code.

Stop codes worth recognising on sight: MEMORY_MANAGEMENT and PAGE_FAULT_IN_NONPAGED_AREA point at memory, CRITICAL_PROCESS_DIED means an essential Windows process died, and WHEA_UNCORRECTABLE_ERROR means hardware reported an error the machine could not recover from.

The Details tab shows the same data as XML. Use it to copy exact values when you are writing a support request, and treat it as read-only: never edit or delete an event, because you lose the one piece of evidence you cannot recreate.

Step 5: Identify Whether the Failure Is Software or Hardware

One entry is rarely enough. The pattern across several events tells you more than any single line.

Repeated 1000 entries naming the same application point at that app, its update, or an add-on it loads. Repeated 1001 entries naming the same driver file point at that driver. WHEA-Logger 17 and 18 entries, a Disk event 7, or an Ntfs 51 or 55 lean toward hardware, especially if they appear without any app crash nearby. Event 4101 during games usually means a graphics driver or a GPU running out of memory.

A caution worth repeating: automated analysis often blames a Windows DLL such as ntdll.dll, because that is the file that finally noticed the failure. The real culprit is frequently a third-party driver loaded earlier. Experienced users on the TenForums BSOD board call this out constantly, and they are right.

Step 6: Match the Module or Driver to a Remedy

Now turn the name into a fix. A driver file ends in .sys, and you can find which device it belongs to without leaving Windows: press Win+X, choose Device Manager, then use View, Show hidden devices and look for anything greyed out. Alternatively, read the module’s description on the Drivers tab of the event, which names the device and its vendor.

From there, work down this order:

1. Roll back or reinstall the driver. Device Manager, right-click the device, Properties, Driver tab, then Roll Back Driver. If there is no rollback, download the driver from the machine or component maker’s own support page rather than a driver aggregator site.
2. Clean up a graphics driver. For a driver named after a graphics utility, run that utility’s clean install option before anything else.
3. Check system files. Run sfc /scannow from an admin terminal, then DISM /Online /Cleanup-Image /RestoreHealth. This repairs Windows components, not drivers.
4. Test the memory. Run Windows Memory Diagnostic from the Start menu search, and use MemTest86 for longer passes when you suspect RAM.
5. Check the disk. Run chkdsk /scan. If you are already seeing Disk event 7 or Ntfs 51, back up your data before anything else.
6. Scan for malware. A full scan with Defender or your antivirus of choice, since some malware deliberately crashes system processes.
7. Run Driver Verifier last. Microsoft notes that roughly three quarters of stop errors trace back to faulty drivers, and Verifier is the tool that surfaces them. It also checks drivers far more strictly than normal use, so it can produce a boot loop that needs Safe Mode to undo. Do not run it on a machine you rely on for work unless you have tested your Safe Mode route.

For app crashes, check %LOCALAPPDATA%CrashDumps for a .dmp with the app’s name. NirSoft’s AppCrashView opens that file and shows the same fields as the General tab in a cleaner layout, which is why forum regulars reach for it first.

Step 7: Confirm the Fix and Save the Findings

Repeat whatever triggered the crash, then come back and look for new entries. A fix that works produces nothing. A fix that merely delayed the problem produces a new event later, which is worth knowing before you declare victory.

Reliability Monitor is the fastest confirmation, and the fastest first stop for anyone who finds Event Viewer heavy. Press Win+R, type perfmon /rel and Enter. It shows a timeline with red circles containing an X, one per failure. Click a date to see everything that failed that day, in plain language. Microsoft support staff routinely ask for a Reliability Monitor screenshot.

To keep the evidence, right-click a log in Event Viewer and choose Save All Events As, then save as .evtx for a full-fidelity copy or .csv for a spreadsheet. To share a blue screen report, zip the contents of C:WindowsMinidump. To open a support case properly, include the stop code, its four parameters, the faulting module, and the exact steps that reproduce the crash.

A support request that says it blue-screened, with the code and the four parameters, gets a real answer. One that says it keeps crashing gets a checklist reply.

Reading a Blue Screen Dump When Event Viewer Is Not Enough

When a 1001 entry exists but names no clear culprit, the .dmp file holds the detail. Take it in two stages.

First, BlueScreenView. Download it from NirSoft, run it as administrator, and it finds the .dmp files in C:WindowsMinidump automatically. Pick one and read two lines: the bug check line, which gives the stop code and parameters, and the Probably caused by line, which gives a driver file. Map that .sys back to a device in Device Manager and you usually have your answer in a minute.

Treat that line as a strong hint rather than proof. The analysis is automated, so when it names a Windows system driver, check whether a third-party driver appears in the same report.

Second, WinDbg. It is Microsoft’s official debugger and it is where you go for a proper stack trace. Install it from the Microsoft Store, open the .dmp file, and in the command window run !analyze -v. You get the stop code, the faulting instruction, the process or driver involved, and often a Microsoft support link for that specific stop code.

WinDbg is a developer tool and the output is dense, so most people should stop after BlueScreenView. Forum posters who want a second opinion are usually asked to zip the Minidump folder instead.

Common Mistakes

The reading goes wrong in a few predictable ways, and each has a straightforward fix.

Treating every event as the cause. The System log fills with thousands of warnings a day, and the crash is one line among them. Filter to Critical and Error around your timestamp rather than reading top to bottom.

Chasing Event 41. Kernel-Power 41 only reports that the machine restarted unexpectedly. The reason sits in the 1001 entry a few seconds later.

Looking in the wrong log. Application crashes live in the Application log, not System. Blue screen records live in System. Opening the wrong one is why so many people report that Event Viewer shows nothing useful.

Searching the wrong date or time. Event Viewer timestamps are local time, so a laptop that crossed a time zone or an automatic clock correction can put events days away from when you remember the crash. Widen the date range in the filter rather than assuming nothing happened.

Confusing warnings with the crash. A yellow triangle a few minutes before a restart is often the failed update or the disk warning that led to it. Read the entries just before the restart, not only the restart entry.

Clearing logs too early. Right-click, Clear Log looks tidy and destroys the record. Never clear a log until the problem is fixed or you have exported it.

Believing a DLL name proves a DLL is guilty. Windows system DLLs appear on most crash reports because they are where the failure surfaced. The driver loaded earlier is a more common real cause.

And when the log looks empty, this is usually why:

Cause	How to confirm	Fix
Page file moved off the system drive or disabled	System Properties, Advanced, Performance, Settings, Advanced, Virtual memory	Set it to system managed on C:
The drive is nearly full	Look for volmgr event 161	Free up space and reproduce the crash
Cleaner apps deleted the dumps	CrashDumps folder is empty but Event Viewer has entries	Exclude those folders from the cleaner and change the retention setting
The crash was too sudden to dump	A forced power-off, or a hard freeze	Rely on Event Viewer, and enable automatic memory dumps
Managed or work account	Access denied opening the System log	Ask IT, or export from a machine you control

A few quick habits before you go looking: photograph the blue screen with a phone, even a blurry photo of the stop code is worth having, and note the time right when it happens.

Frequently Asked Questions

Conclusion

Start with one action: open Event Viewer, filter the System log to Critical and Error around the crash time, and read the faulting module on the 1001 or 1000 entry. If you still need a refresher, that is really all there is to how to read a Windows crash log: narrow to the moment, then decode the one field that names the culprit. Then change one thing at a time, driver rollback first, and confirm with Reliability Monitor before you call it fixed.

If the machine boot-loops, keeps overheating, keeps restarting without a stop code, or the log points at memory or disk, back up your files and get it looked at properly. A crash log tells you what failed; past that point you want hardware tested rather than guessed at.