AttributeUsage.Inherited flag

I found the documentation for AttribuetUsageAttribute to be very ambiguous, particularly regarding the Inherited property. Here’s a quick test on the behavior of the AttributeUsage.Inherited flag.  This affects how the attribute is queried via GetCustomerAttributes(). Here’s how … There are 4 pivots: 1. In the usage case, is there an attribute on the derived class…

1

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

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 attached. Native debugging does the same thing. The list isn’t very well documented, and…

5

Random ICorDebug trivia about debugging AppDomains

I’ve gotten some questions about how appdomains are handled at the ICorDebug level. Here’s some random trivia (this is kind of like the AppDomain version of the random-ICDThread trivia post I did earlier): Breakpoints: An ICorDebugBreakpoint is AppDomain specific. That means the debugger needs to do extra work to simulate a “process-wide” breakpoint; which really…

2

What to expect when you Attach, Async-Break

Don’t assume that if you have a thread doing a spin-wait, that you can attach / asynchronously-break (“async-break”) and your debugger will immediately stop at the spin-wait. When you attach to a debuggee or async-break while debugging, the debuggee’s threads could be anywhere. Even if you attach in response to a debuggee request (such as…

0

Doing Detach with ICorDebug

Detaching a managed-debugger is somewhat complicated at the ICorDebug API level. In a perfectly-friendly API, you could just call “ICorDebugProcess::Detach” and be done with it. With managed-debugging, there are two main constraints and the hresults (in parenthesis) that you’ll get for violating them: You can’t be doing interop-debugging (CORDBG_E_INTEROP_NOT_SUPPORTED) or Edit-and-Continue (CORDBG_E_DETACH_FAILED_ON_ENC). The debuggee must…

1

MDbg, Managed-debugging, and 64 bit

V2 CLR added support for 64-bit (amd64 and ia64), and that includes managed-debugging support. So a 64-bit MDbg can debug a 64-bit managed app. But what about cross-platform stuff when your debugger and debuggee are different platforms? Here’s how MDbg and managed-debugging work across the 32/64 bit divide.  The quick story is that Mdbg is…

2

What does a debugger author need to do to support func-eval?

I’ve mentioned func-eval (aka property eval) is evil for end-users; but it’s also evil if you want to write a debugger that uses func-eval. For example, let’s say you’re writing your own managed debugger and you have a watch window, and you want to eval property-getters and ToString() calls on items.  Since VS does this,…

6