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's say char* ptr, then you can see it as an array in the watch window using a syntax such as:
ptr,10
This will display the first 10 elements from the ptr address, in the same way as it would be displayed if the definition would be:
char ptr[10];
What other tips and tricks do you know about Visual Studio debugger?
PS: I hope this subject wasn't already discussed. Should you find a similar post, please let me know.
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.
You can set the names of your threads using a somewhat awkward piece of code. See this article at MSDN.
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.
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
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.
SaraFord's blog is brilliant for visual studio hints and tips -
Sara Ford's Weblog
