Error Reporting Dump Files (Compact 2013)

3/26/2014

Crash dump files are compressed and sent through an HTTPS (secure HTTP) connection directly from the device to Microsoft. The receiving server uses a concept called bucketing to organize dump data.

The server groups the minidumps into categories called buckets. A bucket is a group of minidump files that arose from similar crashes, that is, crashes with the same code defect.

A combination of variables defines a bucket:

• Application name, version, and timestamp
• Owner application name, version, and timestamp
• Module name, version, and timestamp
• Offset into the module

Therefore, when two users encounter an application crash using the same version of a program at the same offset, the server buckets the crash dumps into the same category. The design hypothesizes that those two users hit the same bug.

Software support personnel can judge the severity and priority of an issue by the number of crashes that occur, which is the hit count of a particular bucket.

Because a handful of bugs cause most crashes, developers can prioritize which crashes to examine first.

The developers review the issues presented to the upload site and debug the problem that caused the crash in the uploaded file.

In addition to being able to judge the severity of a bucket using its hit count, bucketing enables the support software to provide feedback tailored to a particular crash.

The Error Reporting dump format uses Relative Virtual Addresses (RVA) to describe the location of a data member within a file. An RVA is an offset from the beginning of a file.

Because a minidump for a target device must be readable on another device, all structures in the dump file are the same size, regardless of the architecture of the faulting device.

The dump file format specifies a set of directories that point to the data.

Each directory specifies the following:

• Data type
• Data size
• RVA to the location of the data in the dump file

Each file permits only one directory of a specific type.

The basic dump file format is a single MINIDUMP_HEADER followed by n MINIDUMP_DIRECTORY entries followed by n data entries.

The MINIDUMP_HEADER specifies how many MINIDUMP_DIRECTORY entries follow. Each MINIDUMP_DIRECTORY entry points to data in the dump data section.

Error Reporting creates dump files in a reserved area in RAM. After the dump file image is created in RAM, it is written to persistent storage. The size of the reserved area of RAM limits the size of the dump file. The size of the reserved area in RAM can be changed in an OEMInit function by updating g_pOemGlobal->cbErrReportSize. For more information, see cbErrReportSize.

Complete dumps are available only when the kernel debugger is connected and in a break state. Complete dumps are captured by the kernel debugger. Complete dumps are not limited by the RAM reserved for dump files.

The following table shows how Error Reporting can generate three distinct types of crash dumps.

Type of dump file	Size	Description
Context dumps	4 KB - 64 KB.	Information about the crashing system Exception that initiated the crash Context record of the faulting thread Module list, limited to the faulting threads of the owner process Thread list, limited to the faulting threads of the owner process Callstack of the faulting thread 64 bytes of memory above and below the instruction pointer of the faulting thread Stack memory dump of the faulting thread, truncated to fit a 64 KB limit
System dumps	64 KB - several MB	All information in a Context dump Callstacks and context records for all threads Complete module, process, and thread lists for the entire device 2048 bytes of memory above and below the instruction pointer of the faulting thread. Global variables for the process that was current at the time of the crash
Complete dumps	All physical memory plus at least 64 KB	All information in a system dump A complete dump of all used memory

See Also

Other Resources

Error Reporting