Habib Heydarian's Blog @ Microsoft

Search For This Line In IntelliTrace

One of the key benefits of IntelliTrace is that it collects lots of useful information about your application which allows you to debug exactly what the application was doing when a problem occurred. With so much information, it's important to be able to search for the specific data that led to the bug in the program. IntelliTrace provides a couple of features inside the editor that allow you to narrow down your search:

1. Search For This Line In IntelliTrace
2. Search For This Method In IntelliTrace

Both of these features are available from the editor context menu (shown below). In this blog post, I'm going to cover the first feature, i.e. Search For This Line In IntelliTrace. In a future blog, I'm going to cover the second feature, i.e. Search For This Method In IntelliTrace.

So what does the "Search For This Line In IntelliTrace" command do exactly and how is it used? Let's walkthrough a simple example to see how this feature works. In the following code snippet, I am interested in finding out how many times the the statement ShoppingCartItem item = FindItem(product); (line 7 below) was executed and also, I want to figure out what happened before this line was called.

   1: /// <summary>

   2: /// Adds a product to the cart

   3: /// </summary>

   4: public void AddItem(Product product, int quantity, DateTime dateAdded) {

   5:  

   6:     //see if this item is in the cart already

   7:     ShoppingCartItem item = FindItem(product);

   8:  

   9:     if (quantity != 0) {

  10:         if (item != null) {

  11:             //if the passed in amount is 0, do nothing

  12:             //as we're assuming "add 0 of this item" means

  13:             //do nothing

  14:             if (quantity != 0)

  15:                 AdjustQuantity(product, quantity);

  16:         } else {

  17:             if (quantity > 0) {

  18:                 item = new ShoppingCartItem(product, quantity, dateAdded);

  19:  

  20:                 //add to list

  21:                 Items.Add(item);

  22:             }

  23:         }

  24:  

  25:     }

  26: }

In order to do that, I can right-click on line 7 above and select "Search For This Line in IntelliTrace".

After selecting the command, the IntelliTrace Search Bar is shown at the top of the editor window. The screenshot below highlights the IntelliTrace Search Bar.

Think of the Search Bar as the controls on your DVR where you can go backwards and forwards through your IntelliTrace recording. One of the key features that the IntelliTrace Search Bar provides is displaying the number of times that a line of code was executed. In the example below, you can see that the highlighted line was executed 4 times.

Using the Search Bar, you can debug backwards from the time when the line of code was executed. In the screenshot below, after clicking the left arrow once, I can now use IntelliTrace to step back through the code.

Habib Heydarian.

IntelliTrace: A graphical comparison

One of the easiest ways to understand what IntelliTrace is and what it does, is through a comparison between how most developers debug their application today vs. what IntelliTrace enables.

In the figure below, the blue section labeled (1) shows one of the most common ways that developers debug their applications today which is by writing code , e.g. Debug. WriteLine("Calling Web Service") to figure out what the application does.

This is often called "explicit instrumentation" because the developer explicitly adds code to the application to instrument its behavior. After the application runs, a log file is generated which is often just a plain text file that developers view using Notepad. This type of debugging is tedious and it can take a long time to investigate a bug.

In comparison, IntelliTrace alleviates the need to write trace statements just to figure out what the application is doing. In the green section above labeled (2), the IntelliTrace Recorder automatically records what the application does and allows the developer to replay the recording at a later time. Specifically, IntelliTrace provides three capabilities:

• Record
• Playback
• Rewind

What's important to note is that IntelliTrace also provides a rich UI to analyze the application recording. No more wading through volumes of text in Notepad just to figure what the application was doing.

Habib Heydarian.

How to Count the Lines of Code (LOC) in your application using Visual Studio

I was talking to someone the other day and he asked me whether Visual Studio has a tool to count the lines of code in an application. It occurred to me that others might be interested in the answer so I decided to blog about it.

There is a tool called Code Metrics in Visual Studio 2008 and 2010 that among other things, counts the lines of code in a project. Using Code Metrics is very simple. In Solution Explorer, select the project that you want to know the LOC for, right-click and select "Calculate Code Metrics".

The screenshot below shows the Code Metrics window. One of the nice things about the Code Metrics window is that it shows you the lines of code per project, namespace, class or method.

Habib Heydarian.

Looking for questions or feedback on IntelliTrace

