Thread IDs are just the Windows thread's ThreadID, so you can't learn much about the memory allocation from just the calling thread's ID. The callstack is the most important thing to look at.
For the hello.exe sample, there are three threads at the time the "Hello World" message is printed: 1) The thread that ran clix.exe's main(), which runs the managed code including the write to the console. 2) The finalizer thread, which could run managed code. It is blocked in a WaitForSingleObject with the following callstack: 0:001> k ChildEBP RetAddr 02affe1c 77f5c534 *SharedUserSystemCall+0xc WARNING: Stack unwind information not available. Following frames may be wrong. 02affe84 77e7ac21 ntdll!NtWaitForSingleObject+0xc 02affea8 7935e6e0 kernel32!WaitForSingleObject+0xf 02affeb8 7935f6cd sscoree!WaitForFinalizerEvent+0xe 02afff88 7978edd5 sscoree!GCHeap__FinalizerThreadStart+0x1d7 02afff9c 7978f331 rotor_pal!PAL_LocalFrame+0x24 02afffb4 77e7d33b rotor_pal!PAL_ThreadProc+0x2e 02afffec 00000000 kernel32!RegisterWaitForInputIdle+0x43 3) The debugger thread, used for communicating with cordbg, which is blocked in a WaitForMultipleObjects: ChildEBP RetAddr 00a9fdec 77f5c524 *SharedUserSystemCall+0xc WARNING: Stack unwind information not available. Following frames may be wrong. 00a9fe8c 77e75faa ntdll!NtWaitForMultipleObjects+0xc 00a9fec0 794a4e95 kernel32!WaitForMultipleObjects+0x17 00a9ff68 794a5b1e sscoree!DebuggerRCThread__MainLoop+0x13c 00a9ff80 794a5b32 sscoree!DebuggerRCThread__ThreadProc+0x133 00a9ff88 7978edd5 sscoree!DebuggerRCThread__ThreadProcStatic+0x10 00a9ff9c 7978f331 rotor_pal!PAL_LocalFrame+0x24 00a9ffb4 77e7d33b rotor_pal!PAL_ThreadProc+0x2e 00a9ffec 00000000 kernel32!RegisterWaitForInputIdle+0x43 If you use NTSD or Windbg to debug your app, and you break in, try running this command: "!sos.Threads". It uses sos.dll (see sscli\docs\debugging\sos.html for documentation), to list all of the managed threads in the process and shows summary information about each. Lastly, each thread can access the entire heap. Barry -----Original Message----- From: Discussion of the Rotor Shared Source CLI implementation [mailto:[EMAIL PROTECTED] On Behalf Of SUBSCRIBE DOTNET-ROTOR Memomana Sent: Sunday, February 15, 2004 1:57 PM To: [EMAIL PROTECTED] Subject: [DOTNET-ROTOR] Thread ID I noticed that when we start a C# application using the CLI, there will be different threads doing allocations before the user application starts. I can see that by using the default profiler (included in the SSCLI distribution). I think these different threads are allocating objects that are crucial for the CLI/virtual machine. However, I am not so sure about the following: #1 Does Rotor, during its initialization, specify certain threads to do certain things? During startup, I find: tid:613696 ... *hundreds of line of allocation* tid:830056 ... *less than a hundred line of allocation* tid:613696 ... *hundreds* tid:830056 ... *hundreds* tid:905368 ... *thousands* ... ... #2 Can we tell from the thread ID, which threads are for serving the user and the ones for the system/CLI itself? #3 Is there any address range in the heap that a particular thread can access? Any help is very appreciated. Thank you. Memomana =================================== This list is hosted by DevelopMentor(r) http://www.develop.com NEW! ASP.NET courses you may be interested in: 2 Days of ASP.NET, 29 Sept 2003, in Redmond http://www.develop.com/courses/2daspdotnet Guerrilla ASP.NET, 13 Oct 2003, in Boston http://www.develop.com/courses/gaspdotnet View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentorŪ http://www.develop.com NEW! ASP.NET courses you may be interested in: 2 Days of ASP.NET, 29 Sept 2003, in Redmond http://www.develop.com/courses/2daspdotnet Guerrilla ASP.NET, 13 Oct 2003, in Boston http://www.develop.com/courses/gaspdotnet View archives and manage your subscription(s) at http://discuss.develop.com
