You can link a response to either a file or a failure.

• Associating a response to a file is accomplished through a link on the dashboard.

• Associating a response to a failure is accomplished through your company reports.  Please navigate to your company report (e.g.: Product Summary Report) and expand the failure node. The “Responses” will appear as the last column of the report. The following screen shot provides an example of the experience:

The responses column can offer three options: a “Response Id” if the response is already linked to the failure, “Create Response” and “Not Applicable”. The “Create Response” option will only appear for a failure if there are enough cab files available (at least 5), and a strong relationship between the underlying client events and the failure.

If the failure do not meet the criteria, you will see a text that reads “Not applicable”. and you will not be able to link your response to this failure. Please click on the “Create Response” link to create and associate the response when the option is available.

Thank you.

WER team

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

Here are the list of changes in the feed. These updates will start for some companies at the end of this week and will be available for all companies with current reports by next week.

1) Product / Product Version split in the Product Detail Report. The feed splits the Product Version from the Product Name into separate fields.

Report Name: ProductDetailNonSuiteReport, ProductDetailReport.rdl

Feed Name: ATOMFeed

Example Before:

Product and Product Version: <d:Product>CrashMeForBuild Version 1.0.0.0</d:Product>

Example After:

Product: <d:Product>CrashMeForBuild</d:Product>

Product Version: <d:ProductVersion>1.0.0.0</d:ProductVersion>

2) Offset breakout of CABs: The Offset is the place in the code where the failure is happening. It helps with determining the root cause of a set of issues. Offset values are added in two feeds in the reports.

a) Offset addition to Product reports

Reports: CompanySummaryReport.rdl, ProductSummaryReport.rdl, ProductDetailReport.rdl, ProductSuiteSummaryReport.rdl, ProductSuiteDetailReport.rdl

Feed Name: ATOMFeed

Example new field:

Offset Value: <d:Failure_Offset>11A7</d:Failure_Offset>

b) Offset update to CAB details

Reports: CompanySummaryReport.rdl, ProductSummaryReport.rdl, ProductDetailReport.rdl, ProductSuiteSummaryReport.rdl, ProductSuiteDetailReport.rdl

Feed Name: CABFeed

Example new fields:

Offset Value: <d:Offset>106D</d:Offset>

Offset as percentage of CABs: <d:OffsetPc m:type="Edm.Double">1</d:OffsetPc>

Offset as percentage for other CABs: <d:OffsetAllOtherPercentage m:type="Edm.Double">0</d:OffsetAllOtherPercentage>

3) Addition of Operating System/Service Pack and file version associated with the CAB (can be Kernel or User Mode)

Reports: CompanySummaryReport.rdl, ProductSummaryReport.rdl, ProductDetailReport.rdl, ProductSuiteSummaryReport.rdl, ProductSuiteDetailReport.rdl

Feed Name: CABFeed

Example New Fields:

CAB OS and Service Pack: <d:CabOS>Windows 7</d:CabOS>

Is a File or Driver associated with CAB: <d:CabsFileDriverVersionHeader>File Version</d:CabsFileDriverVersionHeader>

Version of file associated with CAB: <d:CabVersion>1.0.0.1</d:CabVersion>

4) Addition of Operating System/Service Pack and file version associated with CAB (Kernel Mode or driver specific)

Reports: DriverDetailReport.rdl

Feed Name: CABFeed

Example New Fields:

CAB OS and Service Pack: <d:CabOSVersion>Windows 7 (SP1)</d:CabOSVersion>

Version of driver file associated with CAB<d:CabDriverVersion>6.1.7600.16385</d:CabDriverVersion>

5) Additions to ATOM feed to support pulling multiple driver versions in a report

Report: DriverDetailReport.rdl

Feed: ATOMFeed

Example New Fields:

CAB Date<d:Cab_Date m:type="Edm.DateTime">2012-08-02T00:00:00</d:Cab_Date>

