http://flier_lu.blogone.net/?id=1370342
[2] Threads After configuring Windbg, we load a CLR program and execute to the CLR to be loaded, then start our CLR exploration journey. First, use! Threads command to see what threads in the current CLR are being executed
The following is quoted:
0:004>! Threads
Threadcount: 2
UnStartedthread: 0
Backgroundthread: 1
PENDINGTHREAD: 0
Deadthread: 0
Preemptive GC Alloc Lock
ID ThreadObj State GC Context Domain Count Apt Exception
0 6ec 0014E708 6020 enabled @000000: 00000000 00148A90 0 STA
2 a68 00157618 B220 enabled @000000: 00000000 00148A90 0 MTA (Finalizer)
The front five counter represents a managed thread, not starting thread, background thread, blocking thread, and quantity of zombie threads. The following list is the details of the current hosted thread: the first domain is a Windbg thread number; ID is the Win32 thread ID; threadObj is a thread object; State is a flag, later introduced in detail; Preemptive GC means GC is This thread collaborates; GC Alloc context is the relevant information of GC; Domain is AppDomain where the thread is located; the Lock Count is a counter that has a lock counter; APT is a thread type, along the concept of STA / MTA / NTA (NetURAL) in COM; final Exception Indicates a thread type, in addition to the normal user thread, there is Finalizer, GC, THEADPOOL WORKER, and ThreadPool Completion Port, which match the name. We can find a detailed instructions for all sos.dll support commands in the .NET Framework SDK Tool Developers Guide / Samples / SOS subdirectory; find Sos.dll for Rotor systems in Rotor's CLR / SRC / Tools / Sos subdirectory Implementation code. This source code is functionally implemented with the same functionality as the CLR formal release version, and is one of the main goals of our research. Strike.cpp is the implementation of the SOS function command. Commands of each SOS are implemented in strike.cpp, and the function parameters are defined by the DECLARE_API macro.
The following is quoted:
#define declare_API (s) /
CPPMOD VOID /
S (/
Handle HcurrentProcess, /
Handle HcurrentThread, /
Ulong dwcurrentpc, /
Ulong dwprocessor, /
PCSTR ARGS /
)
The function parameters are passed to the process handle, current thread handle, current command address, processor, and command line parameter information, respectively. This information is processed in the function, and the debug information is output to the WindBG interface. Let's take a look at the Threads command (strike.cpp: 1237). The Threads function first gets the current thread statistics from a full-term thread storage pool, and stores it in a structure and prints the statistical value within a structure; then call the GetThReadList function (SOS / Util.cpp: 2259) Get a list of threads; for each thread Get thread information and store it in a structure and print thread details; when printing thread information, it is judged that the type of this thread is printed. Let's take a look at the design and use of the global thread storage pool THREADSTORE class (VM / Threads.h: 1998). The CLR is initialized by the Coinitializeee function (VM / CEEMAIN.CP: 1100), which is similar to the concept of JVM, which is actually the runtime environment of the CLR. For details on the detailed startup process of the CLR, see another article in the author. "CLR program under the." The Coinitializeee function uses global variables to ensure that there is only one CLR environment for each process; the troryestartup function (VM / CEEMAIN.CPP: 500) attempts to initialize the CLR. The pseudo code is as follows: The following is a reference:
HRESULT stdmethodcalltype Coinitializeee (DWORD FFLAGS)
{
IF ( g_refcount <= 1 &&! g_feestarted &&! g_feinit)
{
g_eestartupstatus = tryeestartup (fflags);
}
RETURN SUCCEEDEDEDEDEDEDEDEDEDEDEDEDoces?
(SETUPTHREAD ()? S_OK: E_OUTOFMEMORY: G_EESTARTUPSTATUS;
}
The tryestartup function completes the actual CLR startup work with an exception security policy package EESTARTUP function (VM / CEEMAIN.CP: 206). The initTHReadManager function (VM / Threads.cpp: 2068) completes the initialization work of the thread manager in the EESTARTUP function. InitThreadManager functions out of initialization TLS, most of the work is implemented by the ThreadStore :: initthreadstore function (VM / Threads.cpp: 4345) of the Singleton mode of the Threadstore class. Where saving global unique ThreadStore class instance is the global thread storage pool for thread statistics.
The following is quoted:
Threadstore * g_pthreadstore;
Bool threadstore :: initthreadstore ()
{
g_pthreadstore = new threadstore;
Return (g_pthreadstore! = null);
}
