Breaking changes in ICorDebug from 1.1 to 2.0.

Here are some random notes about specific ICorDebug breaking changes between .NET v1.1 (Everett) and .NET 2.0 (Whidbey). (I came across these as I was cleaning out old documents in preparation for my upcoming move). This would have been more timely 2 years ago, but better late than never. This can be viewed as the…

0

Making Catch, Rethrow more debuggable.

I previously mentioned that catch / rethrow an exception impedes debuggability because the callstack is unwound at the catch block, and thus you lose the callstack in the debugger.  On technique to fix this is to take advantage of Just-My-Code ,which was added in .Net 2.0 (whidbey).  JMC lets you mark each function as “my…

3

VS 2003 can not debug .NET 2.0 apps.

Somebody asked here on the forums if you can use VS 2003 to debug .NET 2.0 (whidbey) apps. Unfortunately, the answer is no.VS 2003 can not debug .NET 2.0 apps.  It is a restriction in the underlying .NET debugging services (see below)You can still use the .NET 2.0 SDK tools (such as Mdbg, DbgClr) to…

6

VS2005 ships!

As you’ve probably already heard by now, VS2005 has shipped!  I’ve been using VS2005 for a while now (afterall, MDbg only runs on CLR 2.0). Since I’ve been so involved in V2.0, I had forgotten how many people are still on V1.1 and V1.0. (update: fixed grammar error) The debugger has a lot of great new…

4

ICorDebugStepper and using ICorDebugStepper2::SetJMC

We added Just-My-Code (JMC) stepping (the ability to step through just your code and skip code that’s not yours) in Whidbey. I blogged a demo from the end-user’s perspective here. In response to some email, I wanted to talk a little more about how a debugger can implement JMC from the ICorDebug level. Stepping basics:Managed…

4

Debug support for arbitrary state-machines

I mentioned here  that if your language compiles to IL, then you get free debugging support with Visual Studio (and other managed debuggers).But what if you have an interpreter that can’t compile to IL? For example, suppose you load some state machine via an xml file, and then an interpreter reads in the xml file…

8

Managed Debugging doesn’t support Fibers

Although managed-debugging definitely supports multi-threaded debuggees, it does not support debugging processes with fibers.   The V2.0 CLR provides fiber support, however the ability to debug fiber-mode applications was cut. There are a few reasons that you don’t get fiber-mode debugging for free: 1)      Fibers confuse certain CLR operations like the cooperative synchronization. (See steps…

9

Why you can’t do Edit-and-Continue on Dynamically generated code

I gave a brief example of how you can debug dynamically generated code (e.g., code generated via Reflection.Emit). Jamie Cansdale observed that you can’t use EnC with dynamically generated code. This was a conscious choice. Here are some reasons for it:   It was not a core EnC scenario. For v2.0, we wanted to focus…

4

How to get a V2.0 ICorDebug object

I think the biggest breaking change in the ICorDebug API is how we deal with versioning. Managed debugging is done via the com-classic ICorDebug interface.   In v1.0/v1.1, you cocreate to get an ICorDebug implementation, like so:           ICorDebug * cor;         hr = CoCreateInstance(CLSID_CorDebug, NULL,                               CLSCTX_INPROC_SERVER,                               IID_ICorDebug,                               (void **)&cor);  …

10

Code Gen flags while Debugging

I ranted here that Debuggers shouldn’t affect behavior. V1.1 had some fundamental violations of this regarding code-gen. We’ve fixed this in v2.0 ICorDebug. This includes: 1)       Ensuring that the mere presence of a debugger doesn’t affect codegen flags. Eg, in v1.1, if a debugger was attached, we’d jit the code differently (such as disabling optimizations)…

11