CAB Type<d:Cab_Type>Kernel Mini</d:Cab_Type>

Link to CAB<d:Cab_Download_Link>CAB URL</d:Cab_Download_Link>

As mentioned in “The only thing constant is change” blog, user mode reports use the Failure based approach. When symbols are not available (the most common scenario) this can sometimes make it difficult to determine the root cause of an issue. In these cases, Failures with the same exception code, problem class and module are all grouped into failure with !unknown instead of the function name.

To help mitigate this issue the CABs will be broken down by an Offset grouping, with the Offset value and the percentage of overall CABs that have that value. The Offset is the place in the code where the failure occurred and it helps determine the root cause of a set of issues.  One item to keep in mind is that a file update can cause the Offset to move, so symbols are almost always the best way to identify issues.

Up to 10 CABs per Offset will be available and each Failure can show up to 10 Offsets.  This means that up to 100 CABs could be provided per Failure. Up to now, only 10 CABs are available per Failure. With the combination of more CABs and an Offset breakout, more debugging information will be available per Failure.

Each Failure will show an Offset breakout per CAB set, such as the below:

Each user mode report type will provide an Offset breakout per Failure including:

1) Company Hotlist – The top 10 Failures are provided across all mappings

2) Product Group summary – Provides top 10 Failures across all product mappings in a product group. Each of the product groups provide a per product drill down

3) Product Summary – Provides top 10 Failures for product not in a product group.  There is also a per product drill down providing more Failures

Based on feedback – we’re are also making the following changes with the CAB section of the report:

• For both user and kernel Failures, Full or Heap dumps will be prioritized over Mini dumps
• The OS version will be provided. This will be at an OS and Service Pack level, e.g. Windows 7 (SP1)
• For User Mode reports the File Version will be displayed, for Kernel Mode reports, the Driver Version
• For the Driver Summary Report, the Version Grouping will use a version sort rather than a string sort

Example of Kernel Mode Changes. The OS Version and Driver Version are new fields in the CAB section:

Example of User Mode Changes. CAB are broken down by an Offset group. OS Version and File Version are new fields in the CAB section:

With the report changes, this means some changes to the feed. The next blog will go over the feed changes in detail……

How do I map files?

Once you have authenticated using your Windows Live ID and finished synchronizing with the Microsoft Metadata Exchange Server, you will see your existing drivers and products if previously

provided. The mapping inventory is divided into three areas:

1) Drivers – Provides driver mappings on a file name basis. These are files that inform the Driver summary report, which show a version breakout.  Drivers can be mapped through choosing Drivers New Driver. When a duplicate mapping already exists, the file will need to be investigated for ownership. Once signoff exists, reports can be generated. In most cases the Signoff Status will be “Not needed.”

2) Products – Provides data based on specific files or file versions from specified directory. These files can be either kernel and/or user mode; however, the kernel files must be already mapped as a file in the Drivers section in order to be seen in Product based reports. The new product cycle view is a way of determining where in the development stage a product falls. This can help companies evaluate where to invest their development resources on fixes.

Products can be mapped through Products, New Product

Choose a Name and Version

And add the appropriate file or directory of files

Like driver files, when a duplicate mapping already exists, the product file will need to be investigated for ownership. Once signoff exists, reports can be generated. In most cases the Signoff Status will be “Not needed”

3)  Product Groups – Groups products for reporting. These mappings make up the Product group summary report. Products not part of a Product group are available in the Product summary report.

Product Groups are mapped by choosing the Product Group item

and associating the Product Group with existing Products

Once you’ve made your updates, you can publish your changes.  Published mappings will update the report data once CABs are collected for your selected Drivers, Product and Product Groups

Previously provided metadata around Drivers, Products and Product Groups can be saved through Tools Import metadata and Export Metadata

Q: How can I see Driver Reports

A: Make sure the Product Mapping Tool has entries in the Drivers area. The Driver Summary report will show error reporting data across all versions

