This is an archived page. It's not actively maintained.

如果用户遇到崩溃,系统将提示他们提交由崩溃面板生成的原始崩溃报告。原始崩溃报告由 Socorro 接收,由它来 创建 处理过的崩溃报告。处理过的崩溃报告基于原始崩溃报告,但有包括签名,分类和许多改进的字段(例如操作系统,产品,版本)等信息。原始崩溃报告和处理过的崩溃报告中的许多字段在 崩溃统计信息 中是可以查看和搜索的。尽管有两个不同的崩溃报告,原始的和处理过的,但人们通常谈论单一的“崩溃报告”,因为崩溃统计数据大多是以组合的方式呈现。


请注意,大多数崩溃报告字段是可见的,但其中几个对隐私敏感的部分仅适用于已登录且具有“minidump 访问权限”的用户。相对较少的用户具有 minidump 访问权限,并且他们需要遵守特定的规则。 如果你需要访问,可以提出一个像这样的 申请





详细信息选项卡的第一部分显示包含最重要的崩溃报告字段的表格。 它包括诸如崩溃是何时发生的,哪种产品和版本信息,崩溃类型,以及关于崩溃发生的机器的操作系统和配置的各种细节。 以下屏幕截图显示了这些字段中的一些。
Example fields in the "Details" tab of a crash report

所有字段都有一个工具提示。对于许多领域,工具提示描述其含义。对于所有字段,工具提示指示当您要进行涉及此字段的搜索时要使用的键。(字段名通常但不总是可以用于搜索关键词,例如字段“适配器设备 ID”具有搜索键“adapter_device_id”。)这些描述显示在 SuperSearchFields API 中,并且可以由 崩溃统计信息的超级用户修改



  • Abort: 控制中止,例如通过 NS_RUNTIMEABORT(通过 MOZ_CRASH 或 MOZ_RELEASE_ASSERT 发生的受控中止不会获取中止注释,但它们会获得“MOZ_CRASH 原因”的字段。)
  • OOM | <size>, where <size> is one of large, small, unknown: 内存不足(OOM)中止。 <size>注释由“OOM 分配大小”字段确定;如果该字段缺少<size>则将是未知的。
  • hang: 关闭之前发生了挂起。
  • shutdownhang: 关闭过程中发生了挂起。
  • IPCError-browser: 一个涉及 IPC 的问题。如果 Firefox 的父进程检测到子进程已经发送了已损坏或不可处理的 IPDL 数据,或者未及时关闭,则会使用崩溃报告杀死子进程。这些崩溃现在将有一个签名,指示进程被杀死的原因,而不是当前的子堆栈。

When no special-purpose annotation is present and the signature begins with a stack frame, it's usually a vanilla uncontrolled crash. The crash cause can be determined from the "Crash Reason" field. Most commonly it's a bad memory access. In that case, on Windows you can tell from the reason field if the crash occurred while reading, writing or executing memory (e.g. EXCEPTION_VIOLATION_ACCESS_READ indicates a bad memory read). On Mac and Linux the reason will be SIGSEGV or SIGBUS and you cannot tell from this field what kind of memory access it was.

See this file for a detailed explanation of the crash report signature generation procedure, and for information on how modify this procedure.

There are no fields that uniquely identify the user that a crash report came from, but if you want to know if multiple crashes come from a single user the "Install Time" field is a good choice. Use it in conjunction with other fields that don't change, such as those describing the OS or graphics card, for additional confidence.

For bad memory accesses, the "Crash Address" field can give additional indications what went wrong.

  • 0x0 is probably a null pointer deference[*].
  • Small addresses like 0x8 can indicate an object access (e.g. this->mFoo) via a null this pointer.
  • Addresses like 0xfffffffffd8 might be stack accesses, depending on the platform[*].
  • Addresses like 0x80cdefd3 might be heap accesses, depending on the platform.
  • Addresses may be poisoned: 0xe4 indicates the address comes from memory that has been allocated by jemalloc but not yet initialized; 0xe5 indicates the address comes from memory freed by jemalloc. The JS engine also has multiple poison values defined in js/src/jsutil.h.

[*] Note that due to the way addressing works on x86-64, if the crash address is 0x0 for a Linux/OS X crash report, or 0xffffffffffffffff for a Windows crash report, it's highly likely that the value is incorrect. (There is a bug report open for this problem.) You can sanity-check these crashes by looking at the raw dump or minidump in the Raw Dump tab (see below).

Some fields, such as "URL" and "Email Address", are privacy-sensitive and are only visible to users with minidump access.

