Is ‘Just my Code’ for you?


The debugger has a new feature this time around called ‘Just my code’. This is a new-for-Whidbey managed debugging feature.


Philosophy of Just my code:
The basic idea is that when you debug an application, you want to debug the code in the application, and not all the code that is in the Framework. Specifics:



  • If you step into some non-user code (say the Framework), and that non-user code invokes your callback, you want to step into the callback, not step into the Framework

  • If you step out of your code, you don’t want to step into all that glue code, you want to break on your next event handler.

  • If an exception is thrown and caught in someone else’s code. You don’t care.

  • If your code failed to catch an exception, then you don’t want to let it get swallowed by some big exception filter that a bad person has installed.

  • Sometimes you want to break when an exception is thrown, but not every exception. You only care when your code throws the exception.

What does the debugger consider ‘your code’?



  • If the code is compiled optimized, it is not your code

  • If you don’t have symbols, it is not your code

When we were first coming up with this feature, I was thinking that this feature would be helpful to everyone. After all, everyone at least occasionally has the experience where code written by someone else gets in the way of debugging a problem in your code. However, after playing with the feature for a while, I have changed by mind. It’s a great feature if you want a simplified debugging experience. However, that isn’t me. If you are a hard core dev, do yourself a favor and turn the feature off (Tools->Options->Debugging->General->Just My Code).


Also, one technical note for those who like the feature – if exceptions pass out of user code and are swallowed by certain parts of the Runtime (not the framework), the debugger will not be given a chance to break on the exception. The CLR is working to address this problem, but it is a difficult problem to solve. In Beta 1, one such location is the reflection engine.


Comments (10)

  1. ShadowChaser says:

    This problem happens the other way too – occasionally you cannot debug your own code!

    Try this:

    * Create a solution with two projects

    * Create a custom control in one project

    * Compile the control project

    * Add the new control to the toolbox using browse (to the release or debug build dll of the user control project). There is no other way to use the control! (I’m talking about inherited controls, not user controls. User controls *occasionally* show up in the toolbox by themselves)

    * Open the second project, and drop the control onto a form.

    * Place a breakpoint somewhere in the control project, ie/ the constructor

    * Run the application (the one with the form). The breakpoint never gets hit, even though the DLL for the control is in the solution..

    A tricky problem, but a very frustrating one for developers who program "private" custom controls for their applications.

  2. Gregg Miskelly says:

    I don’t know why that would be. What does the modules window say for your control?

  3. ShadowChaser says:

    When I run the entire solution (including the controls) I get the following modules:

    mscorlib.dll

    HealthSpace.EhsManager.DesktopClient.exe

    system.dll

    healthspace.ehsmanager.desktopclient.core.dll

    system.xml.dll

    system.windows.forms.dll

    healthspace.data.dll

    healthspace.ehsmanager.businesslogic.dll

    purecomponents.navigator.dll

    system.drawing.dll

    dotnetwidgets.dll

    documentmanager.dll

    microsoft.visualbasic.dll (we use C#! probably a 3rd party control.. 😉

    activereports.dll

    activereports.viewer.dll

    dundaswinchart.dll

    healthspace.ehsmanager.desktopclient.plugins.foodui.dll

    healthspace.ehsmanager.desktopclient.plugins.mainui.dll

    healthspace.errorreporting.dll

    healthspace.visualcontrols.dll (the one that won’t debug)

    janus.windows.common.dll

    janus.windows.explorerbar.dll

    janus.windows.gridex.dll

    system.data.dll

    system.enterpriseservices.dll

    system.enterpriseservices.thunk.dll

    Bear in mind that it won’t debug in 2003 – I don’t have a full beta 1 install of 2005 in virtual pc yet – just C# express at home.

    I always assumed that it never could debug because I manually browsed to the .dll when adding the controls to the toolbox.

    If you need any more information you can contact me at ebickle (at) healthspace.ca

    Thanks!

  4. Greg Ennis says:

    The problem is that VC# Express 2005 does not have the option to turn this feature off. So everytime I start the debugging session I get a warning about "Just My Code", complete with instructions to turn it off by navigating to a non-existent configuration dialog. Kind of annoying.

  5. Ryan Dorrell says:

    How about the ability to specify what namespaces you step into while debugging instead? Something like:

    System.Xml.* [NO]

    System.Windows.Forms.* [YES]

    MyNamespace.Objects.* [YES]

    ThirdParty.Object.* [NO]

    I’ve seen a similar feature to this in some Java IDEs.

  6. Gregg Miskelly says:

    Greg: I will try and find out why C# express doesn’t have an option for this. You can always use the ultimate options editor — regedit.

    HKEY_CURRENT_USERSoftwareMicrosoftVCSExpress8.0DebuggerJustMyCode = 0

    BTW: What are you doing that you have a project that is optimized or doesn’t have a PDB?

  7. Ryan: Good feadback. I decieded to post a seperate blog topic about customizations (http://blogs.msdn.com/greggm/archive/2004/07/30/202436.aspx)

  8. Gregg Miskelly says:

    Greg,

    I talked to some coworkers about your problem. I found out two things:

    1) There is aparently a bug where sometimes the warning comes up when it shouldn’t. We are still tracking down why.

    2) There is a button in tools options to show all options, if you click this, there should be an option to turn off just my code.

  9. I would recommend something like this for profiling as well. It’s difficult to profile a windows program when it’s taking up most of it’s time in a Windows look, but the choke point is somewhere in my code.