The Visual Studio debugger is very smart and capable of doing a lot of things. You can change the execution path directly inside the debugger by not executing a certain line of the code or executing a certain line more than once.

While you are at the breakpoint, you can right-click on any line inside the IDE and select Set Next Statement or use Ctrl + Shift + F10 to move the debugger to that line, as shown in the following screenshot:

You can also drag the cursor of the current line using the mouse to move the cursor to any line in the code.

If you choose Run to Cursor from the right-click menu instead of Set Next Statement, the debugger will execute the lines in between and stop at the line that you select. If the line you select does not belong to the following execution of code, it will finish execution in regular course.

When working with a large project, there are situations when you need to label your breakpoints for better management and categorization such that you can enable/disable a certain group of breakpoints depending on your requirements. Let's put some breakpoints on the code and start debugging using F5 from the keyboard. The program will stop at the line where the first breakpoint is set, as shown in the following screenshot. Navigate to Debug | Windows | Breakpoints or press Ctrl + D + B.

A window will appear that will show all the breakpoints you have set in the code. In the preceding screenshot, you can see TestClassLabel. Now, let us right-click either on the breakpoint in the code or in the Tool window and select Edit labels, as shown in the following screenshot:

The command will pop up the Edit breakpoint labels dialog box, which lists all the labels and allows you to create a new label. Initially, it will be blank, but as you create more labels, the list will fill up. Once you have created the labels, you can choose any of the labels associated with the current breakpoint. You can also choose multiple breakpoints to select a label. Once you have selected the label for all the breakpoints individually, you can search in the Search box of the Breakpoints tool window to filter breakpoints from the list.

It is important to note that labels play a very important role in naming a breakpoint. When dealing with large projects, it will be really easy to manage breakpoints with labels to identify exactly which breakpoint it shows. The label is an alias to a breakpoint.

The breakpoint window also allows you to enable/disable an existing breakpoint. For instance, you can uncheck a breakpoint to disable the breakpoint in the actual code. Even though the breakpoint exists in the code, it is marked as disabled, and hence the program will not halt at that point.

The preceding screenshot shows how to disable a breakpoint from the right-click menu. It can also be accessed using Ctrl + F9.

Breakpoints can hold conditions and often come in handy when used in the iteration of a list or numeric value. Putting a halt inside an iteration means redundant breakpoints, and when the problem arises on a certain index of the loop, it is very hard to catch the exact value of the index. Conditions can help in putting a break only when a certain precondition is met. The conditional break allows placing an expression based on the current context and breaks only when the condition is met.

Right-click on the breakpoint either in the tool window or on the sidebar pane where the red breakpoint icon is shown and select a condition, as shown in the following screenshot:

You can declare a local variable using the Watch window and use it in the conditions. The IDE validates the condition and stores it in the PDB file. The textbox that appears is also capable of showing the IntelliSense menu inside it to enhance condition writing.

The two radio buttons indicate what needs to be considered from the condition. If the condition returns a Boolean value, we choose the option Is true; otherwise, we choose Has changed, where the condition can be anything.

Note that after choosing a condition, the red breakpoint icon will show a plus symbol, which indicates that it is conditional.

Visual Studio allows you to import/export breakpoints. If many developers are working on the same code, you can share the breakpoints that you have created in one project with others or save it. So, if you have breakpoints organized with labels, everything is exported to a file that can be used later, as shown:

The file is actually an XML file, which produces XML content of all the breakpoints. A breakpoint, once exported, can be imported back again by choosing the Import Breakpoint button on the Breakpoint tool window.

A breakpoint hit counter is used to determine how many times a breakpoint has been hit on a particular line. Sometimes, it is needed to halt a program only when a certain number of breakpoints have already been hit. Consider a situation where you are iterating with a large number of loops. In these cases, we can configure the breakpoint to stop only when the number of hits it encounters reaches a threshold, as shown in the following screenshot:

