Habib Heydarian's Blog @ Microsoft : Historical Debugger

Coverage of the Visual Studio 2010 Historical Debugger

habibh — Mon, 21 Sep 2009 10:04:00 GMT

During the last couple of months, I've covered the Historical Debugger extensively. If you are interested in learning more about this new feature in Visual Studio 2010, the following blog entries should help you get started.

Habib Heydarian.

An in depth look at the Historical Debugger in Visual Studio 2010 (Part VI)

habibh — Sat, 19 Sep 2009 06:48:38 GMT

In previous blogs, I have covered the Historical Debugger extensively and talked about many of the scenarios. In this post, I'll walk through another scenario where the Historical Debugger is very useful which is Load Testing. When loading testing an application, you can have the Historical Debugger collect information during the run and if one or more of the tests fail, you can use the Historical Debugger log file to debug the test failure(s).

Let's walk through an example. For this walkthrough, I have a Load Test which contains a single Web Test. The application under test is the BeerHouse sample application.

The first step in setting up the Historical Debugger for collecting data during load testing is to enable the "Diagnostic Tracing" option in the Test Settings, as shown below.

Once you've enabled the Historical Debugger, the next step is to run the Load Test. After the Load Test is complete, you should see the test result details which also includes the number of errors, shown below.

While the Load Test was executing, the Historical Debugger was recording the execution history. The following screenshot shows the Historical Debugger log file (QTAgent32_000013d0_090918_204309.tdlog).

Double-clicking the log file opens the Historical Debugger Summary page, shown below. Using the summary page, you can investigate the root cause of the test failure.

Habib Heydarian.

How to debug an exception with the Visual Studio 2010 Historical Debugger

habibh — Wed, 05 Aug 2009 09:08:29 GMT

In a previous blog, I covered how to debug a LINQ to SQL query using the Historical Debugger. In this blog, I'll discuss using the Historical Debugger to debug an exception. The are a couple of reasons why the Historical Debugger is so useful when it comes to debugging exceptions:

If your application handles the exception (catches it), you can see where it occurred
You can see what happened before and after the exception. The ramifications of this capability are tremendous!
You can double-click on an exception and go directly in your code where the exception occurred or was handled.

Let's go through an example. In the following screenshot, you can see that there are a number exceptions that were both thrown and caught. This is indicated by the Exception: prefix.

Double-clicking on the exception above brings up the source window and displays the method where the exception occurred.

Last but not least, using the Debug History window, you can filter out all other events and only display exceptions, as shown below.

Habib Heydarian.

The anatomy of the Historical Debugger Navigation Bar (Navbar)

habibh — Thu, 23 Jul 2009 23:52:30 GMT

In a recent Channel 9 10-4 video, Brian Keller introduced the Historical Debugger in Visual Studio Team System 2010. One of the features that he described in his video was the Historical Debugger Navigation Bar (Navbar) which he used to step back in the application.

In this post, I'm going to describe in detail what the navigation bar does and how to use it. Let's start with a screenshot of what I mean by the navigation bar.

The idea behind the Historical Debugger Navigation Bar is that you can use it to "time travel" through your application and go back and forward in your application to debug a problem. Think of it as the remote control for your Digital Video Recorder (DVR). You can rewind and fast forward as well as skip to sections of your application that you want to debug. The following screenshot shows what the individual controls on the Navbar do and the corresponding shortcut keys.

You can download Visual Studio Team System Beta 1 which includes the Historical Debugger. I've included the following sample code below so that you can use it to play around with the Historical Debugger. I'm always eager to hear your feedback.

using System;

class Program
{
    static void Main()
    {
        Sphere earth = new Sphere();
        double earthRadius = 3956.6; // miles
        double earthArea = earth.CalculateArea(earthRadius);
        Console.WriteLine("The area of earth is {0} square miles", earthArea);
    }
}

public class Circle
{
    // Area = PI * (R) ^ 2
    public double CalculateArea(double radius)
    {
        return (Math.PI * Math.Pow(radius, 2));
    }
}

public class Sphere
{
    // Area = 4 * Area of Circle
    public double CalculateArea(double radius)
    {
        Circle c = new Circle();
        return (4 * c.CalculateArea(radius));
    }
}

Habib Heydarian.

An in depth look at the Historical Debugger in Visual Studio 2010 (Part V)

habibh — Fri, 19 Jun 2009 03:01:00 GMT

In the fifth installment of this series, I’m going to look at how to use the Historical Debugger to diagnose a Unit Test failure. The experience for using the Historical Debugger for debugging Unit Testing is somewhat similar to diagnosing a manual test failure but the steps are quit different.

Example: Debugging a Unit Test Failure

The WPF Patient Monitoring solution that I’m using for this example contains several Unit Tests that test the charting functionality in the application. You can see the list of tests in Test View window below.

In order to enable the Historical Debugger, the first step is to configure the Test Settings by editing the *.testrunconfig file in the solution, as shown below.

In the "Configure Test Settings" dialog, select the Data and Diagnostics tab on the left. Then, check the Diagnostic Trace Collector option to enable the Historical Debugger as shown below.

After configuring the test settings, you can run all the Unit Tests in the solution. When you run the Unit Tests and one or more tests fail, you can investigate the failure further by opening the Test Results Details for each failed Unit Test from the Tests Results window, as shown below.

The Test Results Details window displays various information about why a test failed. Included in this window is a link to the Historical Debugger log that contains the history of what the application under test (not the test itself) was doing when the error occurred.

Opening the log file displays the Historical Debugger Summary page. To investigate why the test failed, a developer can double-click any of the exceptions in the Exceptions list. This will start replaying the set of events that led to the failure.

Habib Heydarian.