Wanted: Debugger User Interface Feedback

In the past, we have relied on internal dogfooding, external alphas and betas, and usability studies of work-in-progress to get feedback that can be used to improve the feature before being released to the public.  We are still doing that more than ever.  However, blogging has opened up a new channel of feedback that I’d like to take advantage of. 

As you may or may not know, I am a developer for the Visual Studio debugger, with a strong emphasis on the user-interface the debugger presents.   That being the case, I am keenly interested in hearing about what you love about the debugger, what you hate about it, and/or ways you think it can be improved or changed to better meet your debugging needs. As posts are made, I will not only note the feedback and try to address it in future versions, but I (and others who read this) will be sure to post guidance and/or tips to help address your needs with existing versions of the product.

To get you started thinking about it, I’ll pose a few questions:

  • Which form of variable inspection do you find yourself making the most use of?  Datatips?  the Watch Window(s), the Autos Window?, the Locals Window?  Why?
  • How do you set and unset a breakpoint?
  • What feature are we completely missing?

And here are a few usability tips:

  • Did you know you can edit many values in the watch, locals, or autos window?  Just click on the item, then click on it’s value.  If the value can be edited, it will become editable.
  • Did you know you can drag a deeply nested watch, local or autos, item to a top level of the watch item?
  • Did you know you can view more than the first item in a C++ array, by appending your watch item with “,#“ where the number is replaced by the number of items you want to view?  For example, if you have a pointer to an array of ints, called “pArray“, you can view the first 10 items with “pArray,10“

While your at it, also be sure to check out some of the other blogs here that address our debugger, including: http://blogs.msdn.com/stevejs and http://blogs.msdn.com/greggm.


