Can I analyze a crash dump myself for free?

Yes. WinDbg and the Microsoft symbol server are free, and gdb and crash are free on Linux. The cost is your time and the debugger skills: finding the dump, setting up symbols and reading the output of !analyze -v or a gdb backtrace.

When should I hand a crash dump to someone else?

When the dump is too large to move around, when the same crash comes up on many machines, when the stack points into a driver or memory corruption you cannot trace, or when the person with the customer's machine is not the person who can read a debugger.

What should I check before sending a dump to an analysis service?

What the dump can contain, who reads it, where it is stored and for how long, and whether the service trains models on it. A kernel or full memory dump can hold far more than a minidump, so send the smallest dump that still shows the crash.

Decision guide

Analyze a crash dump yourself or hand it off?

When to read a crash dump yourself in WinDbg or gdb, and when to hand it to someone else: what you need, what it takes, and what a hand-off involves.

Published 2026-10-27 by PerformanceInsights.ai

Short answer: Analyze it yourself when you have WinDbg and symbols on a machine, an hour to spare and a common stop code or a plain application crash. Hand it off when the dump is large, the crash is in a driver or in memory you can't trace, or you have a queue of them. Handing it off means someone else gets the dump, so check what the dump holds and who reads it first.

Analyze it yourself when

You have WinDbg (or gdb and crash on Linux) and can load Microsoft's symbols, or the module's own symbols, on the machine you are using.
The stop code is a common one with a documented procedure, such as 0x3B, 0x50, 0x9F, 0xD1 or 0x133, or the dump is from one application that crashed.
The dump is small enough to open where you are, and nothing in it may leave your network.
You have the time to read the output. The first dump takes the longest: finding the file, setting up symbols and learning what !analyze -v is telling you.

Start with how to analyze a Windows minidump or Linux core dumps with gdb and crash. Both are free to follow.

Hand it off when

The dump belongs to a customer, and you are the one who has to explain the cause rather than the one who knows how to read a debugger.
The same crash shows up on many machines, so reading dumps one at a time stops being worth it.
The stack points into a driver you cannot identify, or at memory corruption, where the faulting module is often only the victim of an earlier write.
The dump is a large kernel or full memory dump that is hard to copy to a machine with a debugger on it.

What each route costs you

Route	What you need	What you give up
Read it yourself	A debugger, symbols, the dump and the skill to read the output.	Your time, and the dump never leaves your hands.
Hand it to a colleague or a consultant	Someone who reads dumps, and a way to get the file to them.	The dump goes to another person, so agree what it may contain and when it is deleted.
Upload it to an analysis service	An account and the dump, or the API for many.	The dump is stored and read on someone else's servers. Check where, for how long, and whether it trains models.

What handing a dump to DumpTriage means

You upload a Windows crash dump or a Linux core dump (or send it with the API, or let the agents from Downloads send new dumps). DumpTriage runs the debugger, reads the output and sends back the faulting module, the stack and a plain-language root cause; anything the automated passes can't settle goes to an engineer. How the analysis works has the three tiers.

What happens to the dump, in the words of our AI and data page:

No AI model sees your dump. The debugger runs on our own worker. A model only reads the debugger's text output, after we redact it.
We don't train or fine-tune any model on your dumps, transcripts or reports, and our AI provider's terms say it won't either.

Redaction is pattern-based and best-effort, not a guarantee: a secret in a shape we don't recognise can get through. That is why, for the most sensitive systems, the AI and data page suggests keeping them out of scope or sending minidumps rather than full memory dumps. Retention and locations are on that page and on the subprocessors list.

Common questions

Can I analyze a crash dump myself for free?: Yes. WinDbg and the Microsoft symbol server are free, and gdb and crash are free on Linux. The cost is your time and the debugger skills: finding the dump, setting up symbols and reading the output of !analyze -v or a gdb backtrace.
When should I hand a crash dump to someone else?: When the dump is too large to move around, when the same crash comes up on many machines, when the stack points into a driver or memory corruption you cannot trace, or when the person with the customer's machine is not the person who can read a debugger.
What should I check before sending a dump to an analysis service?: What the dump can contain, who reads it, where it is stored and for how long, and whether the service trains models on it. A kernel or full memory dump can hold far more than a minidump, so send the smallest dump that still shows the crash.

Rather not read the dump yourself?

Upload it to DumpTriage. It runs the debugger, reads the output and sends back the faulting module, the stack and a plain-language root cause (how the analysis works). Cases the automated passes can't settle go to an engineer. Free during the pilot.

Create an account