What's your favorite way to debug your program in Visual Studio?

Question

These day I come up with a large software.

I have to debug in Visual Studio 2008.

The steps I take are:

1. Using callstack window to find the code blocks that I i thinks it may have bugs.

2. Using Immediate windows to call some local functions to see whether the data structures in this blocks are correct.

3. When I got the result in step 2,I have to go to step 1 to find the source of the bug using callstack again.

What is your favorite method to debug large or small program in Visual Studio?

I don't think to run whole the program and watch all the related data structure is good way to debug.

Answer 1

One of my AHA-moments in VS200x-debugging was realizing that I can use "Attach to process..." in order to start debugging an executable that already is running. For large solutions, it is surprisingly often faster to launch the application in "normal" fashion and then attach Visual Studio to it, compared to starting the debugging session by pressing F5.

Answer 2

Putting breakpoints into suspicious methods and using Immediate Window is my way. I'm a huge fan of Immediate Window.

Also conditional breakpoints are the other way I like. especially when I'm iterating a collection to find an object that is suspicious. I put a condition to breakpoint and press F5 to get it.

Ctrl + Alt + Q combination is another good shortcut for Quick Watch Window to analyze an object.

Answer 3

I prefer unit tests over using the immediate window, mostly because it means I can run the code over and over again extremely simply (and indeed from a build script).

If you find the problem using the immediate window and fix it without adding any tests, you don't have anything warning you if the same problem comes back again. With a unit test, you have a constant companion to make sure that any future changes don't reintroduce the bug.

Personally I don't like having to step through code - I find it frustrating compared with unit testing. It's too easy to accidentally step over something you wanted to step into etc. It's sometimes necessary, but it's often a sign that your code is too complicated. I particularly dislike having to debug a whole application rather than just stepping through a unit test in the debugger. It's usually orders of magnitude slower.

Answer 4

My favourite way when being introduced to a large application:
- Always: "Read all the code" end to end (this is the most interesting)
- Bookmark the central parts of the code.
- Refactor & write test while debugging

Answer 5

To locate the code that corrupts a variable's value I create a data breakpoint for that variable. The program will break its execution every time the variable's data changes, either through correct code, but also through a stray pointer.

Answer 6

The important point about debugging in my opinion is to form a theory about where the bug may be. In other words try to look at the code and think about the problem before launching the debugger.

I asked a similar question, so you may want to check the answers to that as well.