Centric connect.engage.succeed

Debugging with Visual Studio - Part II: inspection and intervention

Geschreven door Redactie Craft - 24 augustus 2017

Redactie Craft
Remember part I of this blog series on debugging? We discussed the debugging features of setting breakpoints in Visual Studio. Since all our breakpoints are in place, we’ll continue where we left off, press the F5 button and start to debug our application. So, what features does Visual Studio offer when a debugging session is active?

Read: Debugging with Visual Studio - Part I: Breakpoints

Start the debugger

Obviously, we should start the debugger before we can begin looking at our code and the breakpoints we’ve set. The most commonly used option to do this is the ‘Start Debugging’ feature (for which F5 is the shortcut). Another lesser known but very useful option is to attach to an already running process. This allows us to debug applications inside another process, such as Windows Services hosted in svchost.exe, or web applications inside IIS (Express).

Start the debugger

Of course, there are some other ways as well to kick-off the Visual Studio debugger, using multiple start-up projects for example. The start-up projects can be configured at solution level. A frequent scenario using this feature is where an application uses a separate service layer, hosted in its own project and its own process. A less frequently used method to start the debugger is to start an external program, which can be configured in the project properties. Lastly – and also a sneak peek at the next part of this blogging series – you can use the Debugger.Launch method, using code to start the debugger.

Execution Control

So now our code is running and we can start our debugging sessions by looking at the most basic and commonly used features, like stepping through the code. From the current execution line – marked in yellow – you can use:

  • Step Over (F10)
  • Step Into (F11)
  • Step Out (Shift+F11)
  • Run to Cursor (Ctrl+F10)
  • Set Next Statement (Ctrl+Shift+F10)

Do it again!

That last bullet is an interesting one… did you know you can make the debugging take a step back? When debugging, have a look at the yellow arrow that indicates which line is about to be executed. This arrow can be dragged back to any previous line to run that code again, which can be very useful, especially in combination with some features we’ll see later. Similarly, it is also possible to skip over some lines, jumping over a section you suspect of containing a bug for example.

Set Next Statement

This feature has actually been around since VS2010, but it’s about to be improved: during the last Build conference, Microsoft announced it’s working on a ‘Step Backward’ feature that enables actually stepping back while debugging. This feature is based on historical debugging mode and data that Visual Studio tracks (see also this video from 52:36 onwards).

Take a break

Debugging with Visual Studio break button

Sometimes you find yourself waiting for feedback from your app, but it just keeps processing and processing, leaving you wondering what is being processed. Maybe you’re in a long and heavy loop, or the software is waiting for something that is not happening. In this case the ‘break’ button comes in handy. If it’s running your own code at the time, it’ll break at the code line it is currently executing and you can check to see what’s holding up the process.

Inspection and analysing

An essential part of debugging is looking up the current values of your variables. Apart from simply hovering over your variable, a number of other options are available. Obvious ones are the Locals and Autos windows, which display variables and their values in the current scope. The Autos window also displays returned values by called methods.

However, one window I particularly favour using is the QuickWatch. This modal dialog comes in handy for testing an expression and evaluating value trees, which are presented in a tree view. Very useful, for instance, for drilling down in an exception hierarchy. A variation of the QuickWatch dialog box is the Watch window. Variables can be added to the active Watch window by simply right-clicking a variable and choosing ‘Add Watch’; the variable will be pinned and can be tracked during debugging.

Another option is the Immediate Window. This window provides a command-line style environment to execute C# lines. Just like the QuickWatch window, it supports Intellisense and provides support for writing lambda expressions. Debugging lambda expressions are a typical example of code that needs testing at runtime (this feature was introduced with VS2015).

Edit and Continue

We’ve touched on some debugging techniques at runtime. So, by now we should have found the bug and can update our code. What better way to do this than at runtime, fixing the bug and testing it immediately. This can be done using the ‘Edit and Continue’ feature. When execution is paused at a breakpoint, try to edit your code, make sure it’s error free, and press ‘Continue’ (or F5) to continue the debugging session. This also works very well together with dragging the yellow arrow (execution point) to the point before the code you just fixed.

Wrap up

That’s it for debugging features in the Visual Studio IDE. Do you know of any tricks I missed that the world should know about? I’d love to hear them! Next time in this series: debugging-specific code enhancements of C#.

Also read: Debugging with Visual Studio - Part I: Breakpoints.


Schrijf een reactie
  • Captcha image
  • Verzenden