description | title | ms.date | api_name | api_location | api_type | f1_keywords | helpviewer_keywords | ms.assetid | topic_type | |||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Learn more about: ICorDebugThread::SetDebugState Method |
ICorDebugThread::SetDebugState Method |
03/30/2017 |
|
|
|
|
|
6382bdf6-d488-4952-b653-cb09b6e1c6c2 |
|
Sets flags that describe the debugging state of this ICorDebugThread.
HRESULT SetDebugState (
[in] CorDebugThreadState state
);
state
[in] A bitwise combination of CorDebugThreadState enumeration values that specify the debugging state of this thread.
SetDebugState
sets the current debug state of the thread. (The "current debug state" represents the debug state if the process were to be continued, not the actual current state.) The normal value for this is THREAD_RUN. Only the debugger can affect the debug state of a thread. Debug states do last across continues, so if you want to keep a thread THREAD_SUSPENDed over multiple continues, you can set it once and thereafter not have to worry about it. Suspending threads and resuming the process can cause deadlocks, though it's usually unlikely. This is an intrinsic quality of threads and processes and is by-design. A debugger can asynchronously break and resume the threads to break the deadlock. If the thread's user state includes USER_UNSAFE_POINT, then the thread may block a garbage collection (GC). This means the suspended thread has a much higher chance of causing a deadlock. This may not affect debug events already queued. Thus a debugger should drain the entire event queue (by calling ICorDebugController::HasQueuedCallbacks) before suspending or resuming threads. Else it may get events on a thread that it believes it has already suspended.
Platforms: See System Requirements.
Header: CorDebug.idl, CorDebug.h
Library: CorGuids.lib
.NET Framework Versions: [!INCLUDEnet_current_v10plus]