During the last few months, I've been blogging extensively about a new Visual Studio 2010 feature called IntelliTrace (formerly known as the "Historical Debugger"). We are very excited about IntelliTrace and think that it's going to change how people debug their applications.

Since IntelliTrace is a brand new feature, we are eager to hear from developers about what they think about it. So, here is my offer: If you have any questions or feedback (both positive and negative) about IntelliTrace, send me your feedback via this blog and I will reply with an answer within 24 hours. Regardless of weather you've used IntelliTrace extensively and have an "advanced" questions, or you've never used it before and just want to learn about it, I'll be happy to answer any questions related to IntelliTrace.

Thanks in advance.

Habib Heydarian.

Using IntelliTrace to view the return value of a VB or C# method

A few months ago, I blogged about how to view the return value of a C# or VB method in the Visual Studio debugger. As I explained in that blog post, the debugger does not support viewing the return value of a .NET method, so you have to apply a workaround or two.

Being able to see the return value of a method comes in particularly handy when you have methods that take other methods as their parameters, e.g. F(A(x), B(y)), where A() and B() are methods themselves. For example, in the code example below, how can you see the value that is returned by c.CalculateArea(radius)?

IntelliTrace in Visual Studio 2010 makes it easy to view the return value of a method.

The first step is to change the default IntelliTrace options to record "events and call information", as shown below.

After enabling the above option, IntelliTrace will record the return value and parameters of all methods in the running application. Now, whenever you stop in the debugger, the IntelliTrace NavBar is displayed in the editor margin. To see the return value of a method, click the "Go to Previous Event" button (Ctrl+Shift+F11) to step back to the method that you want to see the value for, shown below.

After clicking the button, the debugger will display the method that you stepped back to in the Autos window, as shown in the following screenshot.

Expanding the method in the Autos window will display the return value. The debugger displays the name of the return value as [Return Value].

Habib Heydarian.

IntelliTrace is not available. Why?

When using IntelliTrace, you might run across the following error message in the IntelliTrace window:

IntelliTrace is not available. See the Debugger Output window or the Windows Application Events Log.

Below is a list of reasons why you might see the above error message when trying to use IntelliTrace.

1) In Visual Studio 2010, IntelliTrace does not support debugging a 64-bit process inside Visual Studio. You can workaround this limitation by changing the project configuration for your project to 32-bit. See this article for more details.

2) IntelliTrace is not available if you have attached to the application that you are debugging. The only workaround is to start the application under the debugger.

3) IntelliTrace is not supported for native C++ applications. We hope to fix this limitation in the future.

4) IntelliTrace does not support SQL CLR projects

If you have any feedback or are seeing the above error messages in other scenarios, feel free to send me feedback.

Habib Heydarian.

The future of debugging is here! Visual Studio 2010 now supports stepping back in the debugger.

In my previous post Getting Started with Visual Studio 2010 IntelliTrace: Hello IntelliTrace!, I described how to use the new IntelliTrace feature in Visual Studio 2010 to debug an application. But there's more to IntelliTrace. IntelliTrace also allows you step back in the debugger! However, the step back functionality isn't enabled by default. You can enable this feature via Tools->Options->IntelliTrace. On the IntelliTrace Options dialog, select the IntelliTrace events and call information option. This is shown in the dialog below.

After selecting the option, you can now use the debugger step back through the code. In the following screenshot, you can see a before and after screenshot. On the left hand side (screen 1), the Step Back button is highlighted. The right hand side (screen 2) shows what happens after I've clicked the Step Back button, i.e. the debugger has stepped back into the calling function, Main().

We are very excited about IntelliTrace and we think it's going to change developers' lives. If you have any questions or feedback about IntelliTrace, feel free to drop me a line.

Habib Heydarian.

Getting Started with Visual Studio 2010 IntelliTrace: Hello IntelliTrace!

One of the most talked about features in Visual Studio 2010 Beta 2 is IntelliTrace. In a nutshell, IntelliTrace allows a developer to record the application execution and play it back. Using IntelliTrace, a developer can do some cool things like step back in the debugger.

In this blog post, I'll do a "Hello World!" version of IntelliTrace to help you get started with this feature. We'll start with a vanilla Windows Form project and use it to explore various capabilities of IntelliTrace.

To start with, create a brand new Windows Forms project using either VB or C#. Then, drag and drop a button on the form, as shown below.

Double-click on the button and add the following line to the click event handler.

