Just My Code for C++ in VS 2013

Just My Code for C++ in VS 2013

Rate This
  • Comments 13

If you have experience debugging C# or Visual Basic code in Visual Studio, you are probably familiar with a debugging feature called Just My Code (JMC).  In Visual Studio 2013, we introduce Just My Code for C++.  In VS2013, the goal of this C++ JMC feature is to help the user focus on their code when viewing call stacks without getting lost in library code, Windows code, etc.

User Experience

When looking at a call stack, the debugger will collapse all consecutive frames of non-user code into an annotated frame labeled [External Code].  There is an exception to this, if the application is stopped in non-user code, then external code at the top part of the call stack will be shown.

Let’s start with the most basic example.  If you create a new Win32 Console application in Visual Studio 2012 (or in VS2013 with JMC turned off) and set a breakpoint on the first line, you will get the following call stack:

1basicstack

 To most users, only the top frame is really the only part that is interesting.  The Just My Code feature reduces the call stack to this:

 2basicstackjmc

 Just My Code does not just apply to the Call Stack window, but to anywhere call stacks are shown.  For example, you get these same benefits in the Threads window:

 3threads

 Or in the Parallel Stacks window:

  4parallelthreads

JMC can be extremely helpful in cases where there is a lot of library code that makes it difficult to find your own code.  Consider this example when debugging a Windos Store app.  The call stack is so unwieldy that you can’t see the user code you care about even when you un-dock the Call Stack window and expand it to its near maximum size.

5bigstack

Just My Code makes it much simpler to find your code so that you can navigate to it.

6bigstackjmc

 

Turning JMC off and on

If it turns out that if you do want to see the external code, you can use the context menu in the call stack window to toggle between showing and hiding external code.

7contextmenu

 When you turn this off, Just My Code will display the external call stack frames in a lighter gray color.

 8graystack

 If you want to turn Just My Code off completely, you can change the setting in Tools->Options.

  9toolsoptions

 Customizing Non-user code

 While there is a default experience for JMC out of the box, you can further customize it to your liking if you so choose.  Non-user code is defined in xml files with a .natjmc extension found in one of two locations.

 %VSINSTALLDIR%\Common7\Packages\Debugger\Visualizers

 %USERPROFILE%\My Documents\Visual Studio 2012\Visualizers

 These are the same locations that are used when processing native visualizers (natvis files). The default is settings are found in %VSINSTALLDIR%\Common7\Packages\Debugger\Visualizers\default.natjmc and provide a full illustrative example of how code is defined as non-user.

 xml 

As you can see, you can define code as non-user on three different levels:

  • By Module
  • By File
  • By Function

Name matching allows for the use of * and ? so that you can adequately cover lots of cases by only adding a single line of xml.  For modules, you can additionally include a company name, which will be matched against the company name included when the file was built.  For example, the line below will define modules in system32 as non-user code if they come from Microsoft.  However, if you install your own code into that directory, it will still be considered user code.

<ModuleName="?:\Windows\System32\*.dll"Company="Microsoft Corporation" />

Additionally, for files and functions, you can include a module name to make this more specific.  For example, line below will include RaiseException in kernel32.dll as non-user code, but will not include your function of the same name in a different binary.

<FunctionName="RaiseException"Module ="kernel32.dll"ExceptionImplementation="true" />

As mentioned earlier, the debugger will still show external code at the top of the stack when the application is stopped in that code.  The ExceptionImplementation attribute applies an exception to that rule to hide code that throws exceptions.

We would love to hear any questions or comments you have in the comments below or on our MSDN forum.

  • Can this be set as part of a project or solution?

    Alternatively, can it figure out some sane defaults of the definition of "my" code based off of the include / library path?

    The approach you mention appears to be a "black list".  Can there also be a "white list" / <UserCode> tag?

    Does the NonUserCode tag affect the behavior of "Step Into", so that I don't step into code that isn't mine?

  • Ditto on Ben's question about "Step Into".

  • Very nice feature... so long as devs are responsible, over in C# land I often see the equivalent feature abused by devs who view it as the Not My Problem option.

  • @Ben Craig and thebanjomatic,

    Thanks for sending your feedback.  While this feature is not integrated with stepping, there is a feature in Visual Studio that helps you define what functions to not step into.  In the same directory as the .natjmc files, you will find .natstepfilter files that you can use to get this behavior.

  • @Ben Craig

    Thanks for the feedback.

    Currently, there isn't a way to include this as part of a project or solution.  There also isn't a "white list" of use code at this time.

    Could you expand on what you would like to see with the include / library path?

    Thanks!

  • RE: include / library path comments.

    An intuitive definition of "my code" would be everything that is in my solution.  If that definition is useful, then it would make sense to blacklist all of the static / dynamic libraries that get pulled in from outside the solution.  It would also make sense to blacklist the include paths that point outside of the solution.

    It could also be that this intuitive definition plays out horribly in real life, but I really don't know.

  • To expand on Greg's comment -- it would be extremely nice when debugging not to step into things like std::function, and similarly to see stuff like that treated as "external" code, even though it is technically internal to the current solution.

  • This looks great. I hope to be using it soon.

    It looks like there is only one External Code tag. As an enhancement would it be possible to have additional tags?

    I work on a large legacy Fortran/C/C++ application with several projects, but most of the new work is done in C++. I would like to exclude my Legacy code, but have it show up as "Legacy Fortran", "Legacy C", or "Legacy C++" instead of "External Code". Also, there should be an ability to expand out these sections independently from each other.

    I’ll still use the feature as is but this additional enhancement would make it even better.

  • Cool part about native visualizers. Will VS2013 use natvis, natstepfilter and natjmc files from NuGet C++ package?

    I want distribute library package with native visualizers.

  • I wish that Visual Studio supported stepping through KiUserExceptionDispatcher and the unhandled exception filter.  Right now, it's really hard to debug crash handlers. >.<

  • @Arkadiy Shapkin

    There is not currently a solution to distribute via NuGet.  There is however a sample that shows how to deploy natvis via vsix package.

    code.msdn.microsoft.com/.../Writing-type-visualizers-2eae77a2

  • @Brad Sullivan

    Thank you. I know. This my extension visualstudiogallery.msdn.microsoft.com/c7e02633-86d9-4262-b745-6cc647afb3a8

    Natjmc file can be distributed in vsix package? If so, what type should be in vsixmanifest for that file?

  • One suggestion:  I think I usually would like to see one level into external code; that is, I want to see the external function that my code calls, because that level is visible to me and relevant to understanding what my code is trying to do.  External stack frames called by external code, on the other hand, are (usually) implementation details of the external code, and therefore not interesting.

    I'll also +1 for the ability to store these (and other visualizers) as part of a project or solution.  It's currently a real pain to try to deploy custom visualizers across a development organization.

Page 1 of 1 (13 items)