Visual Studio Debugging Techniques – Part1

Posted: October 5, 2014 in Debugging
Tags: , ,
Importance of learning debugging techniques

Just pause for a second and think about the amount of time a developer spent in writing new code, modifying or understanding existing code in a day. In my experience I have observed that on an average a developer spent more time in understanding the existing code and verifying the modifications made to the exiting code or the new code added is working as expected in comparison to the amount of time taken to write the new code.

We know that writing perfect code is an illusion due to many reasons. As per one of the survey conducted few years back $60 billion per year in economic losses are due to software defects. History tells us that it would not be possible to produce a bug free software no matter what methodology or process we follow. But by having sound debugging techniques we can contribute to minimize the revenue loss to our project by quickly identifying the root cause for the critical bugs.

The other main challenge for any developer is to maintain a legacy source code base. Especially for a developer working in a product based company like ours this would be a minimum thing that the organization would expect from a developer. So in order to avoid any code of regressions in the legacy code a sound understanding of the existing code is very essential.

If you happen to be in a team which is responsible for maintenance support of a huge code base then it is very essential for us to have deeper understanding of the system as a whole.

In other words, as a developer we spent lot of time debugging the source code using Visual Studio (.Net Programmers). Debugging is a major part of the development lifecycle. Sometimes challenging, sometimes puzzling, sometimes annoying and sometimes frustrating.

The progress of debugging tools over the last years has made many debugging tasks much easier and less time-consuming.

In my next few blog posts, I will try to summarize some of the most useful debugging tricks and techniques that can save you a lot of time when using Visual Studio.

Generally either we attach debugger to an already running instance of a process or start a process under the visual studio debugger. It is always easy to debug a solution because of the easy access to the source code and symbols. For this post most of the topics were taken from a code project article.


Labeling in Break Point

This is a very useful feature in Visual studio for managing breakpoints related to each component separately and re-use them as needed. It’s kind of categorization of breakpoints. If you are having different types of breakpoints which are related with a particular functionality, you can give their name and can enable, disable, filter based on the requirements.

Let us assume that your source code has got multiple components namely Object control, Admin console, XML Import, XML Export etc.  Each time you want to debug object control you need the same set of break points to begin the analysis of root cause of an issue. In such case you can name all the break points used to debug Object Control source code prefixed with OC and Admin Console break points prefixed with AD there by enabling you to better group and filter breakpoints.

To understand the whole functionality, let’s assume that you have the below code block which we want to debug. Insert break points in the below source code at each line where you find break point comment.


If you run the program, execution will pause on the first breakpoint. Now see the below picture, where we have the list of breakpoints.


In the above picture label column in blank. Now, see how we can set the label on break point and make use of it. To set label for any breakpoint, you just need to right click on the breakpoint symbol on the particular line or you can set it directly from breakpoint window.


Right Click on Breakpoint, Click on the Edit Labels link, you can add the label for each and every breakpoints. As per the sample code, I have given very simple understandable names for all the breakpoints.


Let’s have a look at how this labeling helps us during debugging. At this time, all the break points are enabled. Now if you don’t want to debug the method2, in a general case you need to go to the particular method and need to disable the breakpoints one by one, here you can filter/search them by label name and can disable easily by selecting them together.


The above example is pretty basic, but this feature is very useful when you have huge lines of code, multiple projects, etc.

Conditional Breakpoint

Visual Studio Breakpoints allow you to put conditional breakpoint. So if and only if that condition is satisfied, the debugger will pause the execution.

To set any of these you

  1. Set a break point
  2. Right Click over the break point, and in the popup menu you select an option that suites you.

These options are as follows:

  • You can set a condition, based off of a code expression that you supply (select Conditionfrom the popup menu). For instance you can specify that name == “Kishore” or some other expression.
  • You can make breakpoints trigger after they have been hit a certain number of times. (Select Hit Count from the popup menu). This is a fun option to play with as you actually aren’t limited to breaking on a certain hit count, but you have options for a few other scenarios as well. I’ll leave it to you to explore the possibilities.
  • You can Set filters on the Process ID, thread ID, and machine name (select Filterfrom the popup menu)



Check the Breakpoint Symbol. It should look like a plus (+) symbol inside the breakpoint circle which indicates the conditional breakpoints.


After setup of the condition of your breakpoint, if you run the application to debug it, you will see execution of program is only paused when it satisfied the given condition with breakpoint. In this case when name=”Name3″.


VS IDE provide the intellisense within the condition textbox.


In condition window there are two options available:

  • Is Trueand
  • Has Changed

We have already seen what the use of “Is True” option is. “Has changed” is used when you want to break the code if some value has changed for some particular value.

Import / Export Breakpoint

At times we want to continue the debugging session which we are doing on a coworker machine.

You can export breakpoints from a Visual Studio project to an XML file by using the Breakpoints window. Later, you can import the breakpoints from the XML file back into Visual Studio.XML files enable easy sharing of breakpoints between projects and developments. You can import and export breakpoints to transfer them between projects or to e-mail an XML file to a coworker. You can also make bulk changes to breakpoints by using a text editor to modify the XML file.

To export all breakpoints that match the current search criteria

  1. In theBreakpoints window toolbar, click the Export all breakpoints matching current search criteria

The Save As dialog box appears.

  1. In theSave As dialog box, type a name in the File name

This is the name of the XML file that will contain the exported breakpoints.

  1. Note the folder path shown at the top of the dialog box. To save the XML file to a different location, change the folder path shown in that box, or clickBrowse Folders to browse for a new location.
  2. ClickSave.

To export selected breakpoints

  1. In theBreakpoints window, select the breakpoints you want to export.

To select multiple breakpoints, hold down the CTRL key and click additional breakpoints.

  1. Right-click in the breakpoints list, and chooseExport selected.

The Save As dialog box appears.

  1. In theSave As dialog box, type a name in the File name

This is the name of the XML file that will contain the exported breakpoints.

  1. The folder path is shown at the top of the dialog box. To save the XML file to a different location, change the folder path shown in that box, or clickBrowse Folders to browse for a new location.
  2. ClickSave.

To import breakpoints

  1. In theBreakpoints window toolbar, click the Import breakpoints from a file

The Open dialog box appears.

  1. In theOpen dialog box, browse to the directory where your file is located, and then type the file name or select the file from the file list.
  2. ClickOK.



If you delete all the breakpoints from your code at any time, you can easily import them by just clicking on the “Import breakpoints button. This will restore all of your saved breakpoints.

Breakpoint Hit Count

Did you know you can make it so a Breakpoint will not break every time but only when it is hit a certain number of times?  Just right click on any Breakpoint and go to Hit Count:

“Breakpoint Hit Count “window having the following:

  1. Break always
  2. Break when the hit count is equal to a specified number
  3. Break when the hit count is a multiple of a specified number
  4. Break when the hit count is greater than or equal to a specified number.





Comments are closed.