Using metadata interfaces from managed code

The metadata APIs are unmanaged COM-classic interfaces declared in Cor.h in the SDK. (look for IMetaData* ). In this blog entry, I’ll wander over some random trivia about trying to use the metadata interfaces from managed code. We run into this from the debugging side because the debugging interfaces are intimately related to the metadata…

7

David Notario, JIT guru, is blogging

David Notario, a dev on the CLR JIT has a blog. Check out http://blogs.msdn.com/davidnotario. The debugger and  compiler have an intimate relationship because the debugger needs to understand the code-gen patterns from the compiler in order to meaningfully debug it.

0

CLR Debugging vs. CLR Profiling

The CLR offers both debugging and profiling services.  While there is some overlap, there are some significant differences between profiling and debugging in the CLR and they’re intended to solve very different problems.   What about the similarities? There’s certainly some overlap between these two services. Both: 1)      can inspect CLR state. including callstacks, local…

9

Standardizing ICorDebug?

I was recently asked “Are there any plans to standardize (ECMA for example) the debugging APIs?”   Short answer is “No”.    My two cents: In my opinion, ICorDebug is not yet ready to be standardized: –         Standardizing it would impede our ability to innovate the API. –         On the managed side, it’s also an…

0

ICorDebug, Edit-and-Continue, and C#

In case anybody missed it, VS 2005 C# is going support Edit-and-Continue! (See announcement, and some follow up posts by the C# team from Andy and Steve).   The CLR is a language-neutral platform. So naturally, our debugging API (ICorDebug) operates at the IL level so that it can be language-neutral as well. The Edit-and-Continue…

13

Implications of using a helper thread for debugging

What it means? I mentioned in a previous post (http://blogs.msdn.com/jmstall/archive/2004/10/10/240452.aspx) that the CLR debugging services is an “in-process model” which means it has a helper thread running in the same process as the EE which provides debugging information at runtime. Contrast this to an “out-of-process” model where the debugger operates completely from a separate process…

16

Why is managed debugging different than native-debugging?

People ask “why can’t a native debugger debug managed code?”. The reason is that the CLR provides a lot of cool services beyond what you get in a typical native C++ app, such as: running on a Virtual Machine / JITing, Dynamic class layout, the type-system, garbage-collection, reflection-emit, and more. Each of these imposes special…

11

We need your feedback on the fate of Cordbg.exe

We currently ship a command line debugger in the SDK, Cordbg.exe. It’s implemented in unmanaged C++. In v2.0, our debugger test team also started developing their own command line debugger, MDbg, written in C# and harnessing the awesome power of managed code.   We don’t want to maintain two command line debuggers. We’d strongly prefer…

16

How can I use ICorDebug?

ICorDebug, the managed debugging API,  is a public API and anybody can use it to write a managed debugger.   However, it’s also a very large and scarcely documented API. V1.1 had about 250 methods, and v2.0 has about 300 methods, and there’s nothing in MSDN about it. So despite our claims, we recognize that…

7

Filters + Finallys are not executed after unhandled exceptions when Native/Interop debugging!

I said earlier that Filters + Finallys are not executed after unhandled exceptions when Native / Interop debugging.  I wanted to elaborate on that statement here:   The symptoms: First, I want to clarify exactly what that means.  Take the following trivial app that throws an unhandled exception: using System;   class Class1 {      …

6