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 Debugging, CodeProject | 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 Debugging, CodeProject | 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

Visual Studio 2017 – Reattach to Process

I have been in situations number of times that required troubleshooting certain issues against a running process using “Attach to Process” mechanism. The whole process of bringing up “Attach to Process” dialog, finding the right process and then attaching to it etc. could become little tedious process especially when you have to attach, detach and then re-attach against same process multiple times. There was enough need for a better mechanism that there are Visual Studio extensions available for it in the marketplace. Visual Studio 2017 has introduced a new “Reattach to process” option that makes this process little easier.

Let’s say, I need to debug against running instance of IISExpress. I’ll first bring up the Debug -> Attach to Process menu option


We can then find the process from this dialog and then Attach to for debugging.
Once the troubleshooting is done, we can just Stop Debugging this.

So far so good. However, if I need to go back and attach to same process again and again, I needed to repeat all the above steps again & again too. However, if you are using Visual Studio 2017, you should be able to see the following “Reattach to Process” option that will start debugging same IISExpress process again without doing all those steps.


Until next, happy debugging!!

Posted in Debugging, CodeProject, Visual Studio 2017 | Leave a comment

Visual Studio 2017 – Process Filter option in Attach to Process dialog

Sometimes there are usability features in the UI that seemingly look small but can have bigger impact on the user experience. In my view, one of the usability feature missing in Visual Studio UI for quite some time was about “Attach to Process” dialog. Below is how this dialog looks in Visual Studio 2015.


Attache to a running process is a great feature that I have used on number of occasions. Almost every time I felt that looking for a specific process from this grid was “slow” process as it requires you to scroll through the list.  Guess what, look what we got in Visual Studio 2017.


We have an option for filtering by process name. So if I need to look for all the w3wp process, I just start typing the process name and that’s bring up what I was looking for.


Until next, happy debugging.

Posted in CodeProject, Visual Studio 2017 | Leave a comment