FAQ

Article
03/16/2009

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.

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.

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

Or, you can type error into the Search bar on the Start Menu and click the “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.

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.

Comments

Anonymous
May 11, 2009
blefler@idgweb.com 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.
Anonymous
June 11, 2009
Bill, I do have a video published on the web that provides a walk through of our site: http://channel9.msdn.com/pdc2008/PC60-V/ 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
Anonymous
July 09, 2009
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.
Anonymous
January 25, 2010
The comment has been removed

Share via

FAQ

Windows XP/ Server 2003

Windows Vista / Server 2008

Windows 7

Comments

Additional resources