What leaves your network when you send us a crash dump
The dump itself reaches our worker in the EU and, if a case needs one, an engineer. No AI model sees it. In the automated analysis, a model only reads the debugger's text output, after we redact it. Redaction is pattern-based and best-effort, which is why the model never gets the dump.
A crash dump is a copy of memory. It can hold file paths, user names, machine names and, in a full memory dump, whatever was in memory at the time. If you are an MSP sending a customer's dump or a vendor sending a user's, you are right to ask where it goes. This post follows one dump, in order. The authoritative version, which we update before anything changes, is how DumpTriage uses AI.
1. The upload
You send the file in the browser or through the REST API. Dumps are stored in the EU and debugged in the EU, and the AI calls go to Google's EU endpoint, so the dump, the debugger and the automated AI analysis all stay in the EU, for every account by default. Setting the EU data region makes that a requirement for yours. Dumps and transcripts are deleted after 30 days by default (configurable up to 90 days).
2. The debugger
On Windows a debugger (WinDbg or cdb) runs on a worker VM created for your job and deleted afterwards, on Google Cloud in the Netherlands. On Linux it is gdb or crash. There is no AI at this step. The raw dump and any private symbols you uploaded are on the worker only for the job, and both are deleted from the worker when the job ends; if that fails, they are deleted before the worker's next job starts. A macOS crash report has no debugger: our own code reads it on our servers.
3. Redaction
Before debugger output reaches the model in the automated analysis, we remove what looks like a secret: passwords, API keys, tokens and Bearer credentials, AWS access keys, database connection strings and long opaque strings. We also remove email addresses, the user-name part of Windows C:\Users\ and Linux /home/ paths, and the machine name that Linux kernel dumps report. Machine names elsewhere in the output, such as a Windows computer name, can still reach the model.
Redaction is pattern-based and best-effort, not a guarantee: a secret in a shape we don't recognise can get through. That's why the model never gets the dump itself, and why you can keep the most sensitive systems out of scope or send minidumps rather than full memory dumps.
4. The model reads the text
The model gets the redacted debugger output, facts we parsed from it (such as the stop code and faulting module), and up to five summaries of similar resolved cases from customers who allow sharing. The calls go to Google's EU endpoint through Vertex AI. We don't use your dumps, transcripts or reports to train or fine-tune any AI model. Google's terms for Vertex AI say Google won't use them to train or fine-tune its models without our permission, and we haven't given it. Since 2026-10-26 caching is switched off for our Vertex AI project, so Google keeps no copy of a request to answer later ones.
One thing we can't switch off: Google still checks every request with automated abuse classifiers. If one flags a request, Google may log the prompt for up to 90 days, in the same EU region, so that its staff can check it against Google's usage policies; it isn't used for training. Only customers with a Google Cloud Master Agreement are exempt from that logging. We use Google Cloud under its standard online terms, so we can't switch it off.
5. When a person looks
The model writes a structured report, and our own rules, not the model alone, decide whether it goes straight to you. A dump from a Windows pre-release build (an Insider flight, beta or RC) is not analysed: it has no public symbols, so it comes straight back flagged as pre-release. Except on the Solo plan, which has no engineer review, a crashing driver we can't identify goes to an engineer. So do heap corruption and memory-corruption exceptions, except in two cases: on Windows, when the deeper pass names the module that caused the corruption; and for a Linux application core, when the report names a tool that finds the earlier bad write: for heap corruption, one such as AddressSanitizer or Valgrind; for a stack overrun, an address sanitizer, since Valgrind does not see one. In those two cases the corruption alone doesn't send the report to an engineer.
On every plan except Solo, which has no engineer review, a case that goes to an engineer is worked with the dump itself. The engineer may use Anthropic's Claude, in the United States, as an assistant. It reads the debugger and forensic tool output they work with, which isn't always redacted first and can include the names of processes, drivers and files, and user and folder names. It doesn't receive the raw dump file. If you need a non-disclosure agreement first, ask us and we'll sign one.
6. Other customers
When an engineer resolves an escalated case, they can save a short summary of it: the crash code, the faulting module, a root-cause category and a note. Summaries of your cases only help with other customers' analyses if you turn sharing on; it is off by default. A summary never holds your dump or your transcripts.
What we are not built for
DumpTriage isn't built for protected health information, and we don't sign HIPAA Business Associate Agreements. Read the Privacy Policy before you send dumps from systems that handle patient data.
Try it on a real dump
Upload a Windows or Linux crash dump and get the faulting module, the stack and a plain-language root cause back (how the analysis works).
Create an account