In the preceding screenshot, you can see the breakpoint hit count box, which is opened by right-clicking on the breakpoint and selecting Hit Count. The default setting is Break always but we can configure it to hit on a counter or a multiple of a counter, or even greater than equal to a counter.

As a default, when a breakpoint is hit, it will halt the execution of the program and pause it until we run the program again. But when the application is pretty large, you may want to continue the program and either run a macro when the breakpoint is hit or invoke a trace method. The breakpoint in such cases is called a tracepoint. To open the tracepoint window, right-click on a breakpoint and select When Hit.

Notice that we print the function name, thread ID, and thread name when the breakpoint is hit. The tracepoints can print items on the output window based on the options listed on the window. Keywords such as $ADDRESS, $CALLER, and so on specified on the window provide macros that evaluate the specific context. After you place a tracepoint, the breakpoint identifier in the left-hand side of the screen will appear as a red diamond instead of a circle.

If you choose Continue execution, it means the macro that we selected will be executed without stopping the code execution.

Breakpoint filters allow you to specify any additional criteria of the breakpoint. With filters applied, you can specify the breakpoint to hit only for a specific machine, or a specific process or a thread. This is often required if you are executing your program several times with a different process ID each time and want to debug only on a certain process ID.

In the preceding screenshot, we filter the breakpoints based on the name of the computer and the process ID. The search box allows you to type in text and, based on the input, the window will filter all the breakpoints that match the labels of the searched string.

DataTips can be imported or exported just like breakpoints. From the main menu, go to Debug | Export DataTips. It will show you a dialog box to store the DataTips in a file as shown in the following screenshot. Once the DataTips are stored in the file, you can open it to see its content. It's a SOAP-based XML file with all the information that is required to reload the DataTips again to a certain point. For instance, your comments or watched items will be kept intact in an XML file using tags such as Comments or WatchItem#. You can add any item as watch using the right-click context menu. The following screenshot shows the XML output on the right-hand side:

Once the file has been exported, Visual Studio can import the file in another Visual Studio IDE or in the same one and load the same environment of the DataTips when needed.

DataTips are really helpful for debugging and testing a large project.

DataTips can be cleared either by dismissing each individual DataTip or using the Debug menu. You have the following two options:

While debugging complex objects, the debugger is associated with a number of visualizers that help in displaying complex structures in better ways.

The visualizer creates a dialog box that appears on the Visual Studio IDE when an appropriate data type is loaded on the debugger. For instance, for a string instance, we generally have three visualizers associated. The Text Visualizer shows the string in the text format in a new window, as shown in the following screenshot. If the string content is XML, you can see the content in the associated XML visualizer and the HTML visualizer.

The debugger visualizer is associated with the data type of a class and is shown corresponding to either its loaded DataTips or in Watch windows. We can use a number of visualizers for a certain data type. We will see how to create a custom debugger visualizer later in this book.

Watch windows are places where you investigate objects just like DataTips. It is an alternative to DataTips. There are various types of Watch windows.

Autos

When the debugger hits a breakpoint, the Autos window shows all the objects and variables that are used in producing the current statement or items in context. Visual Studio automatically identifies the variables for you and shows them in this window. References are also listed inside Autos implicitly, as shown in the following screenshot:

You can open the Autos windows using Ctrl + D + A.

Locals

Locals are variables that are local to the current context and thread of execution. You can view and modify the value of a variable in the break mode using Locals, as shown in the following screenshot. The Locals window updates its value when the program is in the break mode.

Watch windows

Watch windows are customized windows that show objects and variables based on what users customize. While in the break mode, you can right-click on any variable and select Add to watch to add the selected object in the Watch window. You can also drag-and-drop expressions in the Watch window. Notably, there are actually four Watch windows available in Visual Studio to separate variables from one another, and to ensure that you can group similar objects in a Watch window when dealing with a large number of variables at the same time.

Generally, when you right-click and select Add to watch, an object will always be added to the Watch 1 window, but you can drag the expression from Watch 1 to any of the Watch windows.