Q: How can I see reports in the Product group summary?

A: Product Group must be mapped by default in the Product Mapping Tool. Product Groups are made up of different Products. This is a new concept that allows for more flexible ways of organizing data by concepts that makes sense to your organization (e.g. by Suite, by Division.) Once these mappings are created, the next generated set of reports will show a populated Product summary report

Q: How do I make sure I see data for my Product based mappings?

A:  In order for data to be provided to the reports the following conditions must be met:

1) Product data is based on the file version and link date granularity.  If a file version is used across multiple link dates, make sure mappings exist for all applicable files

2) CABs are collected within the last 30 days and a Failure (see the blog “the only thing constant is change – Part 1” for more information) has at least 4 hits

3) You company has logged into the Windows Dev Center within the last 60 days

Q: Where can I find information on report automation?

A: You can download sample code and description of the feed for each core report from the Microsoft Download Center

Q: How do I automate generating product mappings?

A: Automation is done through PowerShell. PowerShell uses the MicrosoftExchange module.This module can be directly initiated through the client

or directly though the PowerShell command

PS C:\Users\testuser> import-module MetaDataExchange

in both cases the Product Mapping Tool (Metadata Exchange client) must be present on the local system. You can get a list of commands through the below:

PS C:\Users\testuser> get-command -module metadataexchange

Q: How do I use PowerShell to automate product mappings?

A: Much like directly using the Product Mapping client, a product and associated files need to be provided.

Create a new product

This action uses the New-Product commandlet and pipes the output into Add-Product, which adds the product to the current Metadata Object

NAME New-Product

SYNTAX

    New-Product [-Name] <string> [-Version] <string> [[-Lifecycle] <Lifecycle> {Prerelease | CurrentRelease |

    Supported}]  [<CommonParameters>]

NAME Add-Product

SYNTAX

    Add-Product [-Product] <Product[]> [-IgnoreDuplicates] [-WhatIf] [-Confirm]  [<CommonParameters>]

    Add-Product [-ProductGroup] <ProductGroup> [-Product] <Product[]> [-IgnoreDuplicates] [-WhatIf] [-Confirm]

    [<CommonParameters>]

Console commands:

Select the file and open

You will see the changes reflected in the Publish Changes section of the tool. Click on Publish to submit the products for processing

Q: What is the Windows 8 Reliability Mappings Product and why do I see this within my Product summary list?

A: The Windows 8 Reliability Mappings Product is to support file mappings for the Windows 8 Reliability report. This report looks at the top issues affecting the reliability of Window 8. In order to provide CAB links within the report, mappings are required at the file version and link date granularity. If these mappings are not currently available through your organization’s current Product based mappings, they will be added to the Windows 8 Reliability Mappings Product. This is to ensure your organization continues to get CABs for the Windows 8 Reliability Report

Q: Where can I go if I can’t find an answer to my question?

A: Contact the Windows Dev Center Support Team

We surveyed users of WER data on https://winqual.microsoft.com to get feedback for the direction of features, the below two themes surfaced quickly as a result:

• “Reduce noise” – we had a lot of feedback around filtering out low priority “events” as these end up being time-wasters.
• “More automation & notifications” – Don’t make me always come to the website to get information push it to me.

We have made feature investments to help make progress in these areas:

“Reduce noise”

For the user mode datasets in the past we had shown “event” (a.k.a. Bucket) based information.  We are moving this dataset to be based on Failures which are the result of the !Analyze debugging extension.   Below I scratch the surface with the difference between these two datasets, but watching the Channel 9 video really helps to understand what logic goes into analyzing failures.

Buckets classify issues by: Application Name, Application Version, Application Build Date, Module Name, Module Version, Module Build Date, OS Exception Code, and Module Code Offset. On the surface this looks like a very precise way to classify issues; however it can be misleading at times since we generate this bucket on the Windows OS client without performing any symbol analysis on the memory dump.  The module that is picked by the Windows Error Reporting client is the module at the top of the stack.  We have found that investigating these issues as raw buckets can cause many investigations that result in a faulting module that is different from the original bucket determination.  Ryan Kivett (a developer lead from the Windows Reliability team) has a great blog post titled: WER History 101

