Welcome to MSDN Blogs Sign in | Join | Help

Browse by Tags

All Tags » ICorDebug » This should be in MSDN   (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
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, March 21, 2006 12:12 PM

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
Posted by jmstall | 0 Comments
Thursday, March 09, 2006 11:39 AM

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
Posted by jmstall | 1 Comments
Wednesday, March 08, 2006 11:41 AM

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
Posted by jmstall | 2 Comments
Sunday, March 05, 2006 12:44 PM

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
Posted by jmstall | 6 Comments
Wednesday, February 08, 2006 1:37 AM

Design Implications from boring details

You can discern a lot of information about an API from what appear to be subtle or irrelevant details For example, each ICorDebug object has a logical parent. (See here for a brief explanation of the different ICorDebug interfaces). Here's a chart: ICorDebugProcess
Posted by jmstall | 2 Comments
Friday, February 03, 2006 12:52 AM

Viewing the current Exception in the debuggeer

VS (and mdbg) expose the $exception pseudo-variable which shows you the most recent exception. (kudos to Shaykatc for mentioning this a year ago). Debugger authors can implement this with: HRESULT ICorDebugThread::GetCurrentException([out] ICorDebugValue
Posted by jmstall | 1 Comments
Wednesday, February 01, 2006 1:00 PM

Random ICorDebugThread trivia

Here's random information about ICorDebugThread that I hope eventually makes it into MSDN: 1. The managed CreateThread callback comes at the first bit of managed code that a thread runs. (I think this is a bad for these reasons , and instead it should
Posted by jmstall | 5 Comments
Tuesday, January 24, 2006 12:15 PM

Multiple steppers on 1 thread and other trivia

ICorDebug has a nicely abstracted "Stepper" object, via ICorDebugStepper (I talked more about that here ). You setup a stepper object (via CreateStepper), resume the process, and then get an aysnchronous "StepComplete" debug event when the stepper is
Posted by jmstall | 1 Comments
Wednesday, January 04, 2006 11:03 AM

Partition of ICorDebug

The ICorDebug API (the API for debugging managed apps) is about 70 total interfaces. Here is how I'd group the interfaces together, along with my random comments about how various interfaces fit into the big picture. A quick comment about interface versioning:
Posted by jmstall | 2 Comments
Thursday, September 15, 2005 1:18 AM

ICorDebug, MTA, STA.

ICorDebug (ICD) is a com-classic interface. In terms of COM threading models , ICorDebug is technically free-threaded (aka, should reside in the "neutral apartment"), which means that it manages its own threading. We go through great pains in the ICD
Posted by jmstall | 4 Comments
Tuesday, August 23, 2005 5:29 PM

ICorDebugStepper and using ICorDebugStepper2::SetJMC

We added Just-My-Code (JMC) stepping (the ability to step through just your code and skip code that's not yours) in Whidbey. I blogged a demo from the end-user's perspective here . In response to some email, I wanted to talk a little more about how a
Posted by jmstall | 4 Comments
 
Page view tracker