PerftTips is a performance measurement feature introduced in Visual Studio 2015. This displays an approximate time previous line of execution took as shown within red rectangle below.
Recently why playing with certain settings, I lost getting the PerfTip. So there were no estimates of time in the Visual Studio UI as in image below.
Turned out there is a setting to enable/disable PerfTip. Make sure you have this one checked.
Until next, happy debugging!!
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!!
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!!
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.
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.
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.
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
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!!
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!!
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.
Only way solving a problem is by Debugging it. 