Introductions, ICorDebug + CLR Debugging Services
My name is Mike Stall, and I'm a developer on the CLR (also called the .NET runtime and a host of other names). I currently work on the CLR Debugging Services along with some other folks. We design and implement the managed debugging API exposed by the CLR and consumed by managed debuggers (like Visual Studio.NET) to allow them to debug managed applications. This API is called ICorDebug, and it's implemented in mscordbi.dll (I had to mention those terms for the search engines ;) ). We don't actually design the debuggers (except for Cordbg...), and so I'd guess we have at best a very indirect impact of the developer community.
I'd expect the audience interested in the CLR debugging services to be extremely small, so I'm not exactly sure what I'll actually blog about, but I'll see as it goes. Some potential posts may include:
- managed debugging design issues. For example, comparing managed-only debugging to native-only debugging.
- code snippets for doing something useful (like a simple harness that traces module loads)
- random comments from various .NET pet projects I do. For example, I recently tried writing a syntax-hilighted version of notepad with winforms and ran into some "interesting" problems.
- other random CLR / .NET observations I come across.
- observations about how the debugging API influences the debuggers.
- stuff about Interop (aka Mixed-mode) debugging. How does it work and why is it so broken in V1.1? (We think we've made great progress on this for V2.0)
- other random stuff that comes to mind.
- anything that readers may prompt me on (so jump on in!)