Virtual code execution via IL interpretation

As Soma announced, we just shipped VS2010 Beta1. This includes dump debugging support for managed code and a very cool bonus feature tucked in there that I’ll blog about today. Dump-debugging (aka post-mortem debugging) is very useful and a long-requested feature for managed code.  The downside is that with a dump-file, you don’t have a…

8

Managed Dump debugging support for Visual Studio and ICorDebug

This is the longest I’ve gone without blogging, but our PDC announcements have stuff way too cool to stay quiet about. If you saw PDC, you’ve head that the CLR Debugging API, ICorDebug, will support dump-debugging. This enables any ICorDebug-based debugger (including Visual Studio and MDbg) to debug dump-files of .NET applications. The coolness goes…

4

Breaking changes in ICorDebug from 1.1 to 2.0.

Here are some random notes about specific ICorDebug breaking changes between .NET v1.1 (Everett) and .NET 2.0 (Whidbey). (I came across these as I was cleaning out old documents in preparation for my upcoming move). This would have been more timely 2 years ago, but better late than never. This can be viewed as the…

0

Things that what work in Native-debugging that don’t work in Interop-debugging.

Interop-debugging (mixed-mode) is managed + native debugging combined. Well, sort of. Native and managed debugging have very different paradigms. Native debugging tends to own the whole process, while managed debugging tends to require control of the whole process while only exposing a managed  view to the user. So some functionality restrictions were needed to get…

1

Debugger.Break()

System.Diagnostics.Debugger.Break() is a BCL method that causes a program to issue a User Breakpoint when run under the debugger. This translates to a Break() debug event on ICorDebugManagedCallback. (Not to be confused with Breakpoint(), which corresponds to actual breakpoints. Yeah, we could have given them better names…) The debugger will break at the callsite of…

3

ICorDebugFunction is 1:1 with the IL

In CLR 1.0, there was a simple invariant between IL code blob, and native code blob.  It was either 1:0 if the code wasn’t jitted, or 1:1 if it was. Method tokens (module scope, mdMethodDef) were also 1:1 with the IL blobs. 1:1 is a nice relationship. Each side can just point to the other without…

2

ICorPublish does not cross the 32/64 bit boundary

I mentioned earlier that ICorDebug does not cross the 32/64 boundary. If you want to debug a 32-bit managed app, you need to use a 32-bit version of the ICorDebug interfaces (or Mdbg). If you want to debug a 64-bit managed app, you need a 64-bit savy debugger. When you debug a 64-bit managed app in…

1

UpdateModuleSysmbols comes on attach

I forgot about UpdateModuleSysmbols when I described the fake debug events sent on attach.  This event is sent after LoadModule and is what delivers the symbols for dynamically generated code. This lets you debug code generated with ref.emit when you attach to a process.  Note that if the debuggee only emits symbols when a debugger…

0

Tips for writing an Interop Debugger

I’ve had a growing number of people inquire about how to write an interop-debugger with ICorDebug. I strongly advise anybody considering writing an interop-debugger to reconsider for reasons listed here. However, for those who can not be dissuaded, and promise to do something really really cool, here are some key tips: Interop-debugging means both the managed…

4

You don’t want to write an interop debugger.

I’ve had a growing number of people inquire about how to write an interop-debugger with ICorDebug.  My goal here is to discourage you from doing that. (This reminds me of one of my college classes. On day one, the acting-Prof launched into a great sermon “Why you should drop this class now”. It turned out…

3