Visual Studio debugger tips & tricks (for C/C++ projects)

Question

I\'m interested in tips and tricks regarding debugging a C/C++ project in Visual Studio\'s debugger. I recently found out that if you have a pointer to a certain data type, let\

Answer 1

SaraFord's blog is brilliant for visual studio hints and tips - Sara Ford's Weblog

Answer 2

Some other tips&tricks I found in this article:

ptr,su -> display ptr as if it was a string of unicode chars.
val,hr -> view val as a hresult data
val,wc -> view val as a window class
val,wm -> view val as a window message

Answer 3

I really like the possibility to tweak the Debugger display of types and structures through AutoExp.dat. The file is located at

..\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\autoexp.dat

and allows to define own templates for the display of data during debugging:

While debugging, Data Tips and items in the Watch and Variable windows are automatically expanded to show their most important elements. The expansion follows the format given by the rules in this file. You can add rules for your types or change the predefined rules.

The file is full of good examples and you can easily adapt certain templates to your own needs or add new ones for your own classes.

Answer 4

• Some debugging / watch related tips:

  Use the following in the Watch window to find out what GetLastError() would return:

  @ERR,hr

• If you use Visual Studio 2003 or earlier, use this watch expression to find out the length of your std::vector v:

  v._Mylast-v._Myfirst

  You can also list the e.g. first 5 entries with this expression:

  v._Myfirst,5

  This doesn't work when using STLport, and the method obsoleted in VS >= 2005 with the new expression visualizers.

• If you want to see the return value of a function, look at the eax register (just enter eax in the watch window). You can even change the returned value. If it's a pointer to a string or array, you can also enter eax in the Memory window to see the underlying string.

Answer 5

Some people don't actually realize that you can change the variable values and move the execution point. This is very useful if you hit a breakpoint after a line of code that is of interest to you, and you want to try it again with different values.

Answer 6

Probably the most important tip you can use is DebugBreak. Put DebugBreak() in your code, and when it executes it's like hitting a break point.

The real nice thing is that you can then put conditionals on it that might ber hard to set on a regular breakpoint. Learn to use this!

For example, your program is crashing when it digests a certain data file. You discover that it crashes in a certain function, but only after it's called a million times+. You also have figured out that it is crashing because a certain variable call it x has the value 1001, but x is supposed to be between 0 and 1000. So instead of hoping to luckily catch the place where x becomes to big, you find every place that x changes. Right after that you put the statement: if(x>1000) DebugBreak();

Yes you can do this with conditional breakpoints, but I've seen a program that takes 1 second to execute slow down to 15 minutes with three coniditional breakpoints, but execute in 1.5 seconds with the DebugBreak.

Having said that here are a couple of useful suggestions. Mathematically prove to yourself that the reason you think a bug is happening accounts for the actual bug happening at least part of the time ( not likely to have two bugs create the same problem, but it happens ). I've seen some of the most stupid fixes put in place because people "feel" that's the reson for the bug. Make sure your logic is as sound as any proof in a geometry class.

The second suggestion if you put in an experimental fix, and it doesn't do anything. Take it out.