Failures, however, are the result of processing memory dumps collected from buckets in order to more precisely assess blame to the appropriate module.  I have included the graphic below to show how buckets can result in multiple different failures.  While this is a typically scenario once private symbol analysis has been applied, there can also be cases where multiple buckets get aggregated into a !Unknown symbol as well.  If you download cabs and run !Analyze with your own private symbol paths you will break down the !Unknown failures into a very precise set of issues.

Here is another example considering multiple buckets:

Since we are performing automated analysis of issues using private symbols we are able to filter out issues where we know we will likely be able to provide a fix, in order to provide fewer issues that will result in investigations that point to issues in modules that don’t belong to you.  This is one of the ways we are reducing the noise in the dataset.  This doesn’t mean that there will be fewer number of issues, but the issues we share are more likely to be actionable for your software.

The below video contains a detailed explanation of the logic behind !Analyze and what goes into the failure dataset.

“More automation & notifications”

We are providing email updates for all the new failure based reports that are going to be published based on the new user mode failure based dataset and the kernel mode failure based dataset as well.

Stay tuned for more updates on planned changes, Part 2 will provide more information…

Synchronous XMLHttpRequest Blocks the UI Thread

We already know performing a blocking operation on a UI thread is asking for trouble. We’ve blogged about this before. It might not be apparent, but this is exactly what can happen when calling the XMLHttpRequest.send() method synchronously (i.e. passing false for bAsync when calling the open method). The UI thread has to wait until it gets a response from the server, or until the request times out. While waiting, it’s not pumping messages.

Why Use Synchronous XMLHttpRequest At All?

Developers tend to use synchronous over asynchronous is because it’s easier and can many times lead to less complex code. This StackOverflow thread states some potentially valid opinions on why you’d use one over the other, but nothing compelling enough that makes it worth the risk.

Fixing It…

There are at least two ways you can write your code to avoid these hangs. The first method is preferred, because you won’t block on the UI thread. The second is less than optimal, because you’ll still block, but for less time than you’re probably doing now.

1. Write your code to call open asynchronously.
   You need to pass true for the bAsync parameter to the open method, and you need to write an event handler for the onreadystatechange event. There are many examples of how to do this out one the web, like this one.
2. Set the timeout property.
   Because the Desktop Window Manager detects a hang after 5 seconds of unresponsiveness, and IE9 Hang Resistance after 8, I would set the timeout property to something under 5 seconds. You may also want to consider creating a function to handle the ontimeout event.
   (How did I get these numbers? Refer to here and here respectively – also already mentioned above)
   

How About an Example?

Let’s dig into the details by creating a couple of scenarios:

1. We’ll create some code that will make a synchronous request and hang the browser, and then
2. change the code to be asynchronous, and observe the acute change in browser behavior.

The goal of these scenarios is to demonstrate how switching from synchronous to asynchronous requests will improve the user experience of your web applications.

DISCLAIMER: This will hang your browser and may result in unintended, perhaps even undesirable behavior on both the client and the server. In other words, don’t run this on your production server, or any other machine that can’t tolerate running instable and potentially broken code.

 The Setup

You’ll need a web server capable of running ASP.NET if you want to follow the example directly. I realize some readers may not be using ASP.NET, but the code should be straight-forward enough that you can adapt it to other environments without too much trouble.

Also, I will assume you are familiar with your web server environment and know how to render a page server-side.

