Now that we’ve released a managed debugger sample for V2.0, people commonly ask “What about v1.1?”. I briefly touched on this when in a comment in the original MDbg post (http://blogs.msdn.com/jmstall/archive/2004/09/30/236281.aspx#245499). Here are more details:
In theory, it’s doable, but there are some hurdles. Here are the biggest problems to back-porting MDbg to v1.1:1) CLR Bugs: The v1.0 / v1.1 ICorDebug implementations have ref-counting + QI bugs in our COM-classic implementations that will break COM-interop (perhaps we can fixing these in a service pack). For example, we break the QI rules for roundtripping around ICorDebugFrame, ICorDebugILFrame, and ICorDebugNativeFrame. So any v1.1 managed debugger may be doomed. COM-interop excercises these rules more aggressively than the unmanaged debugging, so these bugs weren't an issue in v1.1 because our only clients were unmanaged. In theory, if we had a comprehensive list of these defects, a managed debugger could do acrobatics to compensate for them (such as avoiding certain casting operations to avoid the underlying QI). I’m not sure if this is even possible in practice. Creating MC++ wrappers would be one way to get around these.2) MDbg uses Whidbey functionality, such as generics. Most of MDbg was written early in whidbey, so it was really targeting the v1.1 feature set and does not use v2.0 features extensively. This is probably the easiest thing to port. 3) The metadata versioning issue. (http://blogs.msdn.com/jmstall/archive/2004/10/30/250007.aspx). ICorDebug specifically uses the CLR coclasses, so even if you implement your own metadata implementations that avoid the versioning issue, ICorDebug won’t pick them up. If you only debug v1.1 apps, this won’t be an issue. Now this is only an issue if you wanted the v1.1 MDbg to debug v2.0 apps.
A debugger also needs to user other unmanaged APIs (CorPub.idl, CorSym.idl), but these can be wrapped for managed code without serious caveats.
All in all, it may be possible. Once the above issues are out of the way, the problem simplifies into just writing yet another managed application.MDbg is a publicly available sample, so folks are welcome to play around with it and experiment with things like porting it to v1.1. We'd love to hear about it (either replies on this blog, or comments to mailto: clrmdbg AT microsoft.com)