Habib Heydarian's Blog @ Microsoft : Debugging

One bug, two developers: Collaborative debugging is now a reality in Visual Studio 2010

habibh — Wed, 02 Dec 2009 00:51:08 GMT

Quite often, one or more developers need to collaborate on a bug to figure out the root cause of the problem. This collaboration is typically done using tools like email, bug tracking system (e.g. TFS) or if the developers are collocated, they might work on the bug together in one of their offices. Here is what the typical workflow looks like:

In the workflow above, when Developer 1 hands the bug over to Developer 2, there is a lot of context and information that is left out and what usually happens is that Developer 2 restarts debugging the same issue to figure out the root cause. Basically, Developer 2 ends up doing a lot of redundant work that Developer 1 has already done. Ideally, Developer 2 should be able to leverage the investigation work that was done by Developer 1 and just continue the debugging session.

In Visual Studio 2010, using two new features , i.e. Breakpoint Import/Export and DataTips Import/Export allows Developer 1 to hand off the debugging session to Developer 2 so that Developer 2 can just pick up where Developer 1 left off.

Let's go through an example to see how this collaboration works. In this example, Developer 1 is investigating a bug in the Tailspin Toys e-commerce sample application. He is trying to figure out why the Shopping Cart isn't updated when the user adds the same toy to the cart. After debugging the problem in Visual Studio, Developer 1 discovers that the bug is in a method (AdjustQuantity) that is in a component (Tailspin.Model) owned by Developer 2. The screenshot below shows where Developer 1 thinks the bug is.

At this point, Developer 1 wants to give this bug to Developer 2. However, rather than have Developer 2 do all the work to reproduce the bug, Developer 1 captures a couple of crucial pieces of information and sends them along with the bug to Developer 2. In a sense, Developer shares his debugging environment with Developer 2. First, Developer 1 exports his current breakpoint by right-clicking on the breakpoint in the editor and selecting the "Export…" command, as shown below. By exporting the breakpoint, Developer 2 can now easily figure out where to start investigating the bug.

The exported breakpoint file is shown below.

The next piece of information that Developer 1 wants to share with Developer 2 is what information Developer 2 should look at when debugging the problem. In order to do that, Developer 1 first "pins" the variable that he thinks is causing the bug to the editor, as shown below.

After pinning the variable to the editor, Developer 1 exports the pinned variable, by selecting the Debug –> Export DataTips… command. The exported DataTips file is shown below.

Now, instead of Developer 2 restarting the investigation, he can continue where Developer 1 left off by importing the debugging environment. The new workflow is shown below.

To import the debugging environment, Developer 2 can import the DataTips file from Debug –> Import DataTips. The exported breakpoints can be imported from the Breakpoints window, as shown below.

After importing both the breakpoint and the DataTips, Developer 2 can simply continue his investigation by pressing F5. The debugger will now stop at the breakpoint that Developer 1 exported and will show the variable as well. It will even show the comment that Developer 1 wanted to pass onto Developer 2. This is shown below.

If you have any feedback or suggestions on this feature or have any ideas on how to better collaborate when debugging, feel free to leave me a comment.

Habib Heydarian.

Looking for questions or feedback on IntelliTrace

habibh — Tue, 27 Oct 2009 05:23:05 GMT

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

habibh — Sat, 24 Oct 2009 04:30:00 GMT

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.

How to edit code when debugging a 64-bit application

habibh — Tue, 13 Oct 2009 05:19:55 GMT

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.

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

habibh — Tue, 22 Sep 2009 10:31:00 GMT

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.

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

habibh — Thu, 10 Sep 2009 21:34:00 GMT

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.

Troubleshooting common breakpoint problems in the Visual Studio debugger (Part I)

habibh — Wed, 02 Sep 2009 03:41:00 GMT

