What would be an example usage of DebuggerStepperBoundaryAttribute?

Question

I'm familiar with the DebuggerHiddenAttribute and the DebuggerStepThroughAttribute. Today I noticed the DebuggerStepperBoundaryAttribute, and if I understand it correctly, if you attempt to F10 over a property (or method or whatever) that has that attribute, it will turn into an F5.

Use the DebuggerStepperBoundaryAttribute to escape from stepping through code to running code. For example, in Visual Studio 2005, encountering a DebuggerStepperBoundaryAttribute while stepping through code using the F10 key (or Step Over command) has the same effect as pressing the F5 key or using the Start Debugging command.

I can't think of an example that this would be useful/helpful. So either my understanding is wrong, or I can't think of a good example of how it would be helpful. What would be an example usage of DebuggerStepperBoundaryAttribute that would be useful/helpful?

Answer 1

Here is a simple Test Program (Enable Just My Code, and put a break point on lines Test 1,2,3, & 4) referred to below:

class Program
{
    static void Main(string[] args)
    {
        TestDebuggerStepperBoundary();                        // Test 1
        Test();                                               // Test 2
        TestDebuggerNonUserCode(TestDebuggerStepperBoundary); // Test 3
        TestDebuggerNonUserCode(Test);                        // Test 4
    }

    [DebuggerNonUserCode]
    private static void TestDebuggerNonUserCode(Action action) { action(); }

    [DebuggerStepperBoundary]
    private static void TestDebuggerStepperBoundary() { SomethingHorrible(); }

    [DebuggerNonUserCode]
    private static void Test() { SomethingHorrible(); }

    private static void SomethingHorrible()
    {
        var foo = "bar";
    }
}

After reviewing the definition for DebuggerStepperBoundaryAttribute, I don't think the definition is quite right:

The DebuggerStepperBoundaryAttribute attribute is used as an escape from the effect of a DebuggerNonUserCodeAttribute.

You can use the DebuggerStepperBoundaryAttribute without being in the context of the DebuggerNonUserCodeAttribute. F11 on Test 1 immediately hits the next breakpoint on Test 2, without being in the "effect of a DebuggerNonUserCodeAttribute". I think this should really read "The DebuggerStepperBoundaryAttribute attribute is used as an escape from the effect of Step Into or Step Over while debugging." The rest of the defintion makes sense:

When executing within the boundaries of the DebuggerNonUserCodeAttribute, designer-provided code is executed as a step-through until the next user supplied code is encountered. When context switches are made on a thread, the next user-supplied code module stepped into may not relate to the code that was in the process of being debugged. To avoid this debugging experience, use the DebuggerStepperBoundaryAttribute to escape from stepping through code to running code. For example, in Visual Studio 2005, encountering a DebuggerStepperBoundaryAttribute while stepping through code using the F10 key (or Step Over command) has the same effect as pressing the F5 key or using the Start Debugging command.

So to answer my question, if there was some other code that you were to call, that you are unable/unwilling to add DebuggerStepThrough, DebuggerNonUserCode, or DebuggerHidden to, but if the debugger entered the method would be more jarring than going from stepping the code to running the code, then use the DebuggerStepperBoundaryAttribute. (In my example program, F11 on Test 2, takes you directly to SomethingHorrible, which is potentially worse than going straight to running(F5)) It was added explicitly added Context Switching of Threads, and outside of that, I am unaware of any situation that it would be useful.

Answer 2

[DebuggerStepperBoundary] literally means there is a debugging boundary. the debugger will usually jump over this (no matter how much you love StepInto), BUT IT DOES ALLOW you to put a breakpoint, and in that case, it will break. But the usual behavior will be to jump over this function (run through).

[DebuggerStepThrough] this means you can NEVER break in here. if you try to put a breakpoint it will appear disabled as long as "Just My Code" is selected. usually used for Properties and linq and such

When would you use this:

I have an app that uses user32.dll to send keystrokes to a certain app. I put DebuggerStepThrough on 90% of these functions as they have no affect if they are broken into. They need to run as a whole.

Hope this answers your question