QuickDbg

A terminal-based Windows kernel crash dump analyzer. Point it at a folder full of .dmp files and it runs WinDbg non-interactively, extracts everything useful, and prints a structured report severity, bugcheck, call stack, registers, faulting module, memory regions, third-party drivers, event log correlation, and more.

---

Requirements

• Python 3.8+
• WinDbg installed via the Microsoft Store (installs cdbX64.exe to your AppData). Or the Windows SDK version either works.
• The script finds cdbX64.exe automatically. If it can't, it tells you where to get it.
• Internet access on first run is helpful so WinDbg can download symbols from Microsoft's public server. Symbols are cached locally after that.

---

Basic usage

Drop your .dmp files in a folder and run:

python dump_report.py C:\path\to\dumps

If you run it from the same folder as the dumps, you can omit the path:

python dump_report.py

The script walks the folder recursively, picks up every .dmp file (including Minidump\ subfolders), runs WinDbg on each one, and prints the full report to the terminal.

---

What you see

For each dump:

• Severity label — CRITICAL-HW (hardware/RAM), CRITICAL, HIGH-KERNEL, HIGH-DRIVER, or MEDIUM, shown in color
• Identification — filename, dump type, timestamp, OS build, CPU count, uptime at crash
• Bugcheck — hex code, symbolic name (e.g. MEMORY_MANAGEMENT), and the four Arg parameters with WinDbg's own descriptions
• Attribution — faulting process, thread, module, image, failure bucket, failure hash, memory corruptor tag
• Memory regions — each key address (Arg1, read address, write address, etc.) mapped to a named VA region (Non-paged pool, PTE space, Direct mapped physical memory, etc.)
• Call stack — the crash-time stack, color-coded by depth
• Registers — all GP registers + RIP, RSP, EFL, CR3 at the moment of the crash
• Third-party modules — any loaded driver or module that isn't from a standard Windows path, flagged with [!]
• Symbol issues — warnings about missing or deferred symbols that could affect analysis quality

At the top of the report you get a summary across all dumps. Bugcheck code breakdown, faulting processes, hardware-blamed count, a day-by-day crash timeline, and a dedup section that groups crashes sharing the same failure hash.

---

Options

Flag	What it does
--sym PATH	Override the WinDbg symbol path. Default: Microsoft public symbol server with local cache at C:\Symbols.
--timeout N	How many seconds to give WinDbg per dump before giving up. Default: 180. Increase for very large dumps on slow machines.
--json FILE	Write all parsed results to a JSON file alongside the terminal output. Useful for scripting or diffing results over time.
--deep	Run a second WinDbg pass per dump. This fires !whea for hardware errors, !pool for pool corruption, and ~*kb for full thread stacks on complete/bitmap dumps. Slower but surfaces more detail.
--parallel	Analyze all dumps at the same time instead of one by one. Much faster on machines with spare cores, but interleaves the progress output.
--watch	Keep running and watch the folder for new .dmp files. When one appears, analyze it immediately and print the result. Hit Ctrl+C to stop. Useful on a live machine or a collection share.
--no-color	Plain text output — no ANSI color codes. Use this if you're piping to a file or a tool that doesn't handle color.
--no-events	Skip querying the Windows System Event Log. By default the script pulls the 5 minutes of events before each crash and shows them alongside the dump. Use this flag if you don't have permission to read the event log, or just want faster output.

---

Examples

Analyze dumps in the current folder:

python dump_report.py

Analyze a specific folder with deep mode and export to JSON:

python dump_report.py C:\Users\Me\crashes --deep --json results.json

Run in parallel on a large batch, no colors, skip event log:

python dump_report.py D:\dump-archive --parallel --no-events --no-color

Watch a live machine's minidump folder:

python dump_report.py C:\Windows\Minidump --watch --deep

Use a local symbol store instead of downloading:

python dump_report.py . --sym "C:\Symbols"

---

Severity levels

Label	Meaning
CRITICAL-HW	Hardware blamed — RAM, CPU, or firmware. Bugcheck bucket says MEMORY_CORRUPTION or module is hardware.
CRITICAL	Process termination crashes (0xEF, 0xF4) or other critical-flagged buckets.
HIGH-KERNEL	Fault in nt / ntkrnlmp — Windows kernel code.
HIGH-DRIVER	Fault attributed to a .sys driver or a driver-tagged bucket.
MEDIUM	Everything else.

---

Symbols and the first run

The first time you analyze a dump, WinDbg downloads symbols for each module from https://msdl.microsoft.com/download/symbols and caches them at C:\Symbols. This can take a minute or two per dump depending on how many modules were loaded. Subsequent runs are fast.

If you're on an air-gapped machine, point --sym at a local symbol store you've pre-populated, or accept that some stack frames will show as <unknown>.