Winqual Microsoft Product Feedback Mapping Tool

Here is a post for the "average" software developer signing up for Microsoft Winqual and mapping their products. The documentation available isn't every helpful, and it's easy to make mistakes when first mapping your product, thus ending up with too many useless/irrelevant data (at least that's the mistake I made! :) )

Winqual is the great service provided by Microsoft for ISVs to get access to Dr Watson and WER (Windows Error Reporting) data, such that you can improve your/your company’s software quality. This is a bigger deal in Vista, since the reporting loop is now closed, and you can provide feedback about the reported issue to the end-user via the Winqual service.

By an "average" software developer, I mean a vendor shipping software that is for the end-user in mind vs perhaps a vendor shipping a library or component used by other software developers.

That end-user product usually has dependencies on various 3rd party dlls as well as the standard Microsoft dlls. The trick here is to get feedback just on the software you own and are responsible for, while excluding getting data from software that you don’t support. This would mean you would want to know about all crashes in your .exe, whether it was executing your code, or in a 3rd party library or MSFT library (often the case), whose root cause is statistically likely to be in your code anyways.

Either way, even if the fault lies in a 3rd party component, your company is responsible for following up with the vendor to resolve the issue for your end customer. Contrast this with specifically not wanted to get events from every product (only yours) that uses that 3rd party library (such as a regex) library.

The mapping can be done in many ways, but I would recommend for most average ISV software companies that the mapping is done on a per Product/Version basis.

I.e. Separate mappings for

Product A V1.0
Product A V2.0
ProductB V1.0
ProductB V1.1 (only changed binaries mapped)

It also depends on how you deliver SP/Hotfix updates; be it whether they are a complete redelivery of the product, a rebuild, or only the incremental binaries. For example, Product A might use a SP installer with only incremental binaries (only updated binaries changed).

In such a case I tend to map only the changed binaries, as I want failures only associated with the SP to show up under that product, and any failures in the base version to show up in the base version. In other words, customer runs Product A V1.1 (SP) but has a crash in a component that didn't get upgraded. This would be reported under Product V1.0.

So on to the mapping itself. The mapping tool is fairly self explanatory, you start by filling out your Product Files Directory Path, Name and Version.
So you might map something like:
Directory Path: C:\Program Files\ProductA V1.0
Name: ProductA
Version: 1.0

Since a lot of products use/include Microsoft dlls, you may get warnings that those dlls will be excluded. This is normal, and is Microsoft ensuring that you don’t get events from virtually every piece of Windows software on the planet. Note: this doesn’t mean you won’t get events from where you crashed in kernel32.dll, but was in ProductA.exe

Next comes the mapping itself, which is what you want to be most careful on. The safest method is to ONLY select your .exe(s). For example, let us pretend we are the Mozilla foundation wanting to get reports of crashes/hangs with Firefox. Note: Firefox happens to use its own crash reporting mechanism – TalkBack, but we can’t all be so lucky or have the infrastructure in place for this.

Here is the open source Firefox browser mapped with only .exe’s I know to be from this Firefox build selected.



Here is another screenshot showing more .dlls selected, as it seems likely these are directly used by this build of Firefox (the Link Date and Binary Version is the clue). You may want to include these dll’s as a sort of catch-all, so that you don’t miss any events. They should be associated with just this version of the product, but may include other versions, but at least are associated with Firefox itself. Sort by Binary Version, Link Data, Product Name and Directory Path to quickly isolate which binaries your company is responsible for.



Once you are all set you can upload the resulting XML file to Winqual. The end result should be that you are getting appropriate and useful data that you can use to fix issues and improve software quality. If you notice you are getting events from other software vendors, you can always manually remove the troublesome mappings, or delete & re-upload the mapping file.