Cet article est disponible en francais.
The “Just My Code” feature has been there for a while in Visual Studio. Since Visual Studio 2005 actually. And it's fairly easy to miss its details...
High level, this feature only shows you the stack that contains your code, mostly those assemblies that are in debug mode and have debugging symbols (pdb files). Most of the time, this is interesting, particularly if you’re debugging fairly simple code.
But if you’re debugging somehow complex issues, where you want to intercept exceptions that may be rethrown in some parts of the code that are not “Just Your Code”, then you have to disable it.
If you’re an experienced .NET developer, chances are you disabled it because it annoyed you at some point. I did, until a while back.
Debugger Exception Handling
The “Just my Code” (I’ll call it JMC for the rest of the article) feature changes a few things in the way the debugger handles exceptions.
If it is enabled, you’ll notice two columns in the “Debug / Exceptions” menu :
- Thrown, which means that if you check that box, the debugger will break on the least deep rethrow in the stack of the exception
- User-unhandled, which means that if you check that box the debugger will break if the exception has not been handled by any user code exception handler in the current stack.
If it is not enabled, then the same dialog box will display one column :
- Thrown, which means that the debugger will break as soon as the exception is thrown
You’ll probably notice a big difference in the way the debugger handles the “Thrown” option. To be a bit more clear about that difference, let’s consider this code sample :
static void Main(string[] args)
{
try
{
var t = new Class1();
t.Throw();
}
catch (Exception e)
{
Console.WriteLine(e);
}
}
Main executable, in debug configuration with debugging symbols enabled
public class Class1
{
public void Throw()
{
try
{
Throw2();
}
catch (Exception e)
{
throw;
}
}
private void Throw2()
{
throw new InvalidOperationException("Test");
}
}
Different assembly, in debug configuration without debugging symbols.
If we execute this code with the debugger with JMC enabled and with the “Thrown” column check for “InvalidOperationException”, here is the stack trace :
NotMyCode.dll!NotMyCode.Class1.Throw() + 0x51 bytes
> MyCode.exe!MyCode.Program.Main(string[] args = {string[0]}) Line 15 + 0xb bytes
And here is the stack trace without the JMC feature :
NotMyCode.dll!NotMyCode.Class1.Throw2() + 0x46 bytes
NotMyCode.dll!NotMyCode.Class1.Throw() + 0x3d bytes
> MyCode.exe!MyCode.Program.Main(string[] args = {string[0]}) Line 15 + 0xb bytes
You’ll notice the impact of the “least deep in the stack rethrow”, which means that if you enable JMC, you will not have the original location of the exception.
Then you may wonder why it may be interesting to have the original location of the exception in the debugger. It is a debugging technique that is commonly used to find tricky issues that throw exceptions deep in code you do not own, and one of these exceptions is often TypeInitializerException. It can be useful to break at the original location to have the proper context, or stack that lead to the exception.
Lately, I’ve been using this technique of “Break on all exceptions” without JMC to troubleshoot loading of 32 bits assemblies in a 64 Bits CLR. You don’t exactly know which exception you’re looking for in the first place, and having JMC “hiding” some exceptions is not of a great help.
Also, to be fair, a more deep and intense debugging often leads to the use of WinDBG and the SOS extension (and here is a good SOS cheat sheet). But that’s another topic.
Step Into “Debugging Experience” with JMC
If you’ve read this far, you may now ask yourself why you would ever want to enable JMC. After all, you can handle your code yourself and with enough experience, you can easily mentally ignore pieces of the stack that are not yours. Actually, the gray font used for code that does not have debugging symbols helps a lot for that.
Well, there’s one example of good use of JMC : The debugger “Step into” feature. A very simple feature that allows step by step debugging of the software.
If you’re in debugging mode, you’ll step into the code that is called on the next line, if that’s possible, and see what’s in there.
So demonstrate this, let’s consider this example :
static void Main(string[] args)
{
var myObject = new MyObject();
Console.WriteLine(myObject);
}
class MyObject
{
public override string ToString()
{
return "My object";
}
}
This is a very simple program that will use the fact that Console.WriteLine will call the ToString method on the object that is passed as a parameter.
The point of this sample is to make “My Code” (Main) call some of “No My Code” (Console.WriteLine) that will call “My Code” (MyObject.ToString). Easy.
Now if you run this sample with the debugger with JMC disabled, if you try to “Step Into” Console.WriteLine, you’ll actually step over. This is not very helpful from the point of view of debugging you own code.
A very concrete example of that lack of “Step Into” can be found when you have proxies like the ones found in Spring.NET or Castle's DynamicProxy, they get in the way of simple debugging. You can’t step into objects that have been proxied to perform some AOP, for instance.
But if you enable JMC, well, you can actually “Step Into” your own code, even if the next actual method when you step into was not one of yours.
Final Words
Using JMC in this context is very useful and natural I would say. And the feature has been there for so long I missed its original goals. It originally got into my way for deep debugging purposes, and I dismissed as a “junior” feature, even cosmetic. Well, I was wrong…
Anyway, in Visual Studion 2010, the JMC has been improved a bit, as the way to enable and disable it is now far more easier to reach because it is now in the IntelliTrace “Show Calls View”.
Time to switch to Visual Studio 2010, people ! :)