When an application’s GUI stops responding, users may get frustrated and decide to close the application. As previously discussed, Windows Error Reporting (WER) steps in at that point to collect information about why the hang happened before terminating the process.
The data collected by WER is used by application developers to diagnose the hang. The data collection process is divided up into two stages:
- Stage One – Quickly identify the hang. Basic information is used to classify the hang, as discussed in a previous blog post. Developers can use this data to determine which hangs to fix. Alternatively, if a fix has already been created for the hang, WER may direct the user on how to install a fix for the hang.
- Stage Two – Retrieve in-depth data about the state of the system at the time of the hang. This is only requested on-demand from the developer, and only a small portion of users who experience the hang will be requested to send additional data.
The data collected during Stage Two comes from a variety of sources within the system and differs among operating systems. The data being sent by WER in Windows 7 is as follows:
Tip: WER has a setting to enable explicit consent, allowing you to review this data
Report.wer – Summarizes all data included in the WER report.
*.exe.xml – metadata describing the hang itself. It details each thread that was involved in the hang, starting with the thread that owned the HWND that was not responding. It includes description of other threads that contributed to the hang, which may traverse into multiple processes.memory.hdmp – Heap dump for the process with one or more hung windows. Private symbols are required in order to make any sense of the data here, which is typically only available to the developer that created the process.
- WERInternalMetadata.xml – metadata describing the system (processor, OS build number, parent process, etc).
AppCompat.txt – Compatibility settings, if any such settings were applied to the process before startup.
Version.xml – Version data for binaries active within the process.
*.tmp.ref / *.dbgcfg.ini / *.wxhu.dmp – Heap dump for another process within the system that contributed to the hang. Although separated into three files, recent versions of windbg will recognize the *.ini file as a single dump file open all three at once.
ElevatedDataCollectionStatus.txt – WER diagnosis file detailing failures that happened while trying to collect data (i.e., lack of sufficient permission granted).
*.odk.dmp – Kernel minidump used for diagnosing hangs that involve GDI state held in the kernel.
*.atk.kdmp – Kernel minidump collected when an application has failed to terminate via TerminateProcess() or similar. Typically, these hangs are the result of an unresponsive driver.
*.wmi – Data requested by the developer as WMI queries.
Not every hang report contains each file described above. In fact, WER attempts to minimize the amount of data sent and only sends additional data if it is requested.
The most interesting parts of the hang report, as far as diagnosing the hang goes, are the dumps and the *.exe.xml file. Viewing that XML file can provide insight into which threads contributed to the hang, while the dump file can be used to inspect the state of each thread.
WER is aware of privilege differences between processes and the user sending the hang report. It launches with the same token as the process whose UI was hung. If it needs to collect data from a higher privileged process, it will request administrator consent before doing so. Users should read the WER privacy policies for more information about how it deals with protecting their data.