What's new in v2.0 CLR Debugging (ICorDebug)?

  • Article

The CLR debugging services have added a lot of great things in v2.0. The main theme for us has been improving the Rapid Application Development (RAD) experience. Here’s a list of new features:

1) Edit-And-Continue. EnC is the ablity to edit code while it is being debugged without having to restart the debugging session. Both VB.Net + C# are supporting this, and any 3rd-party debugger could too.

2) Just-My-Code debugging. JMC is the ability to debug just the code you’re interested in without getting sucked into debugging 3rd-party library code that you don’t care about. This includes stepping through just your code and filtering exceptions in just your code.

3) Object identity. Object Identity is the ability to ‘tag’ objects found while inspecting and then instantly pull them up later by their tag without having to refind them. We’ve provided object identity for managed code objects, similar to the ‘this’ pointer in native code.

4) Interceptable exceptions. You can now stop an exception in midflight and resume executing code up on the stack, even when there’s not a catch block. It’s like SetIp for exceptions.

5) The mere presence of a debugger doesn’t affect code-gen anymore. In v1.1, the mere presence of a debugger affected codegen (jitted as debuggable). Debuggers shouldn’t affect behavior. We’ve fixed this. Part of this is making sure that jit-debug maps are always tracked. This is a major step forward in the sorry story of debugging retail managed code. Tinkering with .ini files to track debug info is no longer necessary. See here for details.

6) Fit & Finish: We’vefilled a few small holes in the debugger API, such as providing a way to find out how assemblies got resolved and inspecting GC handles.

7) Versioning: We avoided the debugger versioning problem in v1.1 by making v1.1 and v1.0 debugging interfaces completely interchangable (you’ll notice that cordebug.idl doesn’t have any changes between 1.0 and 1.1). This was feasible since we didn’t add any new features to v1.1. For v2.0, we’ve added full fledged debugger versioning support. See here for more details.

8) Managed Debug Assistants (MDAs) : [update:11/10/05] MDAs are useful checks in the core CLR to catch certain problems like running code under the loader lock or having a bad pinvoke signature. We've added first-class support for MDAs into the managed debugging APIs. See here for details.

(I expect to blog about these things in the future. As I do, I’ll come back here and add pertinent links).

We also spent a lot of time on certain infrastructure and stability issues.

- make ICorDebug a much better com-citizen. This was a requirement to use com-interop on the API, and thus enable MDbg.

- Improved func-eval abort (which translates to less hangs when func-evalling properties)

- much more stable (read: significantly less deadlocks) and faster interop-debugging.

 

Although this is all from the CLR perspective, rest assured that Visual Studio 2005 will take advantage of all of these new features.

 

I’d love to know what sort of functionality users would like in the next version.

[Update 7/13/05: Here are new things throughout the rest of .Net 2/VS2005: https://msdn2.microsoft.com/en-us/library/t357fb32.aspx ]

Comments

  • Anonymous
    January 04, 2005
    I am developing an eCommerce website using the UIP application blocks and found that the IDE makes use of some caching of the project files.
    It's sometimes annoying, especially when the cache does not get refreshed, and I have to restart the IDE to successfully build my files. It would be great if we could have an option to clear the IDE cache.


    Thanks
    Shailen Sukul

  • Anonymous
    January 05, 2005
    What I need help with is diagnosing problems with deployed Windows services. It would be helpful to be able to start a monitoring application which gives visibility into executing threads: what they been doing and where they’re at (mapped back to the source code), how long they’ve been doing it, exceptions, etc. This needs to be done without stopping any threads or seriously impacting performance. Right now we try to achieve this through EIF logging, and it’s pretty clumsy.

    Also, since some administrators don’t like this sort of tool lying around on production servers, I would be helpful if this could be done either remotely or by dropping in a single executable, which could easily be pull off once the problem is solved.

    Thanks for all the hard work on a great tool!

  • Anonymous
    January 06, 2005
    Douglas - your description of "monitoring" sounds very close to debugging (but without the debugger ever actually stopping). Eg, you could set breakpoints, but they would only record that they were hit without actually stopping the shell?
    The good news is that sounds like a tool that any 3rd-party could write today. No need to wait for v3 of the CLR ;)

  • Anonymous
    January 07, 2005
    Are there any plans to provide a managed interface to the debug services in v2.0 FCL?
    I used to code unmanaged C++ all the time, but I forget how!

  • Anonymous
    January 07, 2005
    Sam - We are planning to ship MDbg in v2.0 CLR (starting with Beta 2), and that has a set of managed wrappers.

  • Anonymous
    January 10, 2005
    will all the apis needed by a 3rd party debugger to implement enc be in beta2? The beta1 cordebug.idl deprecated the old interfaces without but didn't seem to provide the new ones.

  • Anonymous
    January 10, 2005
    Alastair - the new EnC Apis are actually already in Beta 1. Beta 1 VB.Net supports EnC).
    Check out ICorDebugModule2::ApplyChanges. The MDbg sample actually contains a primitive EnC extension dll to let you manually do Enc (we use it internally for some EnC unit testing).

  • Anonymous
    January 18, 2005
    One thing that would be very useful, is a "break in this instance only" type of breakpoint. Sometimes (well often) you want to break when a method is called but only in a specific instance of the class. In C++ you can set it through a conditional but is a PITA. It would be really cool to have a "Insert breakpoint for this instance" option in the debugger context menu that would set it up correctly.

  • Anonymous
    August 23, 2005
    We added Just-My-Code (JMC) stepping (the ability to step through just your code and skip code that's...

  • Anonymous
    August 27, 2005
    At this point, I've got what seems to be an endlessly long list of things I'd like to eventually blog...

  • Anonymous
    March 24, 2006
    In case you haven't already heard from every other blogger (like Shawn, JasonZ and Brad) , V2.0 of the...

  • Anonymous
    July 20, 2006
    During native debugging, it's common to cast a raw pointer value to a given type. Eg, in the expression...

  • Anonymous
    November 07, 2006
    Microsoft has some great binary patching tools. In my simple tests they're over twice as size efficient

  • Anonymous
    December 27, 2006
    When you attach to a managed debuggee (via ICorDebug::DebugActiveProcess), ICorDebug generates a set

  • Anonymous
    February 12, 2007
    I previously mentioned that catch / rethrow an exception impedes debuggability because the callstack

  • Anonymous
    July 04, 2007
    Debugging MC++ apps from VC2002 with VS2005 came up in the comments here . In the ideal world, Whidbey

  • Anonymous
    December 03, 2007
    Dan Mosely recently posted a feature poll on the MSBuild blog . Here are the results . Debuggability