1) What version of VS / .NET are you using (VS2002 / VS2003 / VS2005 ; .NET 1.0, 1.1., 2.0 ). 2) are you managed-only or interop-debugging
That's correct. Stop() ignores the timeout and is synchronous (it blocks until the debuggee is stop). Stop() uses the same algorithm that the GC uses to keep suspend.
If Stop() does not return, then something in the debuggee is preventing a suspension. This is usually goofy, including: - a thread is hard-suspended - a 2nd native de**** was attached to the managed debuggee and has hard-suspended the debuggee, preventing it getting to a managed stop-point. - certain interop-debugging scenarios (you're managed-only debugging, right ) - a bug in the CLR suspension logic.
If the VS UI hangs while trying to do a Break() (which ultimately calls Stop()), it's possible that VS / ICorDebug hung somewhere before it called Stop.
When Stop() doesn't return, this is usually diagnosable by a full user-mode memory dump of both the debuggee and de****.
|