Random ICorDebugThread trivia

  • Article

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 come as soon as the CLR knows about the thread). This introduces the ICorDebugThread object for that thread.
 2. We haven't defined when exactly the ExitThread callback comes. Currently, it does not come until the underlying native thread has exited.
 3. This means that an ICDThread may not have any managed frames on its stack. For example, the thread may have called into managed code and then returned back to native code. Since the native thread hasn't exited yet, the ICDThread still exists. A very common case of this is the Finalizer thread when it's not running any finalizers.
 4. With fibers, ICorDebugThread becomes 1:1 with the fibers, not the raw OS threads. ICDThread::GetID() didn't make this clear enough (and clients ended up using that expecting it to be stable), so we added ICDThread2::GetVolatileOSThreadID() to make this more obvious.
5. If a debuggee is rudely terminated, you'll still get the ExitProcess event, but not all of the other managed exit-events are guaranteed to come.

Comments

  • Anonymous
    February 07, 2006
    The ICorDebug API (the API for debugging managed apps) is about 70 total interfaces.  Here is how...
  • Anonymous
    March 02, 2006
    That's a fair question. Part of the answer is we don't believe people could use it properly.  The...
  • Anonymous
    March 21, 2006
    Don't assume that if you have a thread doing a spin-wait, that you can attach / asynchronously-break...
  • Anonymous
    June 26, 2006
    I've gotten some questions about how appdomains are handled at the ICorDebug level. Here's some random...
  • Anonymous
    December 27, 2006
    When you attach to a managed debuggee (via ICorDebug::DebugActiveProcess), ICorDebug generates a set