Sunday 20 March 2016

Configure Windows Error Reporting

In Windows XP Microsoft introduced several changes in the exception management system.
The old Dr. Watson was archived in favour of the brand-new Windows Error Reporting system.
What was originally only a local debugger evolved in a more complex end-user reporting system.
The WER system evolved in the subsequent Windows version - significatively in Windows Vista, but from a developer point of view, even in Windows 10, it remained essentially the same as it was in Windows XP.

Main purpose of WER is to catch all the unhandled exceptions and create a report and, if enabled, a memory dump of the faulty process.

Part of WER is the debug dialog that sometimes appear on the desktop whenever a faulty application crashes.






WER also creates two new entries in the Application Event Log:





In the details of the events you can find the full path of the error report and, if enabled, the full path of the memory dump.

Enable Memory Dumps

The first step to identify the root cause of an unhandled exception is to analyse a memory dump. A memory dump is a file that contains a snapshot of the process memory at the time the exception was thrown.
The default Windows configuration is to create mini-memory dumps only for system faults (BSOD) and not for user-mode applications.
To enable user-mode memory dumps for the entire system, change the following System Registry values. You can find an exaustive documentation in this page on MSDN.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps

Value Name      - Data Type     - Default Value

DumpFolder      - REG_EXPAND_SZ - %LOCALAPPDATA%\CrashDumps
DumpCount       - REG_DWORD     - 10
DumpType        - REG_DWORD     - 1
CustomDumpFlags - REG_DWORD

DumpType can be set to the following values:
  • 0: Custom dump
  • 1: Mini dump
  • 2: Full dump
Custom dump allows you to choose what section of the dump generate. You can configure the sections using the CustomDumpFlags value.
I would not recommend in the first to generate a full dump because it could become very large depending on how much RAM is available on your system.

You can also activate the dump only for an application.
Add a new key under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps (for example, HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApplication.exe).
Then add the above mentioned dump settings under the MyApplication.exe key.

The consent dialog

In general, whenever your application throws an unhandled exception a dialog will be shown to the user.
There is an exception (no pun intended :) ) to this rule: if the exception is generated when your application does not have a visible window, the crash will be only logged in the Application Log and no dialog will be displayed to the user.This behaviour is to avoid confusion in the case of a crash in a background application not commonly known to the average user.

Unfortunately, this means that if your application has no window, hardly you will receive a call from your user in case of a crash.

This was exactly the case of an application I was worked on. This application, an MFC application normally displaying a dialog, had a fault in the shutdown process after the main window was destroyed.
The issue was discovered only because in one system, the fault happened before the destroy of the main window making WER display the consent dialog.
We lately discover the Application Log was full of crash events from this application.

To actually debug the issue, I needed first to force WER to display the consent dialog in the exact moment of the crash so that I could attach the debugger.

Force WER to display the consent dialog

Indeed, there is a not-so-well-documented way to force WER to display the consent dialog for a specific application.
Create a new DebugApplications key under
HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting
Under this new key, create a REG_DWORD value with the name of your application including the extension.
Set then the new value to 1.


 

Conclusions

Whenever you are testing an application, I would recommend to keep looking at the Application Log in the case of a silent crash of the application.
In that case, to actively debug the issue, force WER to show always the consent dialog so that you can attach your debugger at the right moment.





No comments:

Post a Comment