Problems for a managed debugger for v1.1?

Long live MDbg » Advanced .NET Debugging

Long live MDbg » Advanced .NET Debugging — Fri, 12 Jan 2007 12:05:04 GMT

PingBack from http://dotnetdebug.net/2005/08/15/long-live-mdbg/

MDbg Linkfest

Mike Stall's .NET Debugging Blog — Thu, 23 Nov 2006 06:12:02 GMT

MDbg is a debugger for managed code written entirely in C# (and IL), which started shipping in the CLR

How to build Mdbg apps

Mike Stall's .NET Debugging Blog — Wed, 28 Jun 2006 17:54:57 GMT

I often publish little samples in this blog based off MDbg (which generally show off the debugging services...

Mike Stall's .NET Debugging Blog : MDbg Linkfest

Mike Stall's .NET Debugging Blog : MDbg Linkfest — Mon, 19 Jun 2006 09:49:02 GMT

PingBack from http://blogs.msdn.com/jmstall/archive/2005/11/08/mdbg_linkfest.aspx

Managed Debugger Sample

Mike Stall's .NET Debugging Blog — Fri, 11 Feb 2005 20:38:00 GMT

How to get a V2.0 ICorDebug object

Mike Stall's .NET Debugging Blog — Sun, 16 Jan 2005 01:02:00 GMT

re: Problems for a managed debugger for v1.1?

Mike Stall — Sun, 07 Nov 2004 09:24:00 GMT

Suppose QI IA --> IB works, but there's a bug where QI IB-->IA fails.

You need to change how MDbg uses IA and IB, but yes, I think that could be made to work.
MDbg would only persist the IA interface. Whenever it needed the IB interface, it would QI IA --> IB, use IB, and then throw IB away. Thus it would never have to go IB-->IA, and life would be fine.

I think that's effectively what you're proposing (though perhaps you cache the IB along w/ the IA so that you don't have to keep repeating the QI).

re: Problems for a managed debugger for v1.1?

Sam Saffron — Fri, 05 Nov 2004 12:40:00 GMT

It may be a little naive, but couldnt you just write a COM object that exposes all the methods in IA and IB and call that from the managed code, that way you do not have to flick between interfaces ... a big aggragate com component to do everything ....

re: Problems for a managed debugger for v1.1?

Mike Stall — Thu, 04 Nov 2004 19:12:00 GMT

1) We've actually played around with the unmanaged "classic" dll because we want to get MDbg to run on Rotor (which doesn't support COM-interop). This is actually surprisingly difficult, but feel free to play around and give it a try!
The problem with the QIs is not that we leak references, it's that if QI's neeed to be "stable". Eg, if we have an IA interface to some object, and then we QI for IB, we need to be able to cal QI on that IB instance to get back the IA instance. Eg, go IA --> IB --> IA. We have bugs in our QI that prevent that.

2) Decompiling - It should be pretty feasible. The Debug API operates at the IL-level anyways (see http://blogs.msdn.com/jmstall/archive/2004/10/03/237137.aspx) The MDbg sample already includes an IL disassembler. The only remaining trick is to hook up your favorite disassembler to MDbg on top of the IL-disassembler example.
You wouldn't need any EnC/reflection goo - the ICorDebug APIs provide fully stack tracing functionality.

re: Problems for a managed debugger for v1.1?

sam saffron — Thu, 04 Nov 2004 13:12:00 GMT

Regarding 1. Couldnt you just write an unmanaged "classic" dll that wraps the problem COM calls. then access using standard interop. Also, I thought the Marshal.ReleaseCOMObject could be uses to free up the hanging QIs

Whats the feasability of adapting MDbg to do de-compiling on the fly? ala reflector. In 2.0 using E&C id assume you cound inject some reflection calls to get a proper stack trace and then use pattern matching to de-compile (if not provided by the debugger interfaces).