On the Visual Studio debugger team, one of the areas where we regularly receive feedback is when breakpoints don't work. Furthermore, some of the error messages that the debugger displays when a breakpoint fails are generic so it might be hard to diagnose why a breakpoint doesn't work correctly (we're working to improve these error messages). In this blog post and subsequent posts, I'm going to cover the most common reasons why breakpoints don't work in the Visual Studio debugger and provide potential workarounds.

Problem

When trying to set a breakpoint in a C# or VB method, you see the following error message:

The common language runtime was unable to set the breakpoint.

Description

This error occurs because the application that you are debugging is optimized and the method where you are trying to set the breakpoint has been optimized away and hence, doesn't exist in the running application. This typically happens if your project configuration is set to Release mode which enables the compiler setting to optimize code, as shown below. One way to fix this problem is to set the project configuration to Debug which disables optimizations.

Habib Heydarian.

How to debug a 64-bit dump using the Visual Studio debugger

habibh — Tue, 01 Sep 2009 04:48:00 GMT

One of the questions that comes up about debugging dump files is how to debug a dump file that was created from a 64-bit process. The reason why this question comes up is because Visual Studio itself is a 32-bit application and therefore, cannot debug a 64-bit dump file (or process). As a result, the first time that a developer tries to debug a 64-bit dump file, he (or she) typically runs across the following error message:

The 32-bit version of Visual Studio cannot debug 64-bit processes or 64-bit dumps. Please remote debug with the 64-bit version of Visual Studio Remote Debugging Monitor (MSVSMON.exe) instead.

To fix this problem, before you start debugging the dump file, run the 64-bit version of msvsmon.exe from %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x64. However, even after doing so, you might see the following error message:

The version of this file is not compatible with the version of Windows you're running. Check you computer's system information to see whether you need an x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher.

Unfortunately, this error is rather confusing and doesn't tell you anything about the root cause. The problem here is that you are running a 32-bit operating system and therefore, cannot run a 64-bit process. Hence, you need a 64-bit operating system to run the 64-bit version of msvsmon.exe.

To summarize, in order to debug a 64-bit dump in the Visual Studio debugger, the following conditions need to be met:

You need a 64-bit version of Windows
You need to run the 64-bit version of msvsmon.exe first

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.

Debugging 101: How to skip over code in the Visual Studio Debugger

habibh — Thu, 30 Jul 2009 10:37:00 GMT

One of the questions that comes up regularly on newsgroups is "How do I skip over a section of my code in the Visual Studio debugger?" The answer depends on the meaning of the word "skip" but in general, there are three ways that you can skip over a section of code in the debugger. I'll describe these three techniques using the following code sample.

        1: public bool DecrementUnitsInStock(int quantity)

       2: {

       3:    bool success = Product.DecrementProductUnitsInStock(this.ID, quantity);

       4:    if (success)

       5:       this.UnitsInStock -= quantity;

       6:    return success;

       7: }

Step Over (F10)

Step Over (F10) is by far the most well known command for skipping over an entire method but still execute the function that you are stepping over. When you Step Over a line, it executes all method calls that are on that line (including methods that take other methods as their argument) and stop on the next line. However, if any of the methods that you are stepping over contain a breakpoint or throw an exception, the debugger will stop in the method.

In the screenshot below, pressing F10 will execute the DecrementProductUnitInStock() method without tracing through it and will stop at the next line.

Run To Cursor (CTRL+F10)

Think of Run To Cursor as an "invisible one-shot breakpoint". What does that mean exactly? It means that just like a breakpoint, the debugger will execute your application up to where your cursor is and break. In the following example, I placed my cursor on the line "return success" and pressed CTRL+F10. The debugger ran all the code up to (but excluding) the line "return success" and stopped.

Run To Cursor is very useful when it comes to skipping over parts of a function that you don't want to step through. For example, if you have a loop in your method and you don't want to step through the loop, set your cursor just after the loop and select Run To Cursor (CTRL+F10).

Set Next Statement (CTRL+SHIFT+F10)

Set Next Statement is a powerful debugging feature for controlling application execution, granted that it's used correctly. If used incorrectly, it can lead to all sorts of weird and wonderful behavior in your application. In a nutshell, Set Next Statement allows you to jump around in a method without executing any code in between. In the code segment below, I moved the yellow arrow to the "return success" line which means that I skipped the execution of the if statement.

Set Next Statement is frequently used in conjunction with edit and continue. That is, after changing some code during the debug session, you can set the next statement to the location before the change and re-execute the code to see the affect of your changes.

Also, instead of using the shortcut CTRL+SHIFT+F10, you can drag the yellow arrow to the location in your code that you want to execute.

If you use other techniques to skip over code in the debugger, feel free to leave a comment.

Habib Heydarian.

Quick Tip: How to move a breakpoint in the Visual Studio debugger

habibh — Wed, 29 Jul 2009 04:38:18 GMT

Setting a breakpoint in the Visual Studio debugger is as simple as placing your cursor on a line of code and pressing F9. However, once you've set the breakpoint, how do you move it to a different location since clicking on the breakpoint will delete it? One workaround is to delete the breakpoint and set a new breakpoint at the new location. The problem is, if you have set a bunch of options on the breakpoint, e.g. a condition, then those options will get lost in the move.

The trick to moving a breakpoint is to use the Breakpoint Location option to change the line number of the breakpoint. You can access the Location option by right-clicking on the breakpoint the you want to move and selecting "Location...", as shown below.

On the File Breakpoint dialog, simply change the Line field to the new location and press [OK]. The breakpoint will move to the new location.

Habib Heydarian.

Walkthrough: Debug a WPF window or Windows Form without running your application [Video]

habibh — Fri, 17 Jul 2009 10:52:00 GMT

Most Windows GUI applications share a common trait. They all have multiple forms and/or dialogs. In the screenshot below, this simple application alone has four WPF windows.

If I want to debug the main window, that's easy. I just press F5 and the main window or form starts up. However, if I want to debug one of windows or dialogs that are displayed as a result of clicking a button in my application, it requires me to i) start my main application and ii) click through various windows and dialogs until I get to the window that I'm interested in.

This is both tedious and can be time consuming. There is a much easier way to debug a window or form, without having to start the debugger and clicking through the application.

Watch the video below for a walkthrough.

This feature is available for both C# and VB. Feel free to drop me a line if you are using this feature today.

Habib Heydarian.

Mixed Mode Debugging for 64-bit Applications

habibh — Wed, 15 Jul 2009 17:24:00 GMT

In Visual Studio 2008 and earlier releases, one of the key complaints is that the debugger doesn't allow you to debug 64-bit mixed mode (managed and native) applications. In fact, if you try to debug a 64-bit mixed mode application, you will see an error that is similar to the following.

---------------------------
Microsoft Visual Studio
---------------------------
Error while trying to run project: Unable to start program '<application_path>'.

The debugger does not support debugging managed and native code at the same time on this platform.
---------------------------
OK
---------------------------

The only workaround is to debug the managed portion of the application using the managed debugger and similarly, debug the native portion using the native debugger.

In Visual Studio 2010, we have removed this restriction such that you can use the Mixed Mode debugger for 64-bit applications. Hence, you will no longer see the above error message.

Habib Heydarian.

Debugging LINQ to SQL queries using the Historical Debugger

habibh — Wed, 15 Jul 2009 00:04:00 GMT

I've covered the Visual Studio 2010 Historical Debugger extensively in a few of the previous posts. In this post, I'll cover how the Historical Debugger makes debugging LINQ to SQL queries a lot more convenient.

If you are trying to debug a LINQ to SQL query, often it helps to look at the generated T-SQL code to get an understanding of what the query is trying to do. In the following example, I have a very simple query expression that returns a list of customers, ordered by their CustomerID.

Dim q =
    From c In db.Customers _
    Order By c.CustomerID _
    Select c

Using the Historical Debugger, it's super easy to see what the underlying T-SQL query looks like. That's because the Historical Debugger records queries made to the database, as seen below.

To see the generated T-SQL query, you can use the Autos window, as shown below.

Once you click the Visualizer button in the Autos window, you can see the entire T-SQL statement that is generated by the LINQ to SQL query expression.

Habib Heydarian.

Fun with Breakpoints in the Visual Studio Debugger

habibh — Mon, 13 Jul 2009 15:15:19 GMT

Once in a while, I come across a feature in the debugger where I ask myself: "I wonder if anyone knows about this feature!"

Yesterday, I came across just such a feature: Did you know that the debugger can play a sound when a breakpoint is triggered? Watch this short video and then continue reading to learn more.

You can configure Visual Studio to play a sound when a breakpoint is triggered via Windows Sounds, as shown below.

I can think of three scenarios where developers would use this feature:

Developers who are visually impaired can use breakpoint sounds to know when a breakpoint is triggered
A developer might have a scenario where it takes a long time to get to the point where the breakpoint is triggered. By binding a sound to the breakpoint, the developer can run the debugger and switch to other tasks. Once the breakpoint is triggered, the developer hears the sound and starts debugging the application.
Some people just like customizing their applications. Take Outlook for example. I have run across numerous people who have changed the default sound for email notifications for Outlook. Why not customize breakpoints?

In the video above, I used Homer Simpson’s classic "Doh!" as the sound for when the breakpoint is hit, but ultimately, I couldn't decide what would be the perfect sound for when a breakpoint is triggered. What do you think? If you have any suggestions as to what sound a breakpoint should play, please leave your feedback. Also, let me know of other scenarios where breakpoint sounds would be useful.

Habib Heydarian.