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

7

14

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.

Karolekarolina answered 20/10, 2008 at 11:3 Comment(0)
I
8

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.

Iguana answered 20/10, 2008 at 11:25 Comment(0)
P
6

You can set the names of your threads using a somewhat awkward piece of code. See this article at MSDN.

Pyrargyrite answered 20/10, 2008 at 11:12 Comment(0)
E
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.

Empiric answered 20/10, 2008 at 12:21 Comment(1)
This is a good tip on defensive programming, but its not a tip specific to the Visual Studio debugger. You can program DebugAsserts in any enviroment.Henandchickens
M
4

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.

Mackmackay answered 20/10, 2008 at 11:19 Comment(0)
K
4

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
Karolekarolina answered 20/10, 2008 at 17:59 Comment(0)
I
3

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

Irrefragable answered 20/10, 2008 at 11:36 Comment(0)
C
3
  • 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.

Canker answered 20/10, 2008 at 12:52 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.