Debug.WriteLine("Hello IntelliTrace!")

Press F5 to run the application and then click on the "Hello IntelliTrace!" button. On the right-hand of the screen, you should see a new window called the IntelliTrace window, as shown below. Click on the "Break All" link in the IntelliTrace window.

After clicking the "Break All" button, the IntelliTrace window displays a number of very useful "events", as shown below. IntelliTrace records what happened in your application in chronological order. So, reading down the IntelliTrace window, you can see that the following things happened:

1. The application started under the debugger
2. The user clicked on a button with the label "Hello IntelliTrace!"
3. The application output some trace information using Debug.WriteLine()
4. The application paused in the debugger

What IntelliTrace is doing is keeping a diary or journal of the application as it was executing so that you can read through what happened. But what really makes the experience that much more compelling is that you can click on an event in the IntelliTrace window and navigate to the source code that caused that event, shown here.

In the next blog, I'll describe how you can customize IntelliTrace to collect additional events such as opening a file or reading from Windows registry keys.

Habib Heydarian.

Visual Studio 2010 Beta 2: The Historical Debugger is now IntelliTrace!

Over the last few months, I've blogged a fair amount about a new feature in Visual Studio 2010 called the Historical Debugger. With the announcement of Visual Studio 2010 Beta 2 also comes a name change for the Historical Debugger. It is now called IntelliTrace™.

Background: We literally spent over two years agonizing over the name for the Historical Debugger. In fact, the team made a list of over 100 candidate names. After much debate, some tears and lots of back and forth, we settled on the name IntelliTrace. So far, many people have told us that they much prefer the name IntelliTrace over Historical Debugger.

Despite the name change, much of the functionality of IntelliTrace remains the same as I had described before. For a refresher, here are a set of blogs that will get you started on IntelliTrace.

• An in depth look at the Historical Debugger in Visual Studio 2010 (Part I)
• An in depth look at the Historical Debugger in Visual Studio 2010 (Part II)
• An in depth look at the Historical Debugger in Visual Studio 2010 (Part III)
• An in depth look at the Historical Debugger in Visual Studio 2010 (Part IV)
• An in depth look at the Historical Debugger in Visual Studio 2010 (Part V)
• Debugging LINQ to SQL queries using the Historical Debugger
• The anatomy of the Historical Debugger Navigation Bar (Navbar)
• How to debug an exception with the Visual Studio 2010 Historical Debugger

In the coming weeks and months, I'll be writing a lot about IntelliTrace and how you can use it to make debugging much more productive.

Habib Heydarian.

How to edit code when debugging a 64-bit application

One of the most popular features in the Visual Studio debugger is the ability to edit code during a debug session and have the changes apply without having to stop the debugger, recompile the application and then run the application to verify the changes. This feature is affectionately known as "Edit and Continue" or "E&C" for short.

Unfortunately, Edit and Continue isn't supported on 64-bit. In fact, if you try to use Edit & Continue when debugging a 64-bit application, you get the following error message: "Changes to 64-bit applications are not allowed", as shown below.

Many users may not be aware that by default, when you create a C# or VB project in Visual Studio 2008, the "Platform" for the project is set to "Any CPU". This means that if you run your application on a 32-bit operating system, your application will run as a 32-bit process and similarly, if you run your application on a 64-bit operating system, the application will be 64-bit. The consequence of "Any CPU" is that when you try to debug your application on a 64-bit operating system, you won't be able to use the Edit and Continue feature.

However, there is a workaround. During development, you can set the Platform for your project to 32-bit which means that your application will run as a 32-bit process even on a 64-bit operating system. This is known as WOW64 or "Windows On Windows" which basically means that you can run a 32-bit application on a 64-bit operating system.

So, how do you set the Platform for your project to 32-bit? Well, you need to create a 32-bit platform using the Visual Studio Configuration Manager. Here is a short walkthrough.

First, open the "Configuration Manager" dialog from Build –> Configuration Manager. The Configuration Manager dialog is shown below.

On the Configuration Manager dialog, select "New..." from the "Active solution platform" dropdown, as shown here.

On the "New Solution Platform" dialog, select "x86" and press the OK button.

That's it! Your project is now compiled as a 32-bit application and therefore, it also runs as a 32-bit process.

An important note to remember is that if you are planning to deploy your application to a 64-bit machine and you want the application to run as a 64-bit process, don't forget to set the project platform back to "Any CPU" and compile the project.

