Microsoft has created their own error reporting system that’s built into Windows XP and Vista. These operating systems will automatically collect crash data for any application that crashes and upload it to their servers. There the data is collected, sorted, and distributed to the companies creating the offending software. I’ve been using the system with my software for quite some time now, so I figured I’m collect my thoughts on the system for people thinking about using it.
From your software’s point of view, there’s nothing you really need to do to get it working. When your software crashes, Windows will automatically catch the error, as long as you’re not catching it yourself. It’s helpful though if you properly version your binaries (EXE and all DLLs). This makes reading the logs later on easier.
In order to see your software crash logs, you need to have a code signing certificate. This is required to create your companies account with winqual, and this costs some money. I’d prefer if we were able to use the system without needing this requirement.
Once logged in, you’ll notice that the winqual system does more than just error reporting, but that will be outside the scope of this article.
In order to view reports, you’ll need to inform the system about your product. Winqual has a small downloadable application that will inspect your binaries and create a file mapping XML file for your product. Once you upload the XML file to winqual, the system will start collecting data for your product.
The system allows you to see a couple of different reports: all crashes by version and hottest crashes by version. These are the most common ones you’ll use. It’s nice that it breaks the reports down by product and version. You’re able to see a list of crashes, sorted by occurrences and counted. You can see a date break-down for each crash of when the crash occurred. For many of the crashes, you’re then able to download the crash data for debugging.
What’s missing though is the ability to search for crashes by date. Given a date, you cannot see what crashes occurred. This would be useful if you knew that a crash occurred on a certain day, then it would be easier to track down.
As it is now, the system is great for fixing your most common crashes. However, the system is not good for finding and fixing particular crashes. There’s no way to link a crash to a customer. Microsoft says this is intentional. However, in the end, as a support tool, it fails.
Also, it often takes a week to a week-and-a-half to get updated with crash data. So you’ll be waiting a while for a particular crash to appear.
On the good side, when you do look at a particular crash and download the crash data, you’re able to easily load the data in Visual Studio 2008 and see the crash as if it occurred locally. Nice touch. The initial data does not contain heap data, but you can later instruct the system collect heap data on subsequent crashes. So produce debugging information for your release binaries and keep archive them.
If you’re planning on certifying your product, the use of winqual error reporting is a requirement. We were disappointed with this because we had our own error reporting system that we feel better serves support issues. We got our report data immediately, and we are able to search the data any way we see fit. Because we certified our product, we had to abandon our better system for Microsoft’s.
Useful Links