Posts Tagged ‘Debugging’


As a developer, regardless of your programming language or the platform that you target, we use the debugger on a daily basis. If you are a developer using Microsoft technologies then you need to learn and understand how to make the most of the Visual Studio debugger so that you can be more productive and effective in your everyday development.

Irrespective of your experience level, I encourage you to read my blog post series on Visual Studio debugging techniques. This is my second blog post in this series and I am sure that by the time you finish reading this entire series, you will have some good knowledge of debugger features which you would want to use immediately when you get back to your computer!

  Step Into Tips





I am sure you might have used ‘Step Into’ (F11) feature of Debug tool bar whenever you would like to debug the code related to a function call line by line. If the line contains a function call, Step Into executes only the call itself, then halts at the first line of code inside the function. Otherwise, Step Into executes the next statement.


12thOct_QTTNow I will tell you another interesting usage of F11. Whenever we would like to debug an application we setup breakpoint(s) and hit F5. But instead of starting the debugging by pressing F5 if you press F11 it would takes you out of the designer mode into debug mode to the first line of your code that is going to be executed.


12thOct_QTTThis is a useful, whenever you would like to debug startup issues in your project. Imagine how you would have done it otherwise? You could have scanned the code and identified what was the first line that is going to be executed outside designer and setup a break point before hitting F5 and remove the break point later. The key here is it saves your time.


12thOct_QTTAnother useful tip is that you can start debugging by selecting a line in the source code and use Run to Cursor (CTRL+F10) option instead of using Start Debugging F5. How cool is that? Even if you would like to debug the click event of a button then directly go to the source code and use Run to Cursor (CTRL+F10) option.

 Import and Export Data Tips

At times we want to continue the debugging session which we are doing on a coworker machine or perhaps you would like to handover the debug session to someone else for their quick feedback.

The first step towards accomplishing this activity is to use import/export breakpoint functionality. But what if you would like to write some debugging comments in your code which could be helpful to those who are resuming this debugging session.

Drag-Drop Pin Data Tip

To accomplish this you need to Pin the Data Tip. Data tip is kind of an advanced tool tip message which is used to inspect the objects or variable during the debugging of the application. When debugger hits the breakpoint, if you mouse over to any of the objects or variables, you can see their current values.





Hitting Ctrl turns the data tip currently displayed nearly transparent. It becomes visible again as soon as it is released.

Change Value Using Data Tips

DataTips is also used to change the value while debugging. This means it can be used like a watch window. From the list of Pinned objects, you can change their value to see the impact on the program.





We can Pin/Unpin Object/Variable Inspect or Data Tip. By pressing the pin Icon Data Tip can be pinned or unpinned.





Click on expand to see comments downwards arrow and type your comments here. BTW it is a multi-line comment.



Last Session Debugging Value

This is another great feature of Visual Studio 2010 debugging. If you pinned some data tip during the debugging, the value of pinned item will remain stored in a session.

It means even when you stop debugging this information is still available in Visual studio.


We can go back to the same line and hover the mouse on the pin to see the details of the last debugging session value as shown in the below picture:




Export/Import/Clear Data Tips

Later you can use Debug > Export Data Tips command to export the data tips and Debug > Import Data Tips command to import it on to a different machine and continue debugging. Debug > Clear Data Tips can be used to clear the data tips in the solution.


Debugger Display Attribute

You can notice some specific information displayed for a type when I hover the mouse on it.




In the above example when I hover the mouse on SystemInfo type, debugger is displaying some specific information related to this type. It is because we have decorated SystemInfo class as shown below.









Debugger display attributes allow the developer of the type, who specifies and best understands the runtime behavior of that type, to also specify what that type will look like when it is displayed in a debugger.

The DebuggerDisplayAttribute constructor has a single argument: a string to be displayed in the value column for instances of the type. This string can contain braces ({ and }). The text within a pair of braces is evaluated as an expression. For example, the following C# code causes “Count = 4” to be displayed when the plus sign (+) is selected to expand the debugger display for an instance of MyHashtable.


Data Tips from comments

Did you know that you can get tool tips from comments? I can hover mouse on comment which actually shows the data tip. Which means you can leave comments with useful expressions.





12thOct_QTTYou can do this on the fly as well. Which means during debugging you can add expressions as comments and determine the value. How cool is that?








I will catchup with you next week with my last blog post on this series with some more interesting tips.

Until then Happy Debugging!!!

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.