Crash Data Analysis

この記事はまだボランティアによって 日本語 に翻訳されていません。ぜひ MDN に参加して翻訳を手伝ってください!

The Mozilla crash reporting system is a treasure trove of data. Mozilla uses this data to measure overall product stability, prioritize and diagnose specific crash issues, and verify fixes that have been made.

Crash Report Contents

A typical crash report consists of a minidump file and a collection of metadata fields.

Minidump Files

A minidump contains at least the following information:

  • Details about the exception which led to the crash
  • Information about each thread in the process: the address which was executing and the register state at the time the process stopped.
  • A list of shared libraries loaded into the process at the time of the crash
  • The stack memory of each thread.
  • The memory right around the crashing address.

A minidump may also contain other memory regions if requested by the application, or other platform-specific data.


Along with the minidump, the crash reporting system includes metadata fields. Firefox code and extensions can add arbitrary fields at runtime, as well as append to a "notes" field. Here are some of the basics:

ProductName collects crashes for Firefox (Desktop), Firefox for Android, Firefox OS, Thunderbird, SeaMonkey, and a few others. This is a required field.
The version number of build  that was running when the crash occurred.
The build ID of the build that was running when the crash occurred.
"Mozilla" in every case, even for partner builds of Firefox.
The time when the crash occurred, as returned by the time() C function.
The time when Firefox started. By comparing the startup time and the crash time, we can see how long Firefox was alive before it crashed.
The time when this particular version of Firefox was installed by the user.
The update channel that the user is on. Typically "nightly", "aurora", "beta", or "release", but this may also be other values like "release-cck-partner".
The currently enabled theme.
A list of the addons currently enabled at the time of the crash. This takes the form of "addonid:version,[addonid:version...]". This value could be empty if the crash happens during startup before the addon manager is enabled, and on products/platforms which don't support addons.
The application "ID". This is a string like "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}" for Firefox which addons use to match compatibility.
Freetext notes added by application and extension code to the crash report.
When present, indicates the PCI vendor and device ID of the graphics hardware.
On Windows, a string of data from the Windows OS about the list of installed LSPs (Layered Service Provider).
Information about the address and size of the "frame poisoning region" used to mitigate errors in the layout code. See roc's blog for details on frame poisoning.
The website which the user most recently visited in the browser before the crash. Users have the option of opting in or out of sending the current URL. This information may not always be valuable, because pages in other tabs or windows may be responsible for a particular crash. This value is considered personally-identifying information (PII) and is only available to Mozilla employees.
On the Firefox release channel, we typically process only 10% of crashes. If Throttleable=0, then this report is being submitted from the about:crashes UI and should always be processed.
Statistics about memory information (Windows-only?).
When the main Firefox process crashes, this will not be present. But when a plugin or content process crashes, this will be "plugin" or "content".
When a plugin process crashes, details about the plugin loaded into that process.
Users may opt in to providing their email address so that Mozilla may contact them about their crash report.
When Firefox intentionally aborts because an allocation fails, this annotation will indicate the size of the attempted allocation.

Crash Report Processing

After a crash is submitted, the Socorro system gives it a unique ID and stores it for processing. It uses the breakpad crash processor to translate the minidump into a stack trace for the crash. Then it attempts to build a "signature" for the crash based on the functions near the top of the stack. For more information about the signature generation, see this very old wiki page.

Reports and Queries

The most common way to access crash report data is via the website This websites has built-in reports of "topcrashes" for each release grouped by signature. There is also a custom query tool which allows users to limit searches on more precise information.

For more automated usage, a summary of each day's crash reports is published as a CSV file, as well as batch analysis jobs. These can be found at

Finally, a set of Mozilla employees have access to directly query the underlying data in either SQL summary or using mapreduce on the storage cluster. If you are interested in obtaining this advanced access, contact Benjamin Smedberg.


 このページの貢献者: monperrus, BenjaminSmedberg
 最終更新者: monperrus,