Copy this code into your favorite text editor and save it as hangme.aspx somewhere on your web server. 

 <!-- code starts after this line -->
 <%@ Page Language="C#" %> 
 <html> 
 <head> 
 <title>XmlHttpRequest open hang test</title> 
 <script runat="server">
    protected void Page_Load(object sender, EventArgs e) { 
       if(Request.QueryString["hang"] == "1") {
          int seconds = 0; 
          Int32.TryParse(Request.QueryString["seconds"], out seconds); 
          System.Threading.Thread.Sleep(seconds * 1000); 
       } 
    } 
 </script> 
 <script type="text/javascript"> 
    function call_hangme() { 
       var oReq;       if (window.XMLHttpRequest) { 
          oReq = new XMLHttpRequest(); 
       } 
       if (oReq != null) { 
          var sUrl = "http://localhost/hangme.aspx?hang=1&seconds=360"; 

          <!-- change localhost to your server name if applicable --> 
          document.getElementById("txt1").innerHTML = "Request Sent..."; 

          <!-- pass false for the bAsync parameter for a synchronous request --> 
             oReq.open("GET", sUrl, false); 

          oReq.send(); 
          document.getElementById("txt1").innerHTML = "Response Received!"; 
       } 
       else { 
          window.alert("Error creating XmlHttpRequest object."); 
       }
    }
 </script> 
 </head> 
 <body> 
    <p>Click this button to hang the browser</p> 
    <form name="form1" action="" method="get"> 
       <input type="button" name="btn1" value="hang me" onClick="call_hangme()"> 
    </form>
    <p id="txt1"/> 
 </body> 
 </html> 
 <!-- code ends on the line before this one --> 

 Make It Hang

Now,

1. Open Internet Explorer and browse to the hangme.aspx page.
2. Click the “hang me” button.

Uh-oh! We’re hung! Because we told the thread to sleep for 6 minutes, we’re going to be here awhile. If you’re using IE9, you’ve probably noticed the gold band at the bottom offering to “Recover webpage”. If you’re using another browser, you’ve probably got a ghosted window.

Calling Open Asynchronously

Copy this code new file and save it as wont_hangme.aspx. 

 <!-- code starts after this line -->  
 <%@ Page Language="C#" %>
 <html>
 <head>
 <title>XmlHttpRequest open hang test</title>
 <script runat="server">
    protected void Page_Load(object sender, EventArgs e) {
       if(Request.QueryString["hang"] == "1") {
          int seconds = 0;
          Int32.TryParse(Request.QueryString["seconds"], out seconds);
          System.Threading.Thread.Sleep(seconds * 1000);
       }
    }
 </script>
 <script type="text/javascript"> 
    function hangme() {
       var oReq;
       if (window.XMLHttpRequest) {
       oReq = new XMLHttpRequest();
       }

       if (oReq != null) {
 
          <!-- change localhost to your server name if applicable -->
          var sUrl = "http://localhost/wont_hangme.aspx?hang=1&seconds=500"; 
          document.getElementById("txt1").innerHTML = "Request Sent...";

          <!-- pass true for the bAsync parameter -->
          oReq.open("GET", sUrl, true); 

          <!-- Here we define an anonymous function for the 
           onreadystatechange event.  We check if we received all the data, 
 >           and the request was successful before changing the text
          -->

          oReq.onreadystatechange = function() {
             if (oReq.readyState == 4 && oReq.status == 200) {
                document.getElementById("txt1").innerHTML = "Response Received!";
             }
          }

          oReq.send();
       }
       else {
          window.alert("Error creating XmlHttpRequest object.");
       }
    }
 </script>
 </head>
 <body>
    <p>Click this button to hang the browser</p>
    <form name="form1" action="" method="get">
       <input type="button" name="btn1" value="hang me" onClick="hangme()">
    </form>
    <p id="txt1"/>
 </body>
 </html>
 <!-- code ends on the line before this one --> 
 

The new code is highlighted. Here, we’re now calling open with bAsync = true, which means we’re making an asynchronous call. This will free up the UI thread to do other things, instead of it being blocked waiting for the response or timeout. If we’re not blocked, we can pump messages, and if we can do that, we’re not hung!