Comments (30)

  1. Jói says:

    A couple of improvements that I would really love to see are:

    1) Being able to look up symbols from the debugging information for a module (similar to what is possible in WinDbg e.g. ‘x mymodule!SymbolName) and set breakpoints on symbols.

    2) Being able to debug child processes as well as just the process launched

    Thanks for a great debugging environment!

  2. zz says:

    Currently, I am mostly a C++ programmer. I mostly wish for easier ways to debug the sometimes overwhelming amount of data I need to look at. So, you ask for it, here it is:

    1. Breakpoint groups

    – allow multiple breakpoints to set & unset as a unit. I like to set a lot breakpoints but they eventually become hard to manage.

    2. Dependent breakpoints

    – Allow breakpoint(s) to be active only if the debugger stopped (or not stopped) at "parent" breakpoint. This great stituations when a function is called many times and you only step into it another breakpoint was stopped at. Basically to chain breakpoints together.

    3. Copy & Paste

    – Currently it is very hard to copy a value from the watch window. For example, if I try to copy the value of char*, I get the pointer instead of the string value (C++)

    4. Visualizers for large string values

    – I think the debugger is only displaying strings up to 256. Hopefully, the new visualizer system to allow to view large strings and also fix point #3 but will it be supported in VC++

    5. Breakpoint <-> Bookmark

    – Easily convert a breakpoint to a bookmark and vice versa

    6. CallStack groups

    – Group callstack calls to windows functions, user code…to provide easier navigation and inspection especially with long callstacks from MFC

    7. Variable watch groups

    – Allow saving/displaying of watch variables in groups. For example, in certain context, I want to watch a certain group of variables but of course that group becomes invalid in a context. So having a variable watch groups manager would make it easier for me to look at the variables I need.

    8. Easier way for setting the breakpoint to stop at particular thread

    9. More data formats ( talking about ,# ,x ,u ,hr etc. )

    – how about format specifier for GUID or to automatically view a string pointer as a char array (stops when it sees NULL)

    10. Have Intellisense parse macros during design time

    – It doesn’t always recognize ListOfStrings:

    #define MAKELIST(TYPE, NAME) TYPE* ListOf##NAME;


    11. Allow the expansion of pointer to an enum to expand to a array in the watch window. Example:

    enum test_t


    ONE, TWO



    test_t arrOfEnum* = new test_t[10];

    arrOfEnum[0] = ONE;

    // etc.

    // in the watch, putting arrOfEnum,10 does expand it to an enum array

    12. Help visualizing linked list, trees and other structures

    – Visualizers for Linked List to allow easier navigation to data. Reference:


    13. "printf style" watch expression


    Format Names Value


    "%s is %d" szName,nYear "Tom is 8"

    Overall, hoping for a more scalable debugging experience by allowing the group of view & data. Appreciate the time and thanks for all of your hard work.

  3. Jim,

    My top three would be:

    1. A way to decide whether or not to break on exceptions based on their context (exception type + call stack). I have an add-in that does this, albeit in an unperfect way due to limitations of the automation model. Ping me via e-mail if you want to see it.

    2. Ability to find out a managed objects ID. Right now I have a tough time deciding whether two objects are the same if they are referenced in different stack frames.

    3. A graphical Watch window for visualizing data structures.


  4. Anonymous says:

    The separate debugger that pops up when using Managed C++ really annoys me. Why can’t it integrate into the IDE?

    My other wanted features have already been covered by the above posters.

  5. Ivana Mandic [MSFT] says:

    Watch window needs to be able to show intellisense for type members.

    If I type someObj. it should popup a list of all available members I can watch.

  6. Niall says:

    I would like the breakpoint groups as well.

    There are a few things that annoy me about the debugger:

    – Conditional breakpoints never seem to work. Maybe I’m not understanding something about them, but they never seem to work for me.

    – Trying to index things rarely works. You can’t use constants to index a lot of things (I have found this with DataRows), which often means you can’t copy the code out of the code window and just dump it in the watch window. The error you get "xyz doesn’t have an indexer" is wrong (because it does), and therefore doesn’t help you to understand what you’re doing incorrectly.

  7. theCoach says:

    I would second the request for a graphical view of the data. I think this could be a fascinating tool, and would really help developers understand their programs. My vision for it is as an object map on top of physical or logical memory, with the ability to zoom in on more detail (obviously, I have not given this the time to come up with a realistic vision), but something that graphically demonstrated the memory and objects, as well as the ability to view transitions and to drill down to the appropriate level or view.

  8. Ivonna Vackoff [MSFT] says:

    Graphica view of the data in the debugger?

    So what do you want, dancing girls maybe a disco globe?

  9. Oooh. A disco globe? I want one.

  10. Please provide better support for conditional breakpoints. Context menu’s over items in the editor with "Break when this reaches a value…" , and settable conditional operations from the watch windows. Like an icon or context for a cell in a watch window, to be able to do: "when the contents of this hits 10, break".

    I can’t believe conditional breakpoints dont work, but like a previous comment brought up, they’re tricky to make work, but I suspect very handy. Mine never seem to work either.

  11. Angry Joe says:

    How about making debugging ASP.Net applications actually WORK without having to go through a day long ordeal EVERY time you build a machine?

  12. Philip Rieck says:

    Hmm. This may be a bit much of a request, but how about being able to view the IL and step through that?

    From a user-interface perspective, I’d like to be able to "disable" watch items. Putting certain items on the watch list can cause severe slowdown. What would be neat is the ability to check/uncheck items so that the debugger doesn’t evaluate them unless you want to. Currently I do this with Watch1-3, but when I’m in lots of different code, I’ll use those to organize by module instead.

  13. Julie Lerman says:

    Drill into ado.net objects like we could do in VB6 with recordsets, etc. please please please please :-)Hmm, that’s not really a UI thing though is it…

  14. zz says:

    One thing I want to is to define macros in watch windows. For example:

    Name Value


    $myexpr 10

    szArr[$(myexpr)] <<value of szArr[10]


    $complexexpr ((cast2*)((cast1*) pLpVoid)+)

    $(complexexpr),$(myexpr) <<array >>

    So if it is $name then it defines a macro, if $(name), means to evaluate a macro. The macros should be able to build on top of other macros. Very useful when have structures, classes or arrays that are complicated. Put this definitely have more benefits beyond that.

  15. Uri Dor says:

    My beef with the Framework right now is that it seems to throw and catch some exceptions as part of its normal execution – I’ve seen it in DataAdapter.Fill() and in XmlDocument.Load().

    So when I turn on "break when thrown", I keep getting the exceptions I don’t care about. I’d rather have an option to break in the debugger only when the exception has crossed the stack border out of the Framework and back into my app.

    Of course I don’t thing the cases I’ve seen should be exceptions at all.

    For my opinion on these exceptions:


  16. Chango V. says:

    I have no doubt the VS Debugger is simply the best in the world. Keep it up!

    I do mostly C++ work, and I delight in debugging. Overall, the VS debugger serves me quite well. Here are the few things that annoy me or I find deficient:

    1. Poor inspection of STL types. It takes a lot of drilling down and sometimes tricky typecasts to get to, for example, the elements of an std::vector. Even the std::string still has problems (I guess because of its alternate internal representation – for strings shorter or longer than 8 characters..).

    2. As suggested by others, I also think some interface for visualizers of complex/custom data structures would be great, even if the actual parsing/visualization code has to be written by the developer.

    3. Inspection of properties on COM objects is such a pain, often simply impossible. For example, I can view IXMLDOMNode::nodeType but never the name property because it’s BSTR/_bstr_t and, apparently, the debugger doesn’t know how to marshal the value. I’ve created my own debug expression DLL (that plugs into autoexp.dat), but I have no clue how to make it work with COM objects.

    4. [Big thanks for the link to Andy Pennell’s WebLog, where he divulges the new NoStepInto method. With COM smart ptrs and all other classes overloaded with overloaded operators, I was developing CTS hitting F11 and Shift+F11…]

    4.1. The new ‘Step into Specific…’ feature is a great helper, but it’s somewhat awkward to use GUI-wise. I can imagine a shortcut like Ctrl key down + right-clicking on a function name within the current statement.

    4.2. I would appreciate a feature that automatically closes a (predefined) source file after stepping out of a function contained in it. Especially when you step into a function unintentionally, so many system or otherwise unwanted source files are left behind open…

    5. Bug: Every now and then, I discover that some of my open source code windows have disappeared. It seems to happen sporadically, and it always takes me by surprise, but I link it to breaking the debugged process or detaching from it. At that point random windows just seem to get closed. [v7 & 7.1]

    6. In projects that use STL (or MFC, or maybe just in general?), Edit&Continue often doesn’t work. It gives me some nonsense error about changed tagEXCEPTION type or something similar, while there are really no type or variable changes in the code.

    7. This may not be easy to do, but I feel it’s feasible, and I’d love to see it: When changing the source code while debugging, the current execution point gets out of sync with the displayed code. Can’t the debugger keep track of shifting text lines (possibly using some internal bookmarks) in the source file and still correctly show the current statement? [Without Edit&Continue working, often I’m forced to stop debugging, rebuild, and then run to the previous state, which is very wasteful.]

    8. Scrolling in Disassembly view often doesn’t work.

    9. It takes too much mouse clicking to let the debugger stop on a particular first-chance exception, see what is causing the exception, and then restore the original setting (‘use parent setting’ in the Exceptions dialog).

    10. No predefined keyboard shortcut for the Autos window (at least there’s none shown on the menu). This is the most useful debugger window.

    Thanks for listening…


  17. Ian says:

    I agree with a post above. The Watch window should be able to use Intellisense.

    It’s annoying to have to copy an item from the watch into the text editor to use Intellisense and see what member I want to add to the watch.


  18. Jim Griesmer says:

    Just wanted to post a short note to let you know that I am indeed still here and totally psyched about the great feedback I’m getting! Some of the ideas I’ve heard countless times, others are brand new ideas I hadn’t heard before.

    Once I get done with a little work item here and fix a few bugs, I will respond with much more detail!

  19. Uri says:

    Let’s imagine that my code faults on System.Data.OleDb.OleDbException; And I have a global catch clause to make the exception look pretty before showing it to the user.

    So I now know which type of exception it was, but not exactly where it came from.

    I set OleDbException to "break into the debugger" and live happily ever after. Or not, since reopening the exceptions window will give me no indication that any exception is handled in the non-default way, the "clear all" button seems to have no effect, and I’m left to drill down the whole list looking for exceptions I’ve set to "break into the debugger".

    Whatever new GUI you introduce, it should somehow show all the changes the user made to default settings…

  20. Roy Osherove says:

    Break on Watch value changes

    Another thing that’s missing for me (and others) is the ability to break in code when a value changes, but not by creating a breakpoint.

    This same functionality exists in VB6:

    Create a watch, and enter "Edit watch properties" dialog.

    There you can select the scope of the watch and can ask to break when value is true or changes.

    This does not exist in VS.Net (or am I missing something?)

  21. Michael Sparks says:

    I have to agree with zz’s comments about groups of breakpoints/watches/etc.

    This could be generalized so that I could have common "profiles" that enable certain breakpoints, exceptions, watches, etc. I could save a profile to either my user account, or to a project (similar to how you have global include directories and project-level include directories).

    Finally, I would be able to have a dockable window or drop-down toolbar button where I can see all profiles that are currently defined, and check and un-check them (some form of import/export would be good too). This way I could define a profile, say, for "low-level debugging" where I break on first-chance AV’s, show the registers window, and show disassembly.

    I’d also like to cast my vote for IL debugging (realize it’d be hard), and graphical visualizers for object graphs.

    To address your initial questions:

    I mostly use datatips if I’m stopped somewhere trying to figure out what happened, and I use watches if I’m stepping though code. A nifty feature would be to grab hold of a datatip and drop it in the watch window.

    I set/unset breakpoints with either F9 or by clicking in the margin, depending on whether my hands are on the keyboard or the mouse.

    One feature I would love (not directly related to debugging) is the ability to click in a token in the source view and then perform some keyboard combo or mouse gesture and have it automatically bold other occurrences of that keyword in view for some configured duration. A lot of times I’ll be looking at a function’s parameters and have to carefully scan the code to see where they are used. The auto-bolding that happens when you close parenthesis or curly’s would be an excellent visual cue. I’m not sure what the average opinion of mouse gestures is, but I do think that using the context menu for this would be too disruptive.

  22. zz says:

    New features in Whidbey C++, mentions briefly some things on the wish list like collection visualization in debugging:



  23. chris_s says:

    Graphical view of debugger?

    Does this mean something like:


    Some people ‘think in pictures’ so that might help there …

  24. piers says:

    The exceptions dialog should have an option to list exceptions by inheritance, not namespace. If I have a catch block that catches ‘ArgumentException’, I want to be able to change the behavior for that type and all types that derive from it (regardless of which namespace they’re in).

  25. piers says:

    – checkboxes in the watch/locals to toggle combos of fields/properties, public/private, merge inherited members/show inheritance hierarchy, statics, etc…

    – allow different sorting in the watch/locals: by declared order, alphabetically, by access, statics first, etc…

    – expandable datatips: show a ‘+’ before expandable items in datatips, allow the user to mouse over the tip and expand/contract the items. grow/shrink the tip as necessary.

    – IL debugging, or at the very least, better x86 disasembly: hyperlinks to jump dests, hover highlights jump dest, better symbols, datatips on registers/storage, indication of whether jumps will be taken.

    – get the JIT guys to sort out their line numbers: jumping around foreach blocks. exceptions not in scope at the start of catch blocks.

    – fix variables going out of scope when stepping out of the last call in a block.

  26. fryguybob says:

    I would very much like the ability (as I had in VC6) to set the font in the watch window without changing the font in every other tool window! It is very distracting to me to have identifiers in a variable width font in one window and a fixed one in my code window.

    Several other mentioned the need for a better way to view a large formated string such as the value of the OuterXml propertiy of a XmlDocument.

  27. Jim Griesmer says:

    Hey everyone! Sorry I’ve been lacking in my blogging, but we’re in the process of trying to get a beta in order and that meant some heads down getting bugs fixed, work finished, etc.

    Thanks for all the great feedback about the debugger UI. Many of the features you requested will be showing up at at a beta near you in the coming months. Others will either be considered for a future beta, or release.

    What I’ve been planning on doing is collecting and categorizing and even submitting new UI ideas based on the above feedback to all of you, but getting a good chunk of time to do that is proving to be difficult.

    So, I’m going to try and take more frequent little steps instead. I’m hoping that over time these little steps will self-organize into larger concepts and topics.

    With that, please be on the lookout for a couple new articles asking more questions or otherwise addressing many of the above posts.