The Art of Debugging – A Developer’s Best Friend – Lesson 7 – Advanced Techniques – Using Object ID

Make object ID – allows you to track an object within the visual studio debugging system

When debugging native code, it’s easy to keep track of objects by their addresses.

But, with managed code, you don’t really have this option. Everything is a reference in managed code. Address is simply are not relevant and managed code.

This can make it hard to tell keep track of objects.

But, when debugging in Visual Studio (at least 2005/2008), you can right click an object and select “Make Object ID”.

This will put a number like {1#} after the object.

You can do this on as many objects as you want to track.

I find this really useful in investigating a bug that involved some nasty recursion and reentrancy.

Let’s look at a demo.

Note that in the code below we have set a breakpoint. If we hover the mouse over the doc variable, data tips will popup. Next, you can right mouse click and a context menu will appear, with Make object ID as one of the options. A few Daugherty

Notice that 1# has appeared to the right.

What makes object ID particularly interesting is that you can look at objects or variables even if they are out of scope.

Essentially, object ID is making objects or variables visible throughout the execution of your application, regardless of scope.

Let’s test this.

Start by adding the doc variable as well as 1# in the watch window.

Next we will run the application and set a breakpoint where the doc variable is not in scope.

Notice that in the watch window the doc is grayed out while 1# is visible, even though the doc variable is completely out of scope.

Furthermore, notice that the 1# retains its most previous runtime value. This can be an important feature if the execution path changes based on the value of a variable or object.

The bottom line is that you can observe your variable or object as it moves through the system.

Imagine a scenario where you have an array of objects that all exercise the same methods. But you want to break only when a specific object invokes a method.


Download the source for Array of Cars

Start by setting a breakpoint on the for each loop.

Start the debugger and run the application until it hits the for each loop. Once you hit the breakpoint at the fort each loop you can assign an object ID to one of the car objects.

Notice that I am right mouse clicking on the second array element of cars. I am making an object ID out of the convertible car object.

Notice that 1# has been assigned to the convertible car.

Now we can go to the car class and set a breakpoint within the method called DescribeCar(). Once you have set the breakpoint, right mouse click on it and select condition.

Notice that the condition sets the this object to the newly generated object ID of 1#.

This means that the breakpoint will only be hit when the invoking object of the DescribeCar() method is a convertible car.


Notice the + within the breakpoint indicates that this is a conditional breakpoint.


From the menu select debug| continue at which point the breakpoint will be hit.


Notice that our conditional breakpoint functioned correctly.

Notice the invoking object is in fact the convertible car.

This is a very powerful technique in situations where you have large numbers of objects and you want to break on method calls for only one specific instance


Comments (4)

  1. Link Listing – February 9, 2009

  2. ASP.NET Thoughts on AJAX Preview 4 and JSINQ [Via: scott ] Podcasts New Spaghetti Code Podcast: VSTS…

  3. The Art of Debugging – A Developer’s Best Friend (Bruno Terkaly) Intro – Lesson 1 Lesson 2 – Breakpoints