Now, when the response eventually comes back from the server, we’ll need a function to handle it. That is what the highlighted code does. It’s our event handler for onreadystatechange event. As you can see, I’m only checking that there response was successful (status == 200) and that all the data has been received (readyState == 4).

Can We Make It Hang Now?

Again,

1. Open Internet Explorer and browse to the cant_hangme.aspx page.
2. Click the “hang me” button.

Voilà! You’ll see the request is sent, but the browser is not hung. When the response finally makes its way back, the text will change; all the while you’re still able to interact with the page.

In Closing

As stated from the outset, you want to implement your XMLHttpRequest calls asynchronously. This example clearly demonstrates why; you’ll improve the responsiveness of your pages, avoid hangs, and most importantly, give your users a better experience.

I work on the team that approves and publishes responses, and if you’ve created more than a few responses, there’s a good chance that we’ve worked with you to clarify your response content at some point. Since clarifications add time to the approval and publishing process, I wanted to give you a checklist of things to look at before you submit a response, so that your responses will sail through approval and publishing.

·         Is the landing page straightforward and uncomplicated? Can you link to a better page, or better yet, a direct download? (The number one reason we clarify responses is that it links to a top-level page, like www.microsoft.com.)

·         Does the experience described in the template you used match the one that users will actually see? For example, if the template says a direct download is available, the linked URL should point to that download, not to a landing page that requires further action from the customer. Note that the templates you see on Winqual are only a subset of what is available.

·         Does a landing page link provide what is promised? For example, if the template selected promises an automated update tool, but the landing page for the response describes a manual update process that doesn’t use a tool, the message could be clearer.

·         Is the solution within easy reach of the user? The guideline we try to hit with every response is three clicks, including the main URL in the response itself.

·         Is your download as directly and easily usable as it could possibly be? Users have an easier time with an MSI than they do with a self-extractor or .zip file, for example, and the smaller the download, the better.

·         Does your response require More Info links? These should not be used unless the response does not work without them. There are a couple of reasons for this:

• Any More Info link text will need to be localized, which means that the entire response be available only in English for 4-6 weeks
• We found through our research that most customers just don’t see More Info links. Customers look for links in the body of the response.

These points cover the majority of response clarifications that we see. Of course, you might need input or have questions before you even create a response. We’d be glad to help you out. If you have any questions or any specific needs, let us know. Send email to WERCMS@microsoft.com, and we’ll give you a hand. Thanks for using Windows Error Reporting and letting us help you.

Kent Walter
Windows Error Reporting

Defined Terms and Concepts

XPROC cab

The “X” stand for cross and the “PROC” stands for process. So in other words, we’re talking about a cross process dump. And what is that exactly? Well, when an app is hung due to cross-process communication, we capture a dump of the hung process and, when possible, the process determined to be at the end of the “wait chain” in the inter-process communication. We include both dumps, as well as other analysis related information, in the cab submitted with the error report. XPROC dumps were introduced in Vista, but there were cases where the state of the hang would be lost before the heap dump was captured.

Process Reflection

At its core, Process Reflection is used to make a clone of an existing process. This clone, also referred to as the reflected process, contains a single thread and a copy of the original process’ address space. Mark Russinovich talks more about it here (31:00)

In the case of hang reporting, when a chain of processes is involved in the hang, we use Process Reflection to create a clone of the process determined to be at the end of the wait chain by virtue of the GetThreadWaitChain API. A heap dump is taken of the clone instead of the original. Cloning takes way less time than generating a heap dump file, so using this technique, we increase our chances of capturing the hung state, than if we were just create a dump of the original process. Also, it’s worth pointing out that our single thread in the clone does not execute during hang reporting, so it is simply parked and left idle. Here’s what its stack looks like today:

