{"id":13686,"date":"2017-09-18T09:00:47","date_gmt":"2017-09-18T16:00:47","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudio\/?p=13686"},"modified":"2019-02-14T15:26:59","modified_gmt":"2019-02-14T23:26:59","slug":"7-more-lesser-known-debugging-tactics-for-visual-studio","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/visualstudio\/7-more-lesser-known-debugging-tactics-for-visual-studio\/","title":{"rendered":"7 More Lesser-known Debugging Tactics for Visual Studio"},"content":{"rendered":"

So, you really liked learning about 7 Lesser Known Debugging Hacks for Visual Studio<\/a>? Good news is that there is always more to learn! The Visual Studio debugger is an enchanting creature that can save you loads of time while finding and fixing issues in your application. It is bursting with tools that can make debugging easier\u2026 if you know they exist, and where to find them! Let\u2019s look at 7 more lesser-known goodies you can use to #SuperChargeYourDebugging<\/a>.<\/p>\n

1. Edit the value of a variable without changing code<\/h2>\n

Are you ever debugging when you get to a variable and it isn\u2019t what you think it should be? Or maybe you just want to change it to see how the code would behave with a different value? You can easily do this while debugging simply by editing the value of the variable in memory using whichever method fits best into your flow: DataTips,<\/b> the Autos, Locals, or Watch windows<\/b>, or the Immediate window.<\/b><\/p>\n

A. Hover over the variable to get a DataTip<\/b> and then single click on the value in the table or right click and choose \u201cEdit value\u201d <\/b>from the context menu. An edit cursor appears and you can provide a new value for the variable.<\/p>\n

\"Data<\/a><\/p>\n

B. In the Autos, Locals, or Watch windows<\/b> double click on the value in the grid or right click and choose \u201cEdit value\u201d <\/b>from the context menu. The value becomes editable and you can provide a new value for the variable.<\/p>\n

\"Local<\/a><\/p>\n

C. In the Immediate window, <\/b>you can use code syntax to reassign the variable to a new value. For example, you can type \u201cx = 12;\u201d<\/i> which would change the in-memory value of the in-scope variable x<\/i> to be the number 12. This method is most beneficial if you need to create or manipulate a variable before assigning it.<\/p>\n

\"Immediate<\/a><\/p>\n

2. Look at values throughout recursive function calls<\/h2>\n

Do you typically find yourself debugging recursive functions using many statements of Debug.WriteLine()? It can be hard to keep in your head how the recursion will play out. One helper for this mental load, can be to use the Parallel Watch window<\/b> to see the change in the variables of the recursive call.<\/p>\n

    \n
  1. Open the Parallel Watch window (Debug\/Windows\/Parallel Watch)<\/b>.<\/li>\n
  2. Click \u201c<Add Watch>\u201d<\/b> and type in the name of a variable you care about.<\/li>\n
  3. As you debug through the recursive calls, you will see them added in new rows in the window<\/li>\n<\/ol>\n

    \"Parallel<\/a><\/p>\n

    3. Show parameter values in the Call Stack<\/h2>\n

    Most developers use the Call Stack<\/b> like a map for their current context in their debugging session. It provides history on where the code calls have happened to get into this state. It can be extra helpful to bring in additional information to orient yourself, like parameter values.<\/p>\n

      \n
    1. Right click on a frame in the Call Stack.<\/b><\/li>\n
    2. In the context menu select the option to \u201cShow Parameter Values\u201d<\/b><\/li>\n
    3. Now see the values are inline directly as part as the input parameters in the Name column<\/li>\n<\/ol>\n

      Note: There can be performance impact to your debugging session when \u201cShow Parameter Values\u201d in on and the call stack is visible. We recommend turning the option off when you are not actively using it.<\/p>\n

      \"CPP<\/a><\/p>\n

      4. Break on a function without manually finding the source<\/h2>\n

      Are you ever thrown into a situation where you know what you need to debug, but finding the source file that contains that code is going to be a bit challenging? One quick way to set a breakpoint in the debugger without needing to know which file and line the code resides in is by setting a Function Breakpoint.<\/p>\n

        \n
      1. Press CTRL+B<\/b>. Or select Debug\/New Breakpoint\/Function Breakpoint. <\/b><\/li>\n
      2. Type in the name of the function that you wish to break on. Click OK.<\/li>\n
      3. Start debugging, trigger your code to execute, and watch as you stop at a magical breakpoint in a source file that you didn\u2019t have to find manually.<\/li>\n<\/ol>\n

        \"Function<\/a><\/p>\n

        5. Flag threads and run all of them to the same location<\/h2>\n

        When debugging multithreaded code, odds are you are going to hit breakpoints and take steps that result in the program advancing other threads. Sometimes to inspect a bug, it might be easier to have all the threads stopped at the same place so you can inspect the state of the program at that time. There is an easy way to do this by flagging threads and then triggering Run Flagged Threads to Cursor. <\/b><\/p>\n

          \n
        1. Figure out which threads you are interested in. You can use Show Threads in Source<\/b>, the Parallel Debugging <\/b>windows, or the Threads <\/b>window.<\/li>\n
        2. Choose the Flag icon to mark the threads you are interested in.<\/li>\n
        3. Right click on the line of code where you want to inspect the application.<\/li>\n
        4. In the context menu select Run Flagged Threads to Cursor. <\/b><\/li>\n<\/ol>\n

          Note: There can be noticeable performance impact to your debugging session when Show Threads in Source<\/b> is turned on or any threads related windows are visible. We recommend only choosing these features when you are actively using them to debug.<\/p>\n

          \"Run<\/a><\/p>\n

          6. Switch active threads to see the context<\/h2>\n

          The parallel watch window is great for seeing many variables across threads, even ones that you have not stopped on. But what about when you want to inspect a detailed state of the application on that thread? The yellow arrow shows the current instruction on the current thread and that sets the context for the rest of the debugger. The Watch windows, Data-tips, and Call Stack all show the state at this context. The debugger makes it easier for you to switch this context by letting you Switch to Thread\u2026 <\/b><\/p>\n

            \n
          1. Select the thread that you want to inspect. You can identify it using Show Threads in Source<\/b>, the Parallel Debugging <\/b>windows, or the Threads <\/b>window. <\/b><\/li>\n
          2. Right click on the thread, and select Switch to Thread\u2026<\/b> and choose your thread.<\/li>\n
          3. Notice how the yellow arrow changes to that thread\u2019s location and the other windows now have that context.<\/li>\n<\/ol>\n

            \"Switch<\/a><\/p>\n

            You can also switch your current debugger context by using the Debug Location Toolbar. <\/b>Click the drop down that enumerates the threads in the program and select a thread to switch to. The Debug Location Toolbar <\/b>is a great tool to use if you are noticing performance impact from having other thread related features visible. The features of this toolbar do not significantly impact performance and can be used as a shortcut for many threaded scenarios I mention.<\/p>\n

            \"Debug<\/a><\/p>\n

            Note: There can be noticeable performance impact to your debugging session when Show Threads in Source<\/b> is turned on or any threads related windows are visible. We recommend only choosing these features when you are actively using them to debug.<\/p>\n

            7. Stop when a variable value changes in C++ code<\/h2>\n

            It can be hard to track down where a specific variable is changing its value. For native developers there is a special breakpoint type, the Data Breakpoint<\/b>, that can help you track down issues caused by variables being manipulated unexpectedly.<\/p>\n

              \n
            1. Stop at a place in code after your object has been created in memory.<\/li>\n
            2. Select Debug\/New Breakpoint\/Data Breakpoint.<\/b><\/li>\n
            3. Type in the address of the variable you want to know about. For example, &MyVariableName, or 0x0085F918<\/li>\n
            4. Select the number of bytes starting at that address that you wish to monitor.<\/li>\n
            5. Trigger the breakpoint and the debugger will stop on the line of code that modified that memory address.<\/li>\n<\/ol>\n

              \"Data<\/a><\/p>\n

              Note: It is important to remember that memory addresses are different every time you start debugging so you will need to clear out and reset your Data Breakpoints every time you start a new debug session. The number of Data Breakpoints that you can have active at a time is limited by the hardware of your environment and the debugger will warn you when you reach that limit.<\/p>\n

              Learned Something? Let us know!<\/h2>\n

              What is your favorite lesser known debugging feature? Comment below!<\/p>\n","protected":false},"excerpt":{"rendered":"

              So, you really liked learning about 7 Lesser Known Debugging Hacks for Visual Studio? Good news is that there is always more to learn! The Visual Studio debugger is an enchanting creature that can save you loads of time while finding and fixing issues in your application. It is bursting with tools that can make […]<\/p>\n","protected":false},"author":1137,"featured_media":255385,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[155],"tags":[237,1383,9,287,156],"class_list":["post-13686","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-visual-studio","tag-net","tag-c","tag-debug","tag-tips-and-tricks","tag-visual-studio-2017"],"acf":[],"blog_post_summary":"

              So, you really liked learning about 7 Lesser Known Debugging Hacks for Visual Studio? Good news is that there is always more to learn! The Visual Studio debugger is an enchanting creature that can save you loads of time while finding and fixing issues in your application. It is bursting with tools that can make […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/posts\/13686","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/users\/1137"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/comments?post=13686"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/posts\/13686\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/media\/255385"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/media?parent=13686"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/categories?post=13686"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-json\/wp\/v2\/tags?post=13686"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}