Introducing DumpTriage: from crash dump to root cause

A machine blue-screens at a customer site, or an application crashes or hangs, and you're left with a crash dump or report. That file usually holds the answer: which driver or module, which code path, which bug check. Reading it takes WinDbg, the right symbols and an hour from someone who knows the commands. Most MSP service desks, software teams and developers whose own machine or application crashed don't have that hour for every crash. DumpTriage is for them: upload the dump, get a root-cause report back.

Published 2026-10-26 by PerformanceInsights.ai

What you send, what you get back

You send a Windows crash dump (a minidump, or a kernel or full memory dump) a Linux process core dump or kdump vmcore, or a macOS crash report, kernel panic or spindump hang report, in the browser or through the REST API. We work out which kind it is from the file header, so you don't have to know. You get back a report with the bugcheck code, the faulting module, the stack and a plain-language summary of the cause.

Linux is in early access: an engineer reviews every Linux report before it's delivered. A macOS report isn't a memory dump: macOS writes it itself, already symbolicated, so there's no debugger to run and we read the report on our own servers instead.

Three tiers, and the rules decide when a human looks

• Tier 1, an automated read. A fixed set of debugger commands (WinDbg, CDB or KD on Windows, gdb or crash on Linux) runs against the dump, or a fixed set of reads against a macOS report, and a model reads the output. Only a case our rules call clear-cut goes back without a human.
• Tier 2, a deeper pass. Ambiguous cases get a second, longer pass with a wider command set, checked for agreement with the first pass.
• Tier 3, an engineer. Cases neither pass can settle go to an engineer. Heap corruption, memory-corruption exceptions and a crashing driver we can't identify always do.

We would rather hand a dump to an engineer than send back a confident wrong answer. So far in the pilot, most cases have gone to an engineer; we'll publish the automated share once we've measured it. The full description is on how DumpTriage works.

What happens to the dump

• No AI model sees the raw dump. The debugger runs on our own worker, and secrets are redacted from its output before a model reads it. A macOS report gets the same redaction on our servers. Redaction is pattern-based and best-effort, which is why the model never gets the dump itself.
• We don't train models on customer data.
• Dumps are stored and debugged in the EU, and the AI calls go to Google's EU endpoint. The subprocessors page lists every third party and its location.
• Dumps and transcripts are deleted after 30 days by default (configurable up to 90 days). Hostnames are stored only as a keyed hash.
• Every command run against your dump is logged: what was asked, never the output.

The details, step by step, are on how DumpTriage uses AI.

Who it's for

For an MSP, the dump comes from a customer's machine and the answer goes back to the customer. For a software vendor, it comes from a user's crash and the answer goes to a developer. For a developer or admin, it's their own machine or application that crashed or hung. All of them need the same thing: the cause, quickly, without sending the dump to a model. Anyone can sign up; the smallest plan is one dump a month, free during the pilot.

• An API for your own tooling. Send dumps from your crash pipeline, upload private symbols, and get a webhook when a report is ready. See the API reference.
• Open-source capture. dumptriage-tools (MIT) turns on crash dump capture on Windows and Linux, and its agents send new dumps by policy: always, ask first, or by rule. On a Mac, a collection script lists the last week's crash, panic and hang reports and asks before sending any. Download them.

Where we are

DumpTriage is in a pilot and free while it lasts. If you'd rather read the dump yourself, our crash dump analysis guides cover WinDbg, gdb and common Windows stop codes such as 0x133.

On this blog we'll write up real crashes (with the owner's permission): what the automated passes found and what the engineer added. We'll also cover how the pipeline decides. Follow along with the RSS feed, or write to hello@performanceinsights.ai.