Windows Dev Center Reports – Failures based on the faulting process

In June 2013, the Dev Center reports were updated. Failures are now provided based on the faulty process, in addition to the faulting module which was used previously. These changes provide another level of granularity in determining which company should be notified for each failure. This update is beneficial for companies who use common and shared files. Below is a sample scenario to explain the updates.

Sample Scenario:

• There are two products (Product 1 and Product2)
• Product 1 has mapped ProcessA.exe and ModuleA.dll
• Product 2 has mapped ProcessB.exe and ModuleA.dll, but indicated that ModuleA.dll is “Common/Shared” so only failures from their ProcessB.exe will be provided on their reports.

Summary:

• If the faulty module and the faulty process are mapped to a product, then failure information is aggregated on the module
• If the faulty process is mapped but the faulty module is not, then failure information is aggregated on the process
• If the faulty process is mapped and the faulty module is mapped but the module is indicated to be “Common/Shared”, then failure information is aggregated on the process

Conclusion:

• Reports for Product 1 prioritize the failures resulting from both ProcessA.exe and ModuleA.dll.
• Reports for Product 2 prioritize the failures resulting from only ProcessB.exe, removing additional noise and cabs from ProcessA.exe.

Product Mapping Tool Updates:

Checking the “Common/Shared” box will filter out failures when the corresponding file is the faulty module. Please note, if you previously had the “IsThirdParty” box checked that field has been cleared and repurposed to indicated “Common/Shared” files. Repurposing this field had no impact to the existing reports.

Report Updates:

Process information is displayed on the report.

Call to Action:

• Map the processes owned by your company to receive failures for those processes
• If you are receiving failures from a common or shared component you do not wish to receive data from then mark the “Common/Shared” box to filter the data out

Comments

• Anonymous
  July 18, 2013
   I'm liking the changes; this will be helpful in tracking down issues, and now gives me the ability to see Windows Module failures attributed to our SW.  One concern I have, however (and I could be missing something completely obvious), is that many of the Failures I'm now seeing have multiple, unique, PROCESS names. --What is missing is the % of hits that can be attributed to each PROCESS.  Without being able to properly quantify the failure for our SW, it almost starts adding 'noise'. :|   Having said that, again, I appreciate you exposing more information (as we used to see in WinQual days). :) -Ted