FAQ

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! (https://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 ”wercon”
Windows Server 2008 Event Log ”wercon”
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
Or
By typing “wercon” in the Search Box at the base of the Start Menu.

clip_image002

Click on the “View problem history” link

clip_image002[9]

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

clip_image002[11]

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

clip_image001[5]

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

OR

  • 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

OR

  • 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.

Example:

Product Name: FabrikamReportingApplication

Product Binary files:

File Name File Version Description Should I map?
FabrikamReportGUI.exe 1.0.0.0 User interface for my reporting product Yes
FabrikamWebserviceDataImport.dll 1.0.0.1 Library used to import and transform data from web services. Yes
ThirdPartyChartControl.dll 5.6.1.3 3rd party DLL I’ve licensed to ship with my report product No
OpenSourceDataVisualizer.exe 4.5.3.1 An open source application that helps with visualizing multiple data sources (I don’t maintain code for this) No
OpenSourceGridControl.dll 2.3.1.4 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.