In the following screenshot, you can see four Watch windows; each of them capable of showing variables in sync. The Watch windows show a grid with the Name, Value, and Type of each expression. You can directly type the value of a variable inside the Watch windows to change the value of the watched variable. Watch windows are also capable of showing calculated values.

Like all other windows, Watch windows also show a tree when a complex object is loaded onto it. For instance, an object of a class in the preceding screenshot shows its properties inside a tree.

Creating an object ID

You can create an object ID of an object or variable from inside a Watch window as well. An object ID is an aliasing mechanism to edit the value of a variable using an identifier. Objects with object IDs can be accessed directly in all debugging tools (immediate window, command window, watch window, and so on). Right-click on any object in the Watch window and select Make Object ID, as shown in the following screenshot:

Once the object ID is created, Visual Studio puts a n# number corresponding to the variable that can be tracked easily by calling it later.

Another important tool window that is most often required by any debugging session is the Error List window. After you build your project, this window appears automatically to show any errors, warnings, or information that you need to know. You can move the cursor to the exact location with details when we double-click on any record from the error list. The error list displays a description of the message, the file where the error occurred, column number, line number, and the project name.

You can toggle errors, warnings, and even messages. It also provides you with a search box to search in case the error list is pretty long, as shown in the following screenshot:

The Error List window also allows you to filter errors on Open Documents, Current Project, and even Current Document.

When running the sample code, there are two types of threads that are created inside the process. We created three threads from the user code, but you can find a few other threads that run with the user threads as well, for example, the Finalizer thread, which is set at the highest priority, Jitter, and so on. These threads should always be set aside.

It is sometimes important to identify the threads created by the user.

In the previous screenshot, you can select Flag Just My Code to flag threads that are created by the user code.

Another important technique is to debug parallel programs. Parallel programs are concurrent programs that may or may not induce a thread inside it. So, you cannot always handle a parallel program simply by using threads. The Visual Studio IDE comes with a number of additional tools that help in debugging parallel programs.

Let's consider the following code:

class Program
{
  static void Main(string[] args)
  {
    Task task_a = Task.Factory. StartNew(() => DoSomeWork(10000));
    Task task_b = Task.Factory.StartNew(() => DoSomeWork(5000));
    Task task_c = Task.Factory.StartNew(() => DoSomeWork(1000));
    
    Task.WaitAll(task_a, task_b, task_c);
  }

  static void DoSomeWork(int time)
  {
    Task.Delay(time);
  }
}

This is similar to the previously used code but using parallel asynchrony.

Similar to the Thread window, the parallel execution programs have Parallel Stacks and Parallel Tasks windows. Open them by navigating to Debug | Windows. Place a break point on Task.Delay and run the program, as shown in the following screenshot:

The Parallel Tasks window shows the different tasks that have been created for the program and the current status of each of the tasks. In the same way, Parallel Stacks shows the graphical view of all the task creations and how they are related to each other.

A debugger needs additional information about the project to work internally. The metadata information needs to be stored separately outside the actual executable such that the debugger can preload certain extent of the information prior to the execution of code; for instance, in Visual Studio, when you initiate a method or start debugging, the debugger automatically opens the appropriate files from the filesystem. This information is not available to the debugger inside the executable itself, but in a new type of file that coexists with the executable called program database files (PDB files). The basic schema of PDB files is:

Each PDB file is identified by a globally unique identifier (GUID). This GUID is stored in the header information of the file and it identifies the actual executable.

In the preceding figure, it is clear that the executable has the information about the source code file path and a GUID to uniquely identify itself. The PDB file holds this information as well. When the debugger loads the executable, it gets the PDB file path and loads the symbols from the file, if they are found. If the PDB files are not found, the debugger does not have any connection with the line the executable executes and the debug info on the same in the source file. Hence, the debugger cannot give you the flexibility of a line-by-line execution of a program.

