Debugger Canvas demo

This is a quick demo of Debugger Canvas, a new power tool for Visual Studio that rethinks the debugging experience. To see it in action, let’s go after a bug in this web app for buying toys.

As you can see I’ve already got one model plane in my shopping cart. When I add the plane again to the shopping cart, I expect to have two items, but I only have one. That’s the bug.

To investigate this bug, I’ll set a breakpoint in the method that adds items to the shopping cart. Let’s go back to our app and add the item again to trigger the breakpoint.

Now we’re getting our first look at Debugger Canvas. Instead of breaking in a file, Debugger Canvas creates a code bubble to focus my attention on the one method where the break occurred. As I step through the code, Debugger Canvas creates a new bubble for each method that runs.

Now I can see my whole call stack side-by-side. This makes some common tasks really easy. For example, if I’m wondering where this product parameter came from, I can glance my way up the call stack. I can see it got passed as a parameter here and here, and here’s where it originates, with this assignment. I didn’t have to click my way all over the files to find out, I could just read the code across the screen.

Each code bubble is a full-blown Visual Studio editor, with all the features you’re familiar with. For example, I can look at tool tips to see values. I can set and clear breakpoints by clicking in the margin. There are also a few handy new features. Each code bubble has button in the corner that brings up the local variables for that method. By opening these up, I can see all the objects at are in play for the whole call stack. At any point, I can also save a copy of the current values of the variables. That way, as objects change state, I can compare the new values to the old values.

There’s also a breadcrumb bar at the top of the bubble to show me where this bubble sits in my code’s structure. This method is in this class, which is in this namespace. I can click on the triangle to see this method’s siblings and quickly bring them onto the canvas.

Of course, we still haven’t found the bug. So, let me step through the code a bit more. Now that I see all the relevant code, I notice that there’s no place where any additions are happening. This parameter is supposed to represent the new amount we want in the cart, but we’re just passing the old amount. Because the bubbles are full-blown editors, I can make the fix right here.

I should probably also double check that I’m not messing up other callers of this method. As usual I do al Find All References, but now when I click on them, they show up in the canvas. I see that the only other callers are these two tests, so I’m not affecting other code. So my fix should be good.

As a last step, let me jot down a quick note about what I did. Then, I can save my canvas as an XPS file, so I can share it with my team to show them how I fixed the bug.

In the previous demo, you might be wondering how I chose where to set my breakpoint. Well, I actually started debugging by looking at an Intellitrace I generated by playing with the web app. Since bug is about posting a shopping cart request, I started with a search for post events. Then I switched over to the Call View to see what calls resulted.

Debugger Canvas make using Intellitrace even nicer. Whenever I find an interesting part of a trace, I can drag and drop a method from the trace into the canvas. Debugger Canvas then populates the whole call tree for that method. I can then use the standard Intellitrace toolbar to step my way through the call tree.

Well, that ends our quick tour. We hope you find Debugger Canvas useful, and we’d love to hear your feedback.