Why did my PC crash? How to find the cause of a blue screen from the minidump (.dmp) file

What Windows keeps after a blue screen

Microsoft calls a blue screen a stop error or bug check. Windows can save what was in memory to a dump file, and it records the crash in its event log. These are the places to look:

• Small memory dumps (minidumps): one file per crash, with the date in the file name, in %SystemRoot%\Minidump (C:\Windows\Minidump when Windows is on drive C). Microsoft's memory dump file options page says each holds the stop code and its parameters, the list of loaded drivers and the call stack of the thread that stopped.
• Kernel, complete and automatic memory dumps: one larger file, %SystemRoot%\MEMORY.DMP, which a later crash can overwrite.
• The System event log: event 1001 (WER-SystemErrorReporting) says the computer rebooted from a bug check and gives the stop code, its four parameters and where the dump was saved. Event 41 (Kernel-Power) is logged after any restart without a clean shutdown.
• Reliability Monitor: start it with perfmon /rel, or from Control Panel, Security and Maintenance, Maintenance, View reliability history. It charts failures and warnings over the past days and weeks.

None of these explains the crash in plain words. Microsoft's stop error troubleshooting article puts the causes at about 70% third-party driver code, 10% hardware, 5% Microsoft code and 15% unknown, because memory was too corrupted to analyse. A small dump only holds the thread that was running, so a problem caused elsewhere may not show up in it.

Option 1: Event Viewer and Reliability Monitor (built in)

1. Open Event Viewer, go to the System log and filter it on event IDs 41 and 1001.
2. In event 1001, note the stop code (for example 0x0000009f) and the path of the dump file.
3. In event 41 the BugcheckCode is in decimal. Convert it with Calculator in Programmer mode: type the number with Dec selected, then select Hex. A code of 0 means no stop code was written, which Microsoft links to power loss, a hard hang or the power button being held down.
4. Look the code up in Microsoft's bug check code reference.

This costs nothing. You learn when the crashes happened and which stop code they had, but the event does not name a driver, and the bug check pages are written for programmers. Microsoft's home-user page on unexpected restarts and stop code errors lists first steps that need no dump, such as removing recently added hardware and installing Windows updates.

Option 2: WinDbg and !analyze -v (free, from Microsoft)

WinDbg is Microsoft's own debugger. It is free and reads small dumps as well as the large MEMORY.DMP.

1. Install WinDbg from the Microsoft Store or with winget install Microsoft.WinDbg, as described on Microsoft's Install WinDbg page.
2. Start WinDbg and open the .dmp file as a crash dump from the File menu.
3. Check that the symbol path points to Microsoft's public symbol server, https://msdl.microsoft.com/download/symbols, which Microsoft recommends when the PC is online.
4. Type !analyze -v in the command box and press Enter.
5. Read the bug check name at the top, then the MODULE_NAME and IMAGE_NAME lines. Microsoft's page on the !analyze extension says they name the module where the error probably happened.

This is the most detailed route, but it is a developer tool: Microsoft's troubleshooting article warns that dump analysis can be very challenging without programming experience. The output is long, and the module it names is not always the thing to change. In one of Microsoft's own examples it was a Windows network driver, and the fix was to disable the network device.

Option 3: Crashwright ($5.99)

Crashwright reads the same crash dumps and event log entries (events 1001 and 41) on your PC and explains them in plain words: what happened, the driver most likely involved and what you can try. Every answer comes with a confidence level (high, medium, low or not known) and the reasons behind it. When nothing in a dump points to one driver, Crashwright says so instead of guessing, and an unknown stop code or driver is shown as unknown.

• How it decides: it checks which driver the stop code's addresses and the running code point into, leaves Windows' own files out of the blame where another maker's driver is involved, and says what the driver belongs to, such as graphics, Wi-Fi or antivirus. Its knowledge base explains over 150 stop codes and recognises over 500 driver files.
• Check this PC: reads the crash history from the event log and shows a 90-day timeline with patterns, such as the same driver in 4 of the last 5 crashes, crashes that all look different (often memory or hardware), or restarts without a blue screen. This has not yet been verified with real crash data.
• Admin-only dump folder: on many PCs only administrators can open the dump folder. Crashwright tells you so and can copy the dumps to your Documents folder after one Windows permission prompt.
• What to try: each crash gets a checklist, starting with the step that fits the evidence, and your ticks are remembered. You can compare crashes side by side, save a report as PDF, web page or text, or copy a short technical summary for support staff. Program crash dumps of apps and games are explained too.
• Explains only: it never changes your PC, your drivers or your settings. It works offline, has no account and sends nothing.

1. Install Crashwright from the Microsoft Store. It needs Windows 10 version 2004 or later, or Windows 11, on a 64-bit PC.
2. Choose Check this PC, or open a .dmp file from File Explorer, by drag and drop or with Ctrl+O. To see how it works first, use Try a sample.
3. Read the explanation and the confidence level, then work down the checklist.

Crashwright costs $5.99 in the Microsoft Store. Get it from Microsoft Store.

What to expect from Crashwright

• Tested on real dumps: 13 real small memory dumps that users attached publicly to bug reports, from Windows 8.1, 10 and 11, with stop codes 0x116, 0x3B, 0x9F, 0xEF and 0x50. All were read, matching an independent read of the header. In the four cases where the bug report named the driver at fault, Crashwright named the same driver with high confidence. 10 real program crash dumps matched the event log.
• Not verified on real data: 32-bit kernel dumps, Windows 7 and older, ARM64 dumps, other stop codes, and unloaded drivers as evidence. Large kernel and complete memory dumps are read for the header only (stop code and time) and were tested only with files we made. The elevated copy, PDF export and Check this PC have not been verified on real data inside the app.
• Hardware-reported codes: for codes the hardware reports, such as 0x124 and 0x101, Crashwright limits how sure it is about any driver. Microsoft says bug check 0x124 is typically caused by physical hardware, such as heat, memory or a failing processor.
• Some dumps cannot be read in full: Windows saves dumps in a format that can change, and a dump Crashwright cannot fully read is shown as such.
• Its own knowledge base: the explanations of stop codes and drivers are written by Karelia Labs, not taken from Microsoft.
• PDF reports need the Microsoft Edge WebView2 Runtime, which is included in Windows 11 and most Windows 10 PCs.
• No promise of a diagnosis: Crashwright explains and does not repair. A low or not-known answer means the dump does not point clearly to one driver.

The Windows facts are from the Microsoft pages linked above and those on event ID 41, unexpected reboots in the system event log and the perfmon command, and the WinDbg listing in the Microsoft Store, checked on 15 November 2026. Crashwright's results are from its tests on 13 real small memory dumps and 10 real program crash dumps that users attached publicly to bug reports; large memory dumps were tested only with files we made.