Welcome to MSDN Blogs Sign in | Join | Help

Browse by Tags

All Tags » ICorDebug   (RSS)
Tuesday, October 23, 2007 4:26 PM

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
Posted by jmstall | 0 Comments
Wednesday, October 17, 2007 4:25 PM

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
Posted by jmstall | 1 Comments
Wednesday, October 03, 2007 1:32 AM

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
Posted by jmstall | 3 Comments
Sunday, September 30, 2007 12:24 AM

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.
Posted by jmstall | 2 Comments
Monday, August 27, 2007 8:00 PM

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
Posted by jmstall | 1 Comments
Thursday, January 18, 2007 12:05 AM

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
Posted by jmstall | 0 Comments
Filed under:
Monday, January 15, 2007 1:03 PM

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
Posted by jmstall | 4 Comments
Wednesday, January 10, 2007 1:27 AM

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
Posted by jmstall | 2 Comments
Thursday, December 28, 2006 1:32 AM

Fake attach event ordering

When you attach to a managed debuggee (via ICorDebug::DebugActiveProcess), ICorDebug generates a set of fake events designed to bring the debugger up to the current state. The motivation is that it pumps the debugger just as if the debugger was always
Posted by jmstall | 5 Comments
Tuesday, November 14, 2006 3:55 PM

LCG + Debuggability, and your feedback

I mentioned earlier that you can debug Reflection.Emit code . Unfortunately, Ref.Emit code can't be unloaded unless you unload the entire appdomain. I wanted to lay out the current landscape, and then get feedback about possible solutions. In Whidbey,
Posted by jmstall | 13 Comments
Filed under:
Sunday, October 01, 2006 12:07 AM

ICorDebugValue vs. System.Object

System.Object represents a managed object within a process. ICorDebugValue is the debugger's representation of a System.Object within the debuggee process. The key here is that the debugger and debuggee processes are ideally fully isolated from each other.
Posted by jmstall | 3 Comments
Filed under:
Monday, September 11, 2006 11:10 AM

LoadClass events are usually meaningless

ICorDebug notifies a debugger when a managed class is loaded via LoadClass debug event. For dynamic-modules, this is useful because it tells you that you just baked a new type and so may have new code to bind breakpoints in (see here for debugging ref-emit
Posted by jmstall | 1 Comments
Filed under:
Wednesday, August 30, 2006 11:40 PM

An example of an API versioning problem.

Here's an example of an API versioning problem. In general: Anytime you take two separate concepts and tie them together based off some current implementation assumption, you're going to get trouble when that assumption is broken. The specific example
Posted by jmstall | 4 Comments
Filed under: ,
Tuesday, August 01, 2006 11:58 AM

Empty implementation of ICorDebugManagedCallback

I have to implement the ICorDebugManagedCallback interfaces. I wrote up a stub implementation (that just E_NOTIMPLs all the methods) and am posting it here for reference. It's pretty tedious, so I'll post it here and then never have to write that again.
Posted by jmstall | 2 Comments
Filed under: ,
Thursday, July 20, 2006 9:59 AM

You can't cast from a pointer to a managed object in the debugger

During native debugging, it's common to cast a raw pointer value to a given type. Eg, in the expression window, do: (Foo*) 0x12345; You may have noticed that you can't do this in managed code. This is a restriction at the ICorDebug (CLR) level. Some of
Posted by jmstall | 2 Comments
Filed under:
More Posts Next page »
 
Page view tracker