"Hidden Secrets" of the Visual Studio .NET debugger? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

As much as I generally don't like the discussion/subjective posts on SO, I have really come to appreciate the "Hidden Secrets" set of posts that people have put together. They provide a great overview of some commonly missed tools that you might now otherwise discover.

For this question I would like to explore the Visual Studio .NET debugger. What are some of the "hidden secrets" in the VS.NET debugger that you use often or recently discovered and wish you would have known long ago?

Answer 1

One of my favorite features is the "When Hit..." option available on a breakpoint. You can print a message with the value of a variable along with lots of other information, such as:

• $ADDRESS - Current Instruction
• $CALLER - Previous Function Name
• $CALLSTACK - Call Stack
• $FUNCTION - Current Function Name
• $PID - Process ID
• $PNAME - Process Name
• $TID - Thread ID
• $TNAME - Thread Name

You can also have it run a macro, but I've never used that feature.

Answer 2

You can right-click an object in the Watch window and click Make Object ID.

It will assign that instance an ID number, allowing you to see, in a complicated object graph, which objects refer to the same instance.

Answer 3

For .net applications System.Diagnostics has lots of useful debugging things. The Debugger class for example:

Debugger.Break(); // Programmatically set a break point
Debugger.Launch(); // Launch the debugger if not already attached
Debugger.IsAttached // Check if the debugger is attached

System.Diagnostics also has lots of good attributes. The two I've used are the debugger display attribute for changing the details put into the locals window and the step through attribute for skipping code you don't care about debugging:

// Displays the value of Property1 for any "MyClass" instance in the debugger
[DebuggerDisplay("{Property1}")]
public class MyClass {
    public string Property1 { get; set; }

    [DebuggerStepThrough]
    public void DontStepInto() {
       // An action we don't want to debug
    }
}

Answer 4

As a web developer who works with Web Services that are within the same solution as my front-end code most of the time, I found the ability to "attach" to a process to be a HUGE time saver.

Before I found this hidden gem, I would always have to set a breakpoint on some front-end code that called a web service method and step into it. Now that I know about this trick/feature I can easily set breakpoints on any part of my code that I want to which saves me loads of time and effort.

Answer 5

$exception in the watch window will show the exception that is currently being processed even if you don't have a catch that assign the Exception instance to a named variable.

Answer 6

• The threads window, from Debug -> Windows -> Threads. You can Freeze and Thaw threads, and switch the active thread. This is awesome when debugging or replicating an issue with a multithreading application.
• You can drag & drop the yellow "Next Statement" arrow to another place. When the program resumes, it will resume execution at that statement. You can add it to the toolbar, a blue arrow called Set Next Statement, but it's not there by default.
• You can "undo" the navigation you did, like scrolling, going to another file, or jumping to a reference. The shortcut is ctrl-- (control minus.) That way you can jump into a function, examine the code there, and go back to where you were without looking.

Answer 7

Conditional breakpoints.

Answer 8

You can load windbg extensions into the Visual Studio debugger and use them from the immediate window.

Answer 9

As posted in another post Sara Ford is doing a current series on the VS debugger.

Her blog is the best source of VS tips: http://blogs.msdn.com/saraford/archive/tags/Visual+Studio+2008+Tip+of+the+Day/default.aspx

Answer 10

This is kind of an old one. If you add a watch expression err,hr, then this will hold the result of GetLastError(), formatted as an HRESULT (VC++ debugger only).

Answer 11

You can drag current line cursor (yellow arrow) up and down your code when execution is paused.

Additionally, in order to enable this during pause on exception you have to click "enable editing" on exception details first.

You can also make VS break on handled exceptions by checking one's of interest under: Debug->Exceptions : Thrown column

Answer 12

Some useful shortcut keys.

• F11 to step into a method.
• Shift-F11 to step out of a method.
• F10 to step over a method.

Answer 13

Things I use often:

• Click the menu item "Debug | Exceptions" (or Ctrl-D, E for short) and you can enable breaking at the time that any exception is thrown, or choose to not break on certain exceptions.

• You can set up the debugger to download some of the framework source code and symbols from a MS server and step into the framework code. (Some libraries, like System.ServiceModel, are not yet available). It in the Options windows under Debugging. See MSDN How-To.

• You can use the VS.NET debugger to debug Javascript running in IE. You just need to install the IE javascript debugger, and enable javascript debugging in IE's settings. Then on a JS error it will pop up a "do you want to debug" dialog box, and you can choose to debug in VS.NET.

Answer 14

You can open and place a breakpoint in a source file if the file belongs to another solution (external file). The debugger can still hit the breakpoint. No need to open another Visual Studio instance to debug the external file. Helpful in debugging web services which you source to. This works as long as all the sources are current and compiled.