How WER Collects and Classifies Error Reports
On This Page
Windows Error Reporting (WER): Classifications
The Microsoft Windows Error Reporting (WER) service captures both kernel-mode (operating system) and user-mode (application) crashes, including information on drivers and applications, as well as about the modules (controls and plug-ins) running at the time of the crash.
When an end user chooses to send an error report to Microsoft over the Internet, the WER service collects technical information about the crash. This data is used for quality control purposes only and is not used for tracking individual users or installations for any marketing purpose. If information is available that will help the end user solve the problem, Windows displays a message to the user with a link to that information.
WER classifies error reports for the same problem into one bucket. When a customer sends an error report, WER determines if a bucket for that problem already exists. If it does, then the report is added to the existing bucket. If not, then a new bucket is created.
The types of data collected and the schemas for defining a bucket are different for user-mode crashes and for kernel-mode crashes.
Classifying Kernel-Mode Crashes
Kernel-mode crashes are first grouped by stop codes and then by additional parameters, depending on the individual stop code. The bucket name is based on the type of error and the device. For example:
|OLD_IMAGE_SAMPLE.SYS_DEV_3577||Crash caused by an old version of sample.sys on device ID 3577|
|0x44_BUGCHECKING_DRIVER_ SAMPLE||Driver sample.sys may have caused Bugcheck 0x44|
|POOL_CORRUPTION_ SAMPLE||Driver sample.sys may have caused pool corruption|
|0xBE_sample!bar+1a||Driver sample.sys crashed in routine bar|
An error report for a kernel-mode crash consists of a minidump file generated at the time of the crash and an XML file generated when the computer restarts and is about to send the error report.
When Windows stops responding, it reverts to a low-level troubleshooting mode. In this mode, a dump file is captured that contains low-level operating system data structures that identify what was happening in the computer at the time of the crash. These data structures include the functions being executed by the processor at the time of the crash, the CPU register state, and stack, thread, and process information. This data can be viewed in a debugger and used to identify the faulting component.
The dump file also contains the list of all drivers loaded in the computer at the time of the crash. This data is used by the debugger to determine which driver images and symbols need to be loaded to debug the crash. The list of modules also helps determine whether known bad or outdated drivers are running on the computer.
Starting with Windows XP Service Pack 1 (SP1), the dump files have been enhanced to allow a driver to store information in the crash dump file that can be used for troubleshooting. The routine for collecting crash data from a driver is KeRegisterBugCheckCallback.
Classifying User-Mode Crashes
User-mode crashes are classified according to the following parameters:
Application name — for example, winword.exe
Application version — for example, 10.0.2627.0
Module name — for example, mso.dll
Module version — for example, 10.0.2613.1
Offset into module — for example, 00003cbb
The .cab files for user-mode crashes include such information plus a minidump file. The minidump file for user-mode crashes contains the state of the process at the time the crash occurred—specifically, the registers and stack for every thread in the application. This information is used to identify which application component caused the crash. The minidump also includes a list of all modules loaded in the application at the time of the crash, so you can get information about each module loaded in the process and to get symbols for each of these modules.