Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / Languages / C++

Visual Studio Debugger Related Attributes Cheat Sheet

4.00/5 (3 votes)
13 Apr 2009Ms-PL2 min read 17.4K  
Visual Studio debugger related attributes cheat sheet

There are some debugger-oriented attributes in .NET, however 70% of developers don't even know that they exist and 95% of them have no idea what they do and how to use it. Today we'll try to shed light on what those attributes do and how to achieve the best of using it.

First of all, let’s define what we want to get from the debugger in VS:

TermWhat it actually does
Step IntoSteps into immediate child (that is what F11 does for standard VS layout)
image
Step OverSkips to any depth (that is what F10 does)
image
Step DeeperSteps into bypassing code, using certain attribute
Run ThroughSteps into, but only one level. All lower levels will be Stepped Over

Now, when we have our set of terms, we can learn what JMC means. It is not a famous whisky brand or another car company. It Just My Code option, checked in or out in “Option” dialog inside Visual Studio:

image

The next turn is for attributes, there are four (I know about) attributes, related to debugger and used by me for efficient programming: DebuggerHidden, DebuggerNonUserCode, DebuggerStepThrough and DebuggerStepperBoundary. We will use only three first. DebuggerStepperBoundary is the most secret attribute, which is related to debugging only in multithreaded environment. It used to avoid delusive effect, which might appear when a context switch is made on a within DebuggerNonUserCode applied. In other words, when you need to Step Through in Thread A and keep running at the same time in Thread B.

So let’s see the effects occurred when using those debugger attributes in case you are trying to Step Into place, this attribute is applied or set a Breakpoint there. When Just My Code (JMC) is checked, all those attribute behaviors are the same – they Step Deeper. However, when JMC is turned off (as in my picture), they begin to behave differently.

AttributeStep IntoBreakpoint
DebuggerHiddenStep DeeperStep Deeper
DebuggerNonUserCodeStep IntoStep Into
DebuggerStepThroughStep DeeperStep Into

As you can see, in this case:

  • DebuggerNonUserCode respects both for F11 (Step Into) and Breakpoints
  • DebuggerStepThrough respects only for Breakpoints
  • DebuggerHidden does not respect at all – just like when JMC is checked.

Bottom line: If you want people to manage whether or not to enter into your hidden methods – use DebuggerNonUserCode attribute. If you prefer them not to even know that those methods exists, use DebuggerHidden. If you want them to be able to put Breakpoints and stop on them, but keep running without explicit action – use  DebuggerStepThrough.

Have a nice day and be good people.  Happy friendly debugging to other developers.

Small bonus: To visualize your struct, class, delegate, enum, field, property or even assembly for user debugger, you can use DebuggerDisplay attribute (you need to put executable code into {} for example (“Value = {X}:{Y}”)]

Thanks to Boris for deep investigation.

License

This article, along with any associated source code and files, is licensed under The Microsoft Public License (Ms-PL)