Watch value of a variable across multiple threads

Everyone is well aware of various ways of watching value of variable during a debug sessions. Watch, Immediate, Local Variables are just few examples. When working on a multi-threaded application, there may be scenarios that a method is called by different threads which means that a variable may have different value across different threads. If you want to watch value of that variable across, multiple threads the conventional tools may not be too helpful. This is where Parallel Watch window can come handy.

Let’s consider following piece of code. The relevant piece of information here is that CheckIfEven method is called using TPL AsParallel construct.

The method CheckIfEven takes an int variable input as parameter that we want to watch. We can watch its value via traditional Watch window but let’s try to do it by Parallel Watch window. This could be found under one of the Debug menu options as shown below.

Next, we add a watch here. You can do it clicking on the “Add Watch” text and entering the name of the variable.

Now once your break-point is hit, you will be able to see the value of this variable across multiple threads.

Until next, happy debugging!!


Posted in CodeProject, Debugging | Leave a comment

Scroll bars Re-engineered

Scroll bars is an effective tool that novices to advanced users use every day without appreciating its effectiveness and usefulness. Various vendors have evolved its design including its position in an application, workflow with gestures and even visibility. Microsoft had re-engineered its use in Visual Studio that many end-users are not aware of and therefore it seem to be an under-utilized feature.

A typical screen in Visual Studio looks like follows with scroll bar on the right to browse through the page up or down.

What many people don’t realize is that you can configure to use your scroll bar more effectively. Right clicking on scroll-bar will bring following context-menu.

Clicking upon the “Scroll Bar Options” will bring up following dialog. You can also get to same dialog by clicking on Tool->Options also. Under the Behavior section, current setting is set to “Use bar mode for vertical scroll bar”.

Let’s change it to select “Use map mode for vertical scroll bar”. Let’s stick with other options of Source Preview Tooltip as checked with Source Overview set to Off.

Clicking on OK button here will make some adjustments to scroll bar . Most visible change will that the scroll bar thumb may look a little bigger. However, if you hover mouse over the anywhere in the scroll bar, it will bring up a tooltip that will provide code preview of that area. This is useful in large code files where you can get a quick preview without loosing the areas where you are currently working on.

Let’s go back to the scroll box options and see what else can it offer with other settings. Let’s change the Source view to Narrow now.

With this setting, now you get a quick preview of code within the Scroll bar as shown below.

Its certainly not easily readable but that tooltip is still there. You can change the  Source Overview Size. With Medium, the source preview with scroll bar looks as follows.

Whereas with a Wide Source overview, it looks as follows.

May not be most favorite tool for everyone but at least be aware this is something available, if needed.

Until next, happy debugging!!

Posted in CodeProject, General | Leave a comment

Bring back my Intellisense window

Intellisense is something that every developer uses consciously or unconsciously. For example, you type a class instance name in visual studio and when you type . (period), intellisense window pops-up showing you various properties, methods etc. for that class.


However sometimes you lose this window such as by by clicking somewhere else on the screen. As a result, now the intellisense window disappear from screen.

If you want to bring back that window, just make sure that your cursor is right after the . for the class you need intellisense. Hitting Ctrl + Space will bring back that window and you can start off right from where you left.

Until next, happy debugging.

Posted in General | Leave a comment

Breaking in code for a specific class instance using Conditional Expressions

Let me describe the problem in hand by presenting a concreate example here. Let’ say we have an Employee class as shown below. Note here that the Salary property is calculated based on certain class instance fields.

Here is how the class is consumed.

Let’s say there is an issue when calculating the Salary for Mr Problematic. There is not issue with Salary for Mr Fine. Easiest way could be to add a break-point in the getter for Salary property but then your code will stop here when Salary is computed for each Employee. Our interest is to only break when Salary is calculated for Mr Problematic. This is where combination of Make Object ID and conditional break-point (using Conditional Expression) can come in handy.

In order to accomplish that, we first need to Make Object ID for Employee class instance for Mr Problematic. This can be accomplished during a debug session once problematic instance has been created as shown below.

You can verify that object ID for this instance is created from the datatip.

Now you can simply add a Conditional breakpoint at the getter for Salary property by using a Conditional Expression of true when this == $1

At this point, you can simply hit F5. Your code will hit the breakpoint once the condition are met. You can verify that it’s the right instance by inspecting the object itself in Watch window as shown below.

One downside of this approach is that you will have to Make Object ID every time for a different debug session. Otherwise you will get following warning.

Until next, happy debugging.

Posted in CodeProject, Debugging | Leave a comment

Function Evaluation within Immediate Windows with No Side Effect

I make quite heavy use of Immediate Window. Its a nice tool within Visual Studio to print variable values, evaluate expressions and even execute statements. However there are times when doing this type of activity changes the state of particular object.

Let me describe the scenario with an example. Let’s say I have an Employee class as follows.

This class is consumed as shown below.

Once the break-point is hit, Salary property of this object can be inspected within Visual Studio.

If I need to run a function of this object, I can easily do it from Immediate Window. In this case, if I call GiveEmployeeARaise method of the Employee object, that function changes the value of Salary which is reflected in Watch window here.

There could be times when I don’t want these test runs of certain function change the state of this object. This is where you can call the method with nse (No Side Effect) switch. Let’s call the same method again but using the switch.

So this time, the Salary property didn’t get incremented.  Isn’t this cool? When I am sure that there is no problem with that state change, you can just remove the nse switch.

Until next, happy debugging.

Posted in CodeProject, Debugging | Leave a comment

Make Your Output Window Less Cluttery

Debug.WriteLine is a handy way to dump some useful information into trace listeners.  When debugging your program in Visual Studio,  you can view these messages in the Output window. However, there is lot more information shown in here that can easily clutter the contents of Output Window.

This happens because all the different types of messages that are been shown in this windows by default. Figure below shows all those different types of messages that are checked by default.

Let turn off some of these here.

Next time you debug the program, the Output window will be little less messy 🙂

Until next, happy debugging

Posted in CodeProject, Debugging | Leave a comment

Parallel Stacks – Textual Form

Parallel Stacks is a very handy feature in Visual Studio for debugging multi-threaded applications. I also use this sometimes when investigating dump files for managed applications. It provides a nice graphical view of what various threads are doing in your application. As an example, this makes it easy to find the unique stacks in your application.


Of course you can zoom into any callstacks to see more details.

However there are times when I needed textual form of all the callstacks. Windbg provides commands like ~*k or ~* e !clrstack to determine that. If you have to do the same within Visual Studio, this is where Command Window can come in handy. You can reach it using View -> Other Windows -> Command Windows menu item as shown below.


Once in command window, you can use Debug.ListCallStack command with AllThreads switch and it will spit out the available callstacks.


Until next, happy debugging!!

Posted in CodeProject, Debugging | Leave a comment