Debugger Usage


The newsgroups give us a good idea of which debugger features are causing the most problems for our users, but it is more difficult to gauge which features our users are using the most. I am guessing Breakpoints/Watch would probably be the at the top, with Modules being one of the less frequently used. I would be interested to know from some of the users here which features they use the most. This is again an ad-hoc sampling, but if you are posting here I bet you are a power user…


How frequently do you find yourself looking at the callstack? Using the command/immediate window? The processes window?


Comments (20)

  1. Ron J says:

    I use a debugger daily.

    How frequently do you find yourself looking at the callstack?

    5%

    Using the command/immediate window?

    50%

    Breakpoints

    99%

    The processes window?

    Almost never

    Watchpoints (almost never)

    Main usage is running the code to a breakpoint and then stepping through the code to see where catch statements occur. Then use the command window to look at variable values.

    I probably in the minority…

    My collegues use it much different than I.

    Hope this helps.

  2. I use pretty much only the locals/autos window, immediate window, and breakpoints.

  3. Simon T says:

    I tend to use the Watch window and breakpoints the most, I used to use the command window a lot in vb6 but find it almost never works in c#, so I gave up with it.

    (When I say never works, I would try and do an assignment to a var to send the code another route, that rarely works, even when I "? variable" chances of it displaying a value without erroring are remote, (twas same on vs.net as well as 2k3 version) My colleagues wonder what the hell I have done as they seem to work, wish I knew).

  4. JasonM says:

    Callstack: 25%

    Immediate: 50%

    Processes: Never

    Breakpoints: Constantly!

  5. Les Whalley says:

    I’ve only managed to get the debugger working by manually attaching each time.

    Call Stack Never

    Immediate 30%

    Processes Rarely

    Breakpoints 80%

    Watch 50%

  6. Eric Wilson says:

    I find that I use the callstack window quite often (mostly to try and figure out how the heck I got to a certain place in the code :).

    After that, I probably use the command window more than anything else (It would be even high if it worked with COM interop properties at all).

  7. Initialy I use the breakpoint to get me to somewhere thats broken. Then I use the immediate window to query values.

    I find the immediate window is not as good as it was in vb. The watch window is almost useless.

    in VB I used to sue the immediate window to see what properties were available, becuse of the intelisense. This seems to only work ‘sometimes’ in C#.

    I’d love to have more prompts in the immediate window with intelisense to tell me what I can and cannot see.

  8. Hoo boy! These are some very interesting posts, I should have replied earlier but yesterday & today have been one of those days… can you believe 4 hours of meetings today?

    I am really surprised that so many people use the command/immediate window so frequently. I would have expected watch/locals to be overwhelmingly more popular than the comamnd window.

    I also see a few complaints & suggestions. I will try out each of these complaints over the weekend and see if these are issues we overlooked and need to fix. There is also a comment from Les that his debugger works only with attach and I have no idea how/why that should be. You would expect a simple F5 to work. Is this a problem with just one projet or each and every one of them, Les?

    Thanks & regards.

    Deeptanshu.

  9. Joe says:

    Callstack: Only when an unhandled exception occurs, then it’s a lifesaver.

    Command/Immediate: Almost never

    Processes: Occasionally

    Watch/Locals/Autos: Always

    Breakpoints: Always

  10. Hi Anonymous,

    Try this link for instructions – http://www.code101.com/Code101/DisplayArticle.aspx?cid=48

    Cheerio,

    D.V.

  11. Chui Tey says:

    Breakpoints: always

    Call stack: almost always.

    Watch: In vb6 break when expression becomes true is great

    It would be a real killer if these features are around:

    a) break when call stack is identical (useful when function is called from different parts of a program)

    b) slow motion replay of events before a particular exception.

  12. Deeptanshu says:

    Hi Chui,

    These are interesting ideas, but the issue is (a) customer need (b) expense.

    You are the first person to ask for break on stack. This will be a very expensive operation because the debugger will need to keep evaluating and comparing the stack after every function call all in run mode.

    For your case of exceptions, you should be able to trace the execution simply by looking at the callstack.

    For a general replay of events – this is very difficult because there will be a significant perf hit to store states & actions of the debugger while running the app and then going back and tracing the executed steps leading to the error. Some screen-recording tools have been made by other companies, but this has not been a very necessary & widely demanded feature, though I do understand that sometimes you really wish you knew what happened 3 minutes ago. Typically timing issues can be tracked much more easily by adding logging to your program and seeing which state was unexpected.

    Regards,

    D.V.

  13. fryguybob says:

    I use breakpoints, Watch Window, and Call Stack.

    What I would really like is the ability to change the font in the watch window. It really bothers me to look at code in anything but a fixed width font. It takes me much longer to identify what I’m looking at because of this.

    Another thing that annoy’s me is that there doesn’t seem to be a good way in the watch window to look at long formated strings (such as the OuterXml property of a XmlDocument).

  14. Deeptanshu Verma says:

    Regarding font in watch window => you can change the font from Tools->Options->Environment->Fonts & Colours : set the font for the group "Dialogs & Tool Windows". There is no font setting for the watch window exclusively.

    You should be able to view long strings via tooltips in the watch window. We have improved the string viewing in the new version which should prove to be more convenient than tooltips.

    Regards,

    D.V.

  15. Eric Newton says:

    Command/Immediate: a LOT, please fix it so that assignments can be made since theres no EnC! ie, theres times when assignment statements refuse to work in both the Immediate and in the Watch windows, and even to simple properties that just directly wrap a private field.

    Call stack: sometimes, when I dont have a clue why i’m at a certain spot: i wish an "expanding view" or something could be considered to show what the simple types’ values were passed in

    Watch: somewhat, but i dont like properties of objects being "run" even though I try to subscribe to the idea of "property access should never change object state" this idea doesnt work well in O/R mapping schemes

  16. Andy Sujdak says:

    Call stack 90%

    Can you guys make a window where it prints a list of all of the functions that have been called in the current debug run? It would be really helpful to be able to see which events are being raised as I step through forms code, and the only thing I know to do to help me here is to use call stack…

    This causes me to struggle when dealing with WinForm UI issues. Meanwhile it’s super-easy to debug my scientific algorithms. Just put it into watch & copy paste into excel to look at your vectors.

  17. Joku says:

    I have the March CTP, the IDE doesn’t seem to notice when I have breaked (c/c++) and pointing the mouse at vars with macros like

    #define G (*(Uz_Globs *)pG)

    then when pointing mouse to "sound"

    if (G.lpUserFunctions->sound != NULL)

    it doesn’t get the value.

    Can’t the preprocessor build a internal database for the debugging where is stored "what is defined where" etc, so that this information could be then used during debugging to resolve those define macros?

  18. Deeptanshu says:

    Hi Joku,

    The debugger does not recognize #defines. This is "by design" because these are preprocessor statements meant for the compiler and used during compilation. If you view the expression in watch window, you will see the Expression Evaluator does not support it, which is why datatips do not show it. These are not really variables having an assigned value, the expression is simply "replaced" by the compiler.

    Theoretically, I guess it could be possible to do something to add this info to the debug info file by treating the preprocessor directives as variables, but then you would end up with huge .pdb files. Since the values of preprocessor symbols do not change, you really don’t need the debugger to see them and can search in the source files (VS has excellent "Find in Files" support that lets you search in entire project or solution).

    Regards,

    D.V.

  19. Mahavir says:

    Please help me with the questions below :