The Windows-only "Total Virtual Memory" field indicates if the Firefox build and OS are 32-bit or 64-bit.

  • A value of 2 GiB indicates 32-bit Firefox on 32-bit Windows.
  • A value of 3 or 4 GiB indicates 32-bit Firefox on 64-bit Windows (a.k.a. "WoW64"). Such a user could switch to 64-bit Firefox.
  • A value much larger than 4 GiB (e.g. 128 TiB) indicates 64-bit Firefox. (The "Build Architecture" field should be "amd64" in this case.)

Some crash reports have a field "ContainsMemoryReport", which indicates that the crash report contains a memory report. This memory report will have been made some time before the crash, at a time when available memory was low. The memory report can be obtained in the Raw Dump tab (see below).


The second part of the Details tab shows bug-related information, as the following screenshot shows.

Information relating to bug reports in the "Details" tab of a crash report

The "Report this bug in" links can be used to easily file bug reports. Each one links to a Bugzilla bug report creation page that has various fields pre-filled, such as the crash signature.

The "Related Bugs" section shows related bug reports, as determined by the crash signature.

Stack traces

The third part of the Details tab shows the stack trace and thread number of the crashing thread, as the following screenshot shows.

Information relating to threads in the "Details" tab of a crash report

Each stack frame has a link to the source code, when possible. If a crash is new, the regressing changeset can often be identified by looking for recent changes in the blame annotations for one or more of the top stack frames. Blame annotations are also good for identifying who might know about the code in question.

Sometimes the highlighted source code is puzzling, e.g. the identified line may not touch memory even though the crash is memory-related. This can be caused by compiler optimizations. It's often better to look at the disassembly (e.g. in a minidump) to understand exactly what code is being executed.

Stack frame entries take on a variety of forms.

  • The simplest are functions names, such as NS_InitXPCOM2.
  • Name/address pairs such as nss3.dll@0x1eb720 are within system libraries.
  • Names such as F1398665248_____________________________ ('F' followed by many numbers then many underscores) are in Flash.
  • Addresses such as @0xe1a850ac may indicate an address that wasn't part of any legitimate code. If an address such as this occurs in the first stack frame, the crash may be exploitable.

Stack traces for other threads can be viewed by clicking on the small "Show other threads" link.

If the crash report is for a hang, the crashing thread will be the "watchdog" thread, which exists purely to detect hangs; its top stack frame will be something like mozilla::`anonymous namespace'::RunWatchdog. In that case you should look at the other threads' stack traces to determine the problem; many of them will be waiting on some kind of response, as shown by a top stack frame containing a function like NtWaitForSingleObject or ZwWaitForMultipleObjects.


The Metadata tab is similar to the first part of the Details tab, containing a table with various fields. These are the fields from the raw crash report, ordered alphabetically by field name, but with privacy-sensitive fields shown only to users with minidump access. There is some overlap with the fields shown in the Details tab.


The modules tab shows all the system libraries loaded at the time of the crash, as the following screenshot shows.

Table of modules in the "Modules" tab of a crash report

On Windows these are mostly DLLs, on Mac they are mostly .dylib files, and on Linux they are mostly .so files.

This information is most useful for Windows crashes, because DLLs loaded by antivirus software or malware often cause Firefox to crash. Correlations between loaded modules and crash signatures can be seen in the "Correlations" tab (see below).

This page says that files lacking version/debug identifier/debug filename are likely to be malware.


The first part of the Raw Dump tab shows the raw crash report, in JSON format. Once again, privacy-sensitive fields are shown only to users with minidump access.

JSON data in the "Raw Dump" tab of a crash report

For users with minidump access, the second part of the Raw Dump tab has some links, as the following screenshot shows.

Links to downloadable files in the "Raw Dump" tab of a crash report

These links are to the following items.

  1. A minidump. Minidumps can be extremely useful in understanding a crash report; see this page for an explanation how to use them.
  2. The aforementioned JSON raw crash report.
  3. The memory report contained within the crash report. Only crash reports with the ContainsMemoryReport field set will have this link.
  4. The unredacted crash report, which has additional information.


The Extensions tab shows which extensions are installed and enabled.

Table of extensions in the "Extensions" tab of a crash report

Usually it just shows an ID rather than the proper extension name.

Note that several extensions ship by default with Firefox and so will be present in almost all crash reports. (The exact set of default extensions depends on the release channel.) The least obvious of these has an Id of {972ce4c6-7e08-4474-a285-3208198ce6fd}, which is the default Firefox theme. Some (but not all) of the other extensions shipped by default have the following Ids: webcompat@mozilla.org, e10srollout@mozilla.org, firefox@getpocket.com, flyweb@mozilla.org, loop@mozilla.org.

If an extension only has a hexadecimal identifier, a Google search of that identifier is usually enough to identify the extension's name.

This information is useful because some crashes are caused by extensions. Correlations between extensions and crash signatures can be seen in the "Correlations" tab (see below).


This tab is only shown when crash-stats identifies correlations between a crash and modules or extensions that are present, which happens occasionally.

See also