Hello,
sometimes calling the method ICorDebugController::Stop NEVER terminates nor returns S_TIMEOUT or something like that. It returns only if I terminate process manually by Task Manager.
A time ago I was not able to stop my application in Visual Studio. After a minute, VS shows a form reporting that a application cannot be stopped... (I suppose Stop returns S_TIMEOUT or not :) ).
MSDN tells us : "Stop is the only synchronous method in the debugging API. When Stop returns S_OK, the process is stopped. No callback is given to notify listeners of the stop. "
So for example ... is't possible to execute Stop method in the second thread and if not returns after a specified amount of time, terminate a executing thread (because: "The value of dwTimeoutIgnored is ignored, and treated as if it were -1.") Is it safe - correct Will not corrupt internal state of managed debugger
Thanx, Libor Bares
ICorDebugController::Stop problem
Jan-Dirk
S10n
ad 1) I'am using VS2003 and .NET 1.1
ad2) Only managed-only debugging (unmanaged debugging is not implemented in my dbgr application)
And it's possible something like that - is't correct :
void StopThreadImpl() {myProcess->Stop(-1);} bool Stop() { Thread stopThread= new Thread(new ThreadStart(new MethodInvoker(StopThreadImpl))); stopThread.IsBackground = true; stopThread.Start(); // wait a minute if(/* thread was not terminated */) { stopThread.Terminate(); return false;} return true; }Magnus Müller
It was C++ and the second one was C# :)
And it's safe something like this
Process::GetProcessById(myPid)->Kill();
(When ICorDebugProcess::Stop is still executing.)
Can-Ann
Processes can be killed at any time. ICorDebug expects that the debuggee exiting at any time.
Killing the entire process is different than killing a specific thread in the process while leaving the rest of the process to hobble along.
MShah
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 debugger 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 debugger.
cammy9.9
Ah! Killing another thread like that is dangerous. You may leak locks and most future ICorDebug calls will hang.
There are issues with using managed ICorDebug wrappers in .NET 1.1, http://blogs.msdn.com/jmstall/archive/2004/11/02/250946.aspx.
What language is this It looks like C#, but the '->' looks C++. Or is just pseudo-code.
I'd suggest explicitly casting the -1 to a DWORD just to not worry about that. Implicit casting rules are language depenedent.