ChildEBP RetAddr
0028fdbc 77a97b8c ntdll!KiFastSystemCallRet
0028fdc0 77af02ef ntdll!ZwWaitForSingleObject+0xc
0028fe38 75ef0239 ntdll!RtlpProcessReflectionStartup+0x1bf
0028fe44 77ab1ec2 kernel32!BaseThreadInitThunk+0xe
0028fe84 77ab1e95 ntdll!__RtlUserThreadStart+0x70
0028fe9c 00000000 ntdll!_RtlUserThreadStart+0x1b

When it comes to debugging analysis, some things aren’t readily apparent with the reflected process. For instance, what about the original threads? Does the handle data conflict with that of the original process? After all, the reflected process is a process in its own right. The short answer is the debugger handles all of this for you. As they say, “the devil is in the details” so we’ll get into how the debugger does this shortly. But first, it’s important to understand the files contained in an AppHangXProcB1 bucket’s cab.

On to the Fun Stuff...

AppHangXProcB1 Cab Contents

So to recap:

A hang has occurred. We get a heap dump of the hung process. Using GetThreadWaitChain(), we discover the process at the end of the wait chain and clone it using ProcessRelection.
Next we grab a heap dump of the clone. But, we also have to deal with the fact that the thread and handle data from the original aren’t copied to the clone. So, in addition to this heap dump, we also capture a mini dump of the original process that has the thread and handle data. The debugger knows how to “stitch” both files together into a single, coherent target.

Let’s take a look at an example cab:

File name                      File size     Date      Time   Attrs
-----------------------------  ---------- ---------- -------- -----
   iexplore.exe.xml                  5496 2010/07/14 16:25:22  ----
   iexplore.exe.6e79.wxhu.dmp.dbgcfg.ini      224 2010/07/14 16:25:22  ----
   WER57FB.tmp.ref                1596362 2010/07/14 16:25:22  ----
   iexplore.exe.6e79.wxhu.dmp    150380775 2010/07/14 16:25:22  ----
   memory.hdmp                   40343241 2010/07/14 16:26:18  ----
   WERInternalMetadata.xml           3226 2010/07/14 16:26:30  ----
   AppCompat.txt                    47354 2010/07/14 16:26:30  ----

Look at the contents of the dbgcfg.ini file and you'll see something like this:

[UserModeDump]
default=WER57FB.tmp.ref
memory=iexplore.exe.6e79.wxhu.dmp
module=iexplore.exe.6e79.wxhu.dmp

You may be able to discern what’s going on here. The *.tmp.ref file is the default target, which is the original process mini dump that I described earlier; the one with the thread and handle data. Using the debugger, you can view the flags passed to MiniDumpWriteDump used to create this file and thus the data contained within:

0:004> .dumpdebug
----- User Mini Dump Analysis

MINIDUMP_HEADER:
Version         A793 (61B0)
NumberOfStreams 11
Flags           1104
                0004 MiniDumpWithHandleData
                0100 MiniDumpWithProcessThreadData
                1000 MiniDumpWithThreadInfo

The *.wxhu.dmp file is the reflected process dump. Its naming convention hasn’t changed from Vista. So, those of you that have been working with XPROC dumps in Vista may have been a little confused when you analyzed this file from a Windows 7 machine, only to see one thread waiting in RtlpProcessReflectionStartup. Open the file directly in the debugger and you’ll see that it has full data, thread and memory info, etc…

0:000> .dumpdebug
----- User Mini Dump Analysis

MINIDUMP_HEADER:
Version         A793 (61B0)
NumberOfStreams 14
Flags           51B25
                0001 MiniDumpWithDataSegs
                0004 MiniDumpWithHandleData
                0020 MiniDumpWithUnloadedModules
                0100 MiniDumpWithProcessThreadData
                0200 MiniDumpWithPrivateReadWriteMemory
                0800 MiniDumpWithFullMemoryInfo
                1000 MiniDumpWithThreadInfo
                10000 MiniDumpWithPrivateWriteCopyMemory
                40000 MiniDumpWithTokenInformation