The PDB files are generally much more important to the debugger than the source code itself. The PDB file loads the symbols into the vshost debugging environment and links the source code blocks with symbols. You can also maintain symbol servers to store the PDB files so that it is available to you while debugging.

Even though both the Command and Immediate windows can be used interchangeably while debugging an application, there is one basic difference between the use cases of these windows.

The Command window is used to execute commands or aliases directly from being within the IDE. You can execute almost all the commands that are either available in menus of the IDE or hidden somewhere. The Command window can load dlls or packages into the IDE as well.

The Immediate window, on the other hand, is solely used during debugging and is useful to execute statements, print values of a contextual variable, or even evaluate expressions. Generally, the Immediate window is quite capable of executing large expressions while being in the debugging mode in the same way as it does inside Watch windows.

An IntelliTrace file can be saved directly to the hard drive (.itrace) by choosing the Save button from the tool window. When you choose the Save button, it prompts the location where you want to save the content. Once you save the content, you can double-click and reopen the content in Visual Studio to get the entire report of the debugging session.

In the report, it produces a neat graph of the complete execution of the application with all the modules that are loaded, the entire system info, exceptions occurred during execution (if any), test data (if any), and the threads. It also lists the web requests that are made from the application, as shown in the following screenshot:

The IntelliTrace logs are so elaborate that the IDE can produce the same environment when you double-click on the any of the threads (or in particular, the main thread).

As we can see, IntelliTrace files are considerable in size; we can filter them to log trace information only to the modules specific to our requirement. Go to Tools | Options and then IntelliTrace | Modules, or directly type IntelliTrace in the IDE search box and type IntelliTrace to open the following screen:

To capture data, you can choose either the modules you want except the listed modules or the reverse based on the radio button you choose. Generally, we bother only about our own code. Let's select the first radio button and then select the Add button. Specify the filename that you need to omit the IntelliTrace information from and select OK.

To test our application, we will create a new dll and write the name of the dll in the Add a Pattern dialog box. Now, when you debug the code, the detailed information for the calls to the dll will be missing.

Debugger Canvas is another interesting tool for advanced debugging. It is actually built on top of IntelliTrace and helps in getting all the information about debugging in one single instance.

To work with Debugger Canvas, you need to install it from the following location: http://bit.ly/debuggercanvas.

Once you install Debugger Canvas to the IDE, you can open a new canvas by navigating to Debug | Debugger Canvas | Create New Canvas. Now let's put a breakpoint in the code and run the program.

You can see that the code is now shown inside Debugger Canvas on the IDE. On choosing Step Into from the menu or pressing F11, it produces another box with the code where the cursor is moved to. There are navigation keys to move back and forth between these windows.

Debugger Canvas is helpful at times when you want to see the entire call stack of the code and easily move back from one call stack to another easily. Debugger Canvas also has an option in the right-hand side corner of each canvas element, which shows the locals of the current execution block as seen in the preceding screenshot.

For users who want to debug by writing, the .NET class library opens up some interesting debugger APIs that you can invoke from your source code to call the debugger manually.

From the very beginning, there is a DEBUG preprocessor variable that determines whether the project is built in the debug mode.

You can write the following:

#IF DEBUG
/// The code runs only in debug mode
#ENDIF

The preprocessor directives are actually evaluated during compile time, which means the code inside #IF DEBUG will only be compiled in the assembly when the symbol is included.

There are other options such as Debug.Assert, Debug.Fail, Debug.Print, and so on. All of them only work in the debug mode. In the release mode, these APIs won't get compiled.

You can also call the debugger attached with the process, if any, using Debugger.Break(), which will break the debugger in the current line. You can check Debugger.IsAttached to find whether the debugger is attached to the current process, as shown in the following screenshot:

We can also load and attach a process directly to the debugger using code by referencing the EnvDTE packages. We will discuss them later in this book.

Visual Studio needs Terminal Services to run inside Visual Studio as it communicates with the process even when it is in the same machine using Terminal Services to maintain a seamless experience on both the normal and remote debugging of a process.