Habib Heydarian.

RUNTIME turns 100,000!

Today represents a huge personal milestone. My car reached a 100,000 miles! There is nothing unique or special about my car except the license plate and the Visual Studio logo on the hood. Most of my friends refer to the car as RUNTIME (for obvious reasons).

I purchased it when I first joined Microsoft from my first manager and have had it since then. It's a great little utility truck.

Habib Heydarian.

Debugging a COM object (Runtime Callable Wrapper) with Visual Studio 2010

If you have written managed code that uses a COM object, then you are probably familiar with System.__ComObject. When a COM object lacks a Runtime Callable Wrapper (RCW), the CLR provides a generic RCW which is an instance of the type "System.__ComObject". Unfortunately, one of the downsides to System.__ComObject is that the Visual Studio 2008 debugger cannot display its members.

Let's look at an example. When I was writing this blog post, I wrote a tiny console application that would speak the word "Hello" using the Microsoft Speech Object Library (SpeechLib) which is a COM API.

   1: using SpeechLib;

   2:  

   3: class Sample

   4: {

   5:     static void Main()

   6:     {

   7:         SpVoice spVoice = new SpVoice();

   8:         spVoice.Speak("Hello", SpeechVoiceSpeakFlags.SVSFDefault);

   9:     }

  10: }

Unfortunately, as soon as I ran the application, the application threw a COMException with the HRESULT 0x8004503A, as shown below.

Since I didn't know what the problem was, I added the variable "spVoice" to the Watch window to have a closer look. However, the debugger couldn't show me anything since I didn't have a RCW for SpeechLib and hence the CLR had generated a generic one at runtime. So, I'm somewhat stuck at this point.

Luckily, in Visual Studio 2010, there is now a "Dynamic View" that displays all the members of a COM object of type System.__ComObject, as shown below.

Expanding the "Dynamic View" node displays the members of spVoice. As can be seen from the screenshot below, the reason for the exception was because the audio service on my computer wasn't running. This makes sense since I was running this demo on the Hyper-V virtual machine.

Habib Heydarian.

Coverage of the Visual Studio 2010 Historical Debugger

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.

• An in depth look at the Historical Debugger in Visual Studio 2010 (Part I)
• An in depth look at the Historical Debugger in Visual Studio 2010 (Part II)
• An in depth look at the Historical Debugger in Visual Studio 2010 (Part III)
• An in depth look at the Historical Debugger in Visual Studio 2010 (Part IV)
• An in depth look at the Historical Debugger in Visual Studio 2010 (Part V)
• Debugging LINQ to SQL queries using the Historical Debugger
• The anatomy of the Historical Debugger Navigation Bar (Navbar)
• How to debug an exception with the Visual Studio 2010 Historical Debugger

Habib Heydarian.

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

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.

Class Breakpoint: How to set a breakpoint on a C++ class in the Visual Studio Debugger

When debugging an application, there are times when you want the debugger to stop whenever any of the functions in a particular class are called. An example of this may be when you are trying to find out which object is calling your class. Of course, you could manually set a breakpoint on every function in your class but that is both tedious and time consuming, not to mention error prone (what if you miss one of the functions?)

What you really want is a "class breakpoint", that is, a breakpoint on an entire class and all its functions, operators, constructors, etc. In Visual Studio, you can set a "class breakpoint" using a function breakpoint. Specifically, when setting a function breakpoint, instead of specifying a function name, you can specify the name of the class followed by the '*' wildcard character. The '*' wildcard indicates to the debugger to break on "anything" that is called within the class.

Let's go through an example. In the following class declaration, I want to set a breakpoint on all methods in the Stack class.

class Stack
{
private:
    list<int> m_list;
public:
    void push(int i);
    int pop();
    int depth() const;
    bool empty() const;
};

To do that, I can bring up the "New Breakpoint" dialog by pressing CTRL+B as shown below and type in Stack::* for the function name, as shown below.

After setting the breakpoint, the Breakpoints window displays the new breakpoint just like any other breakpoint, as shown below.

As soon as any of the functions in the Stack class are called, the debugger will stop at the function. Also, the Breakpoints window will show the fact that multiple breakpoints were set in the class. In the following screenshot, the function push() was called and the debugger stopped since there was a class breakpoint on the Stack class.

Habib Heydarian.