How do I get started with Windows Error Reporting (WER)?

How do I find Windows Error Reporting information on a PC?

How do we match up crash data (Windows Error Reporting signatures) with companies?

What files should I map?

How do we detect applications hangs in Windows?

What is a bucket?

What is a “special” exception?

What are the different types of memory dumps?

When will I see data?

Q: How do I get started with Windows Error Reporting (WER)?

A: As an Independent Software Vendor (ISV) who develops software applications for the Windows Operating Systems, you are able to register to receive Software Quality information from the Windows Quality website.

Please follow this link to a page with directions on how to get started! (http://www.microsoft.com/whdc/maintain/StartWER.mspx).

Q: How Do I find Windows Error Reporting information on a PC?

A:  Here are the solutions for finding WER data on XP, Vista, and Windows 7.

OS WER Information
Windows XP Event Log
Windows Server 2003 Event Log
Windows Vista Event Log
Windows Server 2008 Event Log
Windows 7 Event Log
Action Center


Windows XP/ Server 2003

On XP / Server 2003 you can find information about error reports in the Application Log.
When a crash occurs the bucketing parameters are written to the Application Event log with the event source of “Application Error” and event ID 1000
When the crash is submitted the bucket ID is written to the Application Log with the same event source and has an event ID 1001.

Windows Vista / Server 2008

On Vista you can use the “wercon” control panel accessible via:
Start >Control Panel >System and Maintenance >Problem Reports and Solutions >View Problem History
By typing “wercon” in the Search Box at the base of the Start Menu.


Click on the “View problem history” link


Double click on on a line item below the Application Name to view details:


Notice the bucketID and the Copy to Clipboard feature.

Windows 7

Using the Action Center: 

Open the Action Center by clicking on the flag icon in the system tray


Select the Action Icon from the system tray, and click Open Action Center.

By expanding the Maintenance toggle button, the customer can see the View System History link.image

After selecting the View System History link, the customer can click the View problem reports and responses link.

View Problem Response and Reports/Reliability Panel

Or, you can type error into the Search bar on the Start Menu and click the “View problem History”

StartMenu "View Problem History"

Select View Problem History, and then select View problem reports and responses.

Q: How do we match up crash data?

A: Here is the general mapping logic we used based on crash data that is gathered by Windows Error Reporting (WER) client.  Notice the difference between Pre Windows Vista, and Post Windows Vista.

How do we match up crash signatures with Files that are mapped?

We use 4-6 basic parameters to match mapped files in the developer portal, Windows XP has fewer and matches on File Name and File Version for either Applications and Modules. With this in mind if you are still developing for Windows XP it is a best practice to come up with a unique file name and file version. This best practice translates to any other development environment, but is important with Windows XP as you can see the parameters below that the Windows XP WER Client sends to our service.

Windows XP (Includes Windows Server 2003)

WER client sends these parameters we use to match crashes:

  • Application Name
  • Application Version


  • Module Name
  • Module Version

With Windows XP/Windows Server 2003 crashes we have less data to use for matching crash signatures with files mapped on the portal.

Windows Vista++ (includes Windows Server 2008)

WER client sends these parameters we use to match crashes:

  • Application Name
  • Application Version
  • Application File Link Date


  • Module Name
  • Module Version
  • Module File Link Date

We use the link date to get a more accurate match on the files mapped on the portal.

Q: What files should I map

A: Given the way we have implemented mapping logic the best policy is to map only the files where you own or maintain the source code.  If you ship 3rd party or open source modules with your software where you do not own or maintain source then you will not be able to take action on these error reports, and this information will just be added noise and complexity.

Even if you don’t map 3rd party modules you will still see crash reports where any module crashed your application.

NOTE: We have mapping collision detection that will preclude you from mapping certain files.


Product Name: FabrikamReportingApplication

Product Binary files:

File Name File Version Description Should I map?
FabrikamReportGUI.exe User interface for my reporting product Yes
FabrikamWebserviceDataImport.dll Library used to import and transform data from web services. Yes
ThirdPartyChartControl.dll 3rd party DLL I’ve licensed to ship with my report product No
OpenSourceDataVisualizer.exe An open source application that helps with visualizing multiple data sources (I don’t maintain code for this) No
OpenSourceGridControl.dll An open source library where I’ve incorporated the source code into my build and maintain changes and updates for this source. Yes

With the mapping scenario above you will still see crashes where ThirdPartyChartControl.dll caused a crash in the FabrikamReportGUI.exe application.

Q: What is a bucket?

A: A bucket uses a set of parameters gathered by the WER client to describe a WER Event.  For crash events the bucketing parameters are Application Name, Application Version, Application Build Date, Module Name, Module Version, Module Build Date, Exception Code, and Code Offset.

There are also Generic Buckets that are made up of up to 10 parameters.

Q: What is “special” exception?

A: A special exception is a grouping of two WER event types: Buffer Overruns (BEX) where the exception code = C0000409, and Data Execution Prevention (DEP) where the exception code = C0000005.  These two event types are related to security of software and can also be viewed in the Security Alerts section of the website.  In order for the WER client to capture BEX events you need to use the /GS command when compiling your software.

Q: What are the different types of memory dumps?

A: Below is a table that contains brief descriptions of the different types of dump files that can appear in .CAB file.

Extension Description
.mdmp minidump (Default dump collection type, stacks, and loaded modules)
.hdmp .mdmp += heap data
.kdmp on-demand kernel mode minidump (snapshot of the kernel mode portion of a given user mode process) only sent if WCT (Wait Chain Traversal) added it, or was explicitly requested for a given ibucket by a user.
memory.dmp Old style (<=XPSP2) heap dump.  This is not actually a debugging dump file, instead its just a blob of read only pages
atk.dmp application termination kernel (taken when an exited process takes more than 10 seconds to actually terminate)
hu.dmp heap user
mu.dmp mini user
odk.dmp on demand kernel
axhu.dmp arbitrary x-process heap user
axmu.dmp arbitrary x-process mini user
wxhu.dmp wct x-process heap user (wct is wait chain traversal)
wxmu.dmp wct x-process mini user


Q: When will I see data?

A:  After mapping files we will start to pull any existing data we have for crashes. Generally you will see Hit data within a day or so. Users who setup Vista and Windows 7 with recommended settings (~80%) will automatically send us the hit data without any prompting, so you can see hits without cabs.

By default we collect 10 cab (minidump) files per event*, since a user still has to click on the “send additional information” button for us to get the crash dump it can take some time to get cab files.

Once we receive cab files for an event you will generally be able to see these cabs within a few hours of us receiving them.

NOTE:  For newly detected crashes it can take more than 4 days to get the crashes processed and up on the site.  Commonly if you create an app to test our system you will see a longer latency in getting WER data.  Since WER is collecting unhandled exceptions on Windows all the time, we recommend mapping existing released software.

*We do not set collection rules for files that are un-versioned, and automatic collection rules depend on the time you map your files.  If you are mapping old files, all the buckets have been created and we will not automatically collect files for old buckets.  For newly created buckets we will set the collection rules for the most common file extensions.

Comments (4)

  1. Bill Lefler says:


    Your team is pushing people to adopt WER. It would be really helpful if you would make things clear to developers. All of the sample code in the WinQual help and on MSDN is in C++. How about some C# examples?

    Besides the sample code. The explanations are unclear and vague. Having the WinQual site dump you into a help file if you don’t have a certificate installed is a really bad way to encourage people to use the site. How about showing off the powers of the site by letting people log into a example account to see what the benefits of WER might be.

    Trying to decide to adopt WER is a very difficult decision currently due to lack of info.

  2. Bill,

    I do have a video published on the web that provides a walk through of our site:


    There is no special thing in general you need to do to use WER as the WER client is collecting unhandled exception information about applications crashing on Windows since XP.  The only thing that is needed to get started is an Organizational VeriSign certificate, and to map your binaries.

    From your comments we might need to highlight this a bit more, and having a sample login would be helpful to see it.  Let me know if there is anything I can do now to provide more information.

    We do have a codeplex project for interfacing with our services that contains C# code.  http://wer.codeplex.com

  3. Michael Viking says:

    Oh, and before I stumbled onto this page, I had mapped a third party DLL since we use it.  Now we have a bunch of events for applications I’ve never heard of in our event list.  How can I delete them?  I did try to delete the third part DLL from my mapping list but it still shows up albeit in grayed out text.

    Thanks in advance.

  4. Peter Schneider says:

    I also have some problems using the winqual web site:

    The "Product Rollup" page keeps on showing many entries for old products which I have deleted successfully from our Product Mappings. After deleting those mappings they were grayed out for a few days but they finally disappeared. But all those old products still appear in the rollup and make it very noisy.

    Is this expected?

    Can I access the rollup of a specific product version somehow (search doesn’t seem to work for products)?

    Another issue is: It seems we also get reports for crashes in one of our applications even if the Module has not been included in our Product Mapping (e.g. for system DLLs or DLLs from third party tools like virus checkers). So why is it recommended to map all of our binaries at all? What is the difference or benefit?

Skip to main content