Debugger Window Menu Items: Where should they be?

The VS debugger since 7.0 has put most debugger windows on the Debug menu, under the Windows sub-menu. I say 'most' because the Output window lives on the View menu, under Other Windows sub-menu.

Where do you expect debugger windows to be on the menu? (Ignore Output for now, we intend to fix that one independent of this). Your choices are:

  1. Where they have been since 7.0 (ie under Debug/Windows)
  2. Where every other window is (ie under View/Debugger Windows)?

We can't agree, so need the communities feedback.

Comments (56)
  1. Marty Garins says:

    My vote would be for option number 2 – Where every other window is.

  2. My vote is for View->Debugger Windows

    That way all views are in one place.

  3. Woody Pewitt says:

    This is one of my pet peeves this sould be and should have always have been View/Debugger Windows. Please put it where it belongs!

  4. Bjoern Graf says:

    Yes, View->Debugger Windows is the place these have to be. Even thought I used to open these windws more than once I always look in View for them first 🙂

  5. View–>Debugger … I think it’s more clear and natural.

  6. Mark Allan says:

    View -> Debugger Windows would seem more consistent.

  7. AndrewSeven says:

    How about both?

  8. Andy Pennell says:

    The Powers That Be won’t let us put the menus in both locations. We thought that was the ideal solution.

    Please keep the votes coming.

  9. B.Y. says:

    Drop this feature, real programmers use to debug.

  10. MartinJ says:

    I gotta vote for option 2. It seems more natural to find all the little tool windows in one menu.

  11. Ken Cox [MVP - ASP.NET] says:

    To me, Task List, Immediate, Command Window, Output and BreakPoint all belong together. Anyway, my choice is:

    View -> Debugger Windows

    But don’t people realize that they can move these around to suit themselves using Tools > Customize?

  12. Joe says:

    Not the question you asked, but here’s a wish for Visual Studio which seems to me to be related.

    I often have a solution which contains a server and a client app (usually using remoting). When I want to debug the client app, I want to run the server app (without debugging) then run the client app in the debugger (or vice versa to debug the server app). The only way I’ve found to do this today is to:

    – Set the Startup project to the server app

    – From the Debug menu choose "Start without debugging"

    – Set the Startup project to the client app

    – From the Debug menu choose "Start without debugging" (or use Debug from the context menu in solution explorer).

    What I’d like to see is an option "Start without debugging" in the context menu for all projects in a solution. So I could do the following:

    – Right click the Server project in Solution explorer and select "Startup without debugging"

    – Right click the Client project in Solution explorer and select "Debug".

  13. Geoff Appleby says:

    Definately option two. The debug menu should be for debug specific tasks, and only that.

  14. Joe: You can have multiple startup projects (set this in Solution Properties). That would probably solve your problem.

  15. Steve Perry says:


  16. Alexander says:

    View -> Debugger Windows and right click menu during run-time

  17. Jeff says:

    I don’t care, as long as they are all in one place.

  18. Uwe says:

    Put them somewhere NOW and ship two weeks earlier would be my choice 🙂

  19. Andrei says:

    I tend to agree with the second choice ! If it’s something that you can view, sounds logical to look for it in the "View" menu 🙂

  20. Jim Griesmer says:

    If the debug windows were duplicated, one submenu under Views->Debug and one under Debug->Windows, would you be confused?

    The "Powers That Be" claim this is the reason for no duplication.

  21. I don’t care, I use keyboard shortcuts. Please, don’t change default shortcuts a lot…

  22. Jason Ronald says:

    Option #2 seems to make the most sense.

  23. Pattern Guru says:

    It would not be confusing to have some windows in two places. The current situation is (where the heck was that specific window again…?). Please put all windows in the same place, in the right place. So great question. I think I would prefer to have all windows in one place, so that would be option 2.

  24. View/Debugger menu is my choice.

    I have two wishes also for VS

    1) Lock (Toolbars, docked Windows)

    2) Property named "Default NameSpace" in Project’s Folders that if its specified overrides the Project’s "Default NameSpace"

  25. Wayne Taylor says:

    I think the it should be number 2….


  26. Dmitriy Zaslavskiy says:


  27. AndrewSeven says:

    The PTB are confused.

    The View menu is a general menu, if people have a hard time finding the menu item to view somthing, then it should be added to this menu.

    All groups of windows such as Debug Windows should be available from View.

    The Debug menu is a specialized menu, all the common menu items for debugging should be available from this menu (such a view call stack).

  28. I’m personally in favor of 1), but 2) makes sense also.

    I do have a suggestion for

    I use floating debugger windows, all stacked on top of each other with tabs (I don’t know what this is called). I don’t dock them, because I want to move them out of the way if I need to look at my code. However, if you accidentally click the close button, all debug windows go away. To bring them back, you need to do the following:


    Debug->Windows->Call Stack




    That’s a lot of mouse clicking to undo a single errant mouse click.

    I’d LOVE a way to restore all my debug windows.

    Something like


    You could even have multiple configs, such as "minimal", "normal", "Max", "All"

  29. I think you are actually asking the wrong question.

  30. Matthew Adams says:

    Another vote for View->Debugger Windows here. Even though those windows have been on the debug menu for ages, I always look for them in the wrong place first, because learning ‘view’ for windows is somehow more primitive than ‘debug’.

    In fact, I find the debug menu as a whole difficult and time consuming to use. The fact that there are things to do with running the app with and without the debugger, the fact that it is almost always easier to use the Tools…Attach to process to attach to remote processes, because it is nearer the top of the menu, than it is to find it buried in the debug menu…

  31. Jim Griesmer says:

    I have to agree with Matthew. I am a Debugger UI dev, and I always use Tools.Attach To Process for the same reasons he mentions.

    I even accidentally looked for the debug windows under the View menu myself one night when I was working really late and I was really tired.

    So I’m all for making a change. The more responses we get in support of a change, the better.

  32. Bard Sorensen says:

    Clearly option #2 Seems logical….

  33. Leave is Debug menu! PLEEEEEEEEEAAAASE!

  34. Chango V. says:

    Please don’t move them again! I still hesitate where to look for a debugger window first. (The worst part is occasionally I need to go back to VC 6.) And please assign simple, logical default keyboard shortcuts to the most useful windows. Browsing menus is wasting time.

  35. Andreas Eliasson says:

    Number 2 of course.

  36. View –> Debuggers, But I think I’m biased on this ;-).

  37. Definitely #2. I’m always looking for the windows there and it drives me nuts that i can’t find them. I need to remember that they’re on the debugger menu.

    Why can’t they be on both?

  38. Carl Daniel (VC++ MVP) says:

    I hate it when things move around for apparently no good reason… That said, I’d vote for moving them to View|Debug – that’s where I always look for them before remembering that they’re under Debug|Windows.

  39. Eric Vincent says:

    There really shouldn’t be any discussion. They’re windows, made for viewing, option 2 is the only answer. The only argument you could make for option 1 is that it’s already under the debug window, so you’ve got to live with a mistake, but that’s not much of an argument.

    While it’s true that they display information related to debugging, they don’t actually perform debugging functions. I expect to find debugging functions under the debug menu.

    Also consider that the other window options are consolidated under view, so why should these deserve special treatment?

    Grab the rip cord, take the leap, do it right.

  40. rob says:

    Number 2, but add a configuration option or registry key that allows you to revert back to number 1 for those who are already used to the old way. Giving users the ability to customize their dev environment is a very, very, very good thing.

  41. me says:

    Number 2 is much more logical. I also don’t think that a "VS7" compatibility profile would be out of line, especially in light of the other rumored key mapping changes.

    However, isn’t the real question (as Ken correctly points out) why don’t people just change the layout to suit their own personal fancy? After all, if that isn’t what Tools -> Customize… is for, then what IS it for?

    This seems to be a versioning situation where (unlike, ahem, changing API’s, for example) you can pretty safely make a change for the sake of consistency, aesthetics, or whatever and people have an existing, well-defined recourse to revert to the old behavior if they like.

  42. Keith Hill says:

    I’d vote for #2 also since it is consistent with the other tool windows. Just make sure you leave the "Windows" dropdown button on the Debug toolbar.

  43. Christian R says:

    I would also vote for #2. Despite knowing they have moved, I continue to auto-pilot to View then to Debug to find the Windows (like Memory).

  44. szoke says:

    No2 is the ultimate.

  45. Definitely #2 – at least that’s where I look for it every now and then, only to remember it’s not there 😉

  46. Steve O'Brien says:

    I’ll go with #2.

    Additional debugging requests:

    1) A mode to automatically step through code at a settable speed, so you don’t have to keep pressing the step key (with a pause button).

    2) An assignments window with 2 columns that each time the code does an assignment, puts the code executed in the left column, and the value assigned in the right column. When debugging, you could set a breakpoint at the place you know an error has occurred, then using the assignments window, work backward to determine where things went wrong.

  47. Corneliu I. Tusnea says:

    Option 2.

    + Lock (Panos Theofanopoulos)

    + Keep the shortcuts (Ilya Ryzhenkov)

    BTW, who come up with the "Ctrl+Shit+B" combination? And who can press it with one hand only?

    One more: When setting up the new shortcuts please make sure you do a usability test on a Natural Keyboard also ( It makes quite a difference.

  48. Under "View", with the rest of them.

  49. mlepage says:

    Seems unanimous to move them under the View menu (and I agree), yet in 2008 they remain under the Debugger menu. Whatever happened?

Comments are closed.

Skip to main content