BlackWaspTM

This web site uses cookies. By using the site you accept the cookie policy.This message is for compliance with the UK ICO law.

Debugging
.NET 1.1+

Hiding Code from the Debugger

Sometimes stepping through properties and methods gives no benefit to a developer who is trying to debug some software. In these situations it can be useful to hide code from the debugger so that it is stepped over automatically.

DebuggerStepThrough Attribute

When you are debugging your software by stepping through the code, some methods, properties and even entire classes add noise and complicate the debugging unnecessarily. Sometimes it is more useful to hide a member or type from the debugger completely. The .NET framework provides some attributes that you can apply for this purpose.

The first attribute we'll look at is DebuggerStepThrough. You can add this to a method, constructor, structure or class. If you do, when you attempt to step into the decorated code, the debugger steps over it instead.

If a breakpoint exists within a section marked with DebuggerStepThrough, the breakpoint is ignored. If a breakpoint is added to some code that is not decorated with the attribute, but that code is called by a hidden member, the breakpoint will operate as normal. However, the hidden method will not be displayed in the Call Stack window; you will see only, "External Code" where it would normally be shown.

To demonstrate, create a new console application. As the attribute is found in the System.Diagnostics namespace, include the following using directive wherever you add the attributes.

using System.Diagnostics;

Complete the code by modifying the Main method and adding some extra methods as follows. Note the use of the DebuggerStepThrough attribute on the DoSomething method but not on DoSomethingElse, which it calls. Set two breakpoints at the positions shown in the comments.

static void Main(string[] args)
{
    DoSomething();
}

[DebuggerStepThrough]
public static void DoSomething()
{
    Console.WriteLine("Can't stop here!");  // Breakpoint
    DoSomethingElse();
}

private static void DoSomethingElse()
{
    Console.WriteLine("Can stop here!");    // Breakpoint
}

The DoSomething method is now effectively unavailable to the debugger. If you run the program, the first breakpoint will be ignored because it resides within a member decorated with the attribute. The second breakpoint will pause the debugger but the call stack will not include information about the DoSomething method.

DebuggerHidden Attribute

The DebuggerHidden attribute operates in a similar manner to DebuggerStepThrough. Although it cannot be applied to classes or structures, it can be added to properties and indexers. Again, breakpoints within a decorated method will be ignored. However, when using DebuggerHidden, the member is completely hidden from the stack trace, as if it did not exist.

Try changing the code as shown below and running the program again to see the difference.

static void Main(string[] args)
{
    DoSomething();
}

[DebuggerHidden]
public static void DoSomething()
{
    Console.WriteLine("Can't stop here!");  // Breakpoint
    DoSomethingElse();
}

private static void DoSomethingElse()
{
    Console.WriteLine("Can stop here!");    // Breakpoint
}
19 August 2013