You’ll also probably notice that this dump also has handle data. But again, hang reporting does not duplicate the handle data from the original to the reflected process, so the only handle you should see is a process handle from the original process:

Stream 10: type HandleDataStream (12), size 00000038, RVA 08F35E0F
  1 descriptors, header size is 16, descriptor size is 40
    Handle(0000000000000008,"Process","")

Viewing the "Stitched" Target

There are at least two ways you can view the stitched target (using the same cab as an example):

1. Extract the files from the cab and open the *.dbgcfg.ini file instead of the individual dump files
   
   C:\debuggers\cdb -z C:\temp\xproc\iexplore.exe.6e79.wxhu.dmp.dbgcfg.ini
   
   Microsoft (R) Windows Debugger Version 6.13.0001.776 X86
   Copyright (c) Microsoft Corporation. All rights reserved.
   
   Loading Dump File [C:\temp\xproc\iexplore.exe.6e79.wxhu.dmp.dbgcfg.ini]
   Loading User-mode Dump Configuration File [C:\temp\xproc\iexplore.exe.6e79.wxhu.dmp.dbgcfg.ini,C:,\temp\]
           default dump: [WER57FB.tmp.ref]
           memory dump: [iexplore.exe.6e79.wxhu.dmp]
           module list dump: [iexplore.exe.6e79.wxhu.dmp]
   
   Loading Dump File [C:\temp\xproc\WER57FB.tmp.ref]
   User Mini Dump File: Only registers, stack and portions of memory are available
   
   Loading Dump File [C:\temp\xproc\iexplore.exe.6e79.wxhu.dmp]
   User Mini Dump File: Only registers, stack and portions of memory are available
   
   
   
2. Open the cab file directly in the debugger. Then open the dbgcfg.ini file from there
   
   C:\debuggers\cdb –z C:\temp\xproc\sample.cab
   
   Microsoft (R) Windows Debugger Version 6.13.0001.776 X86
   Copyright (c) Microsoft Corporation. All rights reserved.
   
   Extracted C:\temp\xproc\000011a00_memory.hdmp from C:\temp\xproc\sample.cab
   
   Loading Dump File [C:\temp\xproc\000011a00_memory.hdmp]
   User Mini Dump File: Only registers, stack and portions of memory are available
   
   0:016> .opendump /c "iexplore.exe.6e79.wxhu.dmp.dbgcfg.ini";g
   Extracted C:\temp\xproc\000011a00_iexplore.exe.6e79.wxhu.dmp.dbgcfg.ini from C:\temp\xproc\sample.cab
   
   Loading Dump File [C:\temp\xproc\000011a00_iexplore.exe.6e79.wxhu.dmp.dbgcfg.ini]
   
   Loading User-mode Dump Configuration File [C:\temp\xproc\000011a00_iexplore.exe.6e79.wxhu.dmp.dbgcfg.ini]
           default dump: [WER57FB.tmp.ref]
           memory dump: [iexplore.exe.6e79.wxhu.dmp]
           module list dump: [iexplore.exe.6e79.wxhu.dmp]
   
   Loading Dump File [C:\temp\xproc\000011a00_WER57FB.tmp.ref]
   
   Loading Dump File [C:\temp\xproc\000011a00_iexplore.exe.6e79.wxhu.dmp]
   
   
   
3. Just run !analyze. It uses the same procedure outlined in option 2, and it leaves the targets opened once it’s finished.

Last But Not Least!

Make sure you have the latest debugger or else it may not recognize this type of target. You can download it from here.

A SpringBoard Series is available here: http://technet.microsoft.com/en-us/windows/bb899442.aspx

A great starting place to learn about all MDOP has to offer is here: http://technet.microsoft.com/en-us/windows/ff383366.aspx

For the Error Reporting Component (DEM) here are two links to videos that are worth watching:

• A Tour of Desktop Error Monitoring 
• Using MDOP Desktop Error Reporting

The Official MDOP Blog