Welcome to MSDN Blogs Sign in | Join | Help

October 2004 - Posts

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
Posted by jmstall | 7 Comments
Filed under: ,

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
Posted by jmstall | 0 Comments

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
Posted by jmstall | 9 Comments
Filed under:

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
Posted by jmstall | 0 Comments
Filed under:

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
Posted by jmstall | 13 Comments

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
Posted by jmstall | 16 Comments

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,
Posted by jmstall | 11 Comments

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
Posted by jmstall | 16 Comments
Filed under:

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
Posted by jmstall | 7 Comments
Filed under:

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
Posted by jmstall | 6 Comments

Debugging IL

Managed applications are compiled to IL (Intermediate Language) and then our JIT (Just-In-Time compiler) can compile it to native code so that the CPU can execute it. (The alternative is interpreting the IL directly, which has horrible performance characteristics
Posted by jmstall | 25 Comments

"Rocket Science" API?

Let me just say it and make sure we're all on the same page here: We made a lot of mistakes in v1.0 of ICorDebug. One such mistake was we frequently called ICorDebug a "Rocket Science" API. IMO, we figured that anybody writing a debugger must be a super
Posted by jmstall | 1 Comments
Filed under: ,

Debuggers aren't supposed to change behavior

Ideally, an app executes the same whether there's a debugger attached or not. This derives from very practical motivations: Bugs usually first occur outside the debugger (some test fails), and then you want to just rerun the test under the debugger to
Posted by jmstall | 9 Comments
Filed under:

Getting your feedback!

I'm interested in our consumer's feedback and knowing what sort of things people would like me to blog about. If you have feedback or things you'd like to see me post on, please just post a comment on this blog instead of trying to send me email. (I bet
Posted by jmstall | 5 Comments
 
Page view tracker