Debugging with Reflector and Visual Studio

Mike Taulty recently posted about how he debugs using Visual Studio, Reflector, and SOS. I've been doing a similar style of debugging lately that I think is a bit more efficient, and here's how I do it. You may want to first take a look at what Mike's doing to put this in context.

First I use Jamie Cansdale's awesome TestDriven.NET which has the very cool Go To Reflector feature.

You can also Go To Reflector from any frame in a call stack:

One cool thing about this is that your Reflector instance stays open the whole time, and as you bounce around your call stack using Go To Reflector, the Reflector instance synchronizes to the new location that you specified using Go To Reflector.

You can also set breakpoints on code from within Reflector, which is a bit friendlier than setting breakpoints from the Disassembly window. Yes, you can set breakpoints on assemblies that you don't even have the source for.

Instead of dropping into SOS mode to look at local variables and the value of this, I simply pull up the Locals debug window. The Locals window shows values from the current stack frame as you double-click each frame in the Call Stack pane.

Sometimes the Autos window will show additional relevant variables that the Locals window doesn't and vice versa, so you may want to check both if you don't find what you're looking for.

Unfortunately I haven't found a way to get Visual Studio to do the equivalent of SOS's !dumpheap or !dumpobj for browsing and searching the heap, so you'll still need to drop down to SOS/WinDbg if you want to find all in-memory instances of particular objects or if you're analyzing a dump file. Supposedly you can load WinDbg/AdPlus dumps in Visual Studio, but I haven't gotten that to work very well with dumps of managed code. If anyone knows the secret to getting Visual Studio to analyze dumps of managed code in the same level of detail as it analyzes managed processes, I'd love to find out.

For more commentary on Mike's original goal of being able to debug the .NET Framework using its actual source code, see this post by Andrew Stopford about using Rotor to debug with source, and check out the comments regarding Deblector.