.NET Framework Developer Center >
.NET Development Forums
>
Building Development and Diagnostic Tools for .Net
>
The CLR's internal threads
The CLR's internal threads
- It is known that the CLR creates additional threads for its owns needs like GC. Which tasks more may be executed by the CLR except GC? Is there an opportunity to recognize such internal threads inside CLR profiler?
Thanks.
Answers
- You can always break in to a managed app with a native debugger and peek at what threads are created and what stacks they have. Some of the most common threads you'll see are the finalizer thread and a debugger helper thread. GC can also create threads for its own use, and there are other reasons the CLR may need to create its own thread.
Since profilers are native code, they get to view all the threads in the process simply by using OS APIs. Your profiler may also end up running on some of these internal threads depending on what your profiler does. For example, if your profiler responds to the Enter/Leave/Tailcall hooks, then your hooks will be called on the finalizer thread when a finalizer is executed. If your profiler responds to GC events, and the GC creates extra threads to do its job (e.g., server-mode GC), then your profiler will be called on those GC threads.
It's worth noting that CLR Profiling API events like ThreadCreated are specifically for managed threads only. However, you get to write a DllMain, and can choose to respond to DLL_THREAD_ATTACH, which notifies you of any new OS threads being created for the process (native or managed).
Thanks,
Dave- Proposed As Answer byDavid BromanMSFT, OwnerTuesday, November 03, 2009 5:10 PM
- Marked As Answer byKarel ZikmundMSFT, ModeratorFriday, November 06, 2009 5:46 PM
All Replies
As far as i know its not officially documented anywhere but since rotor and the real runtime are pretty similar (but not identical) you could look into the rotor code to see what they spin off extra threads for to get an idea of what the real runtime could be doing.
- Thank you for an idea.
- You can always break in to a managed app with a native debugger and peek at what threads are created and what stacks they have. Some of the most common threads you'll see are the finalizer thread and a debugger helper thread. GC can also create threads for its own use, and there are other reasons the CLR may need to create its own thread.
Since profilers are native code, they get to view all the threads in the process simply by using OS APIs. Your profiler may also end up running on some of these internal threads depending on what your profiler does. For example, if your profiler responds to the Enter/Leave/Tailcall hooks, then your hooks will be called on the finalizer thread when a finalizer is executed. If your profiler responds to GC events, and the GC creates extra threads to do its job (e.g., server-mode GC), then your profiler will be called on those GC threads.
It's worth noting that CLR Profiling API events like ThreadCreated are specifically for managed threads only. However, you get to write a DllMain, and can choose to respond to DLL_THREAD_ATTACH, which notifies you of any new OS threads being created for the process (native or managed).
Thanks,
Dave- Proposed As Answer byDavid BromanMSFT, OwnerTuesday, November 03, 2009 5:10 PM
- Marked As Answer byKarel ZikmundMSFT, ModeratorFriday, November 06, 2009 5:46 PM


