Why does this simple .NET console app have so many threads?

Question

This simple program starts with 15 threads - according to the count. Sometimes during its lifetime it drops a few, but they come back.

class Program
 {
     static void Main(string[] args)
     {
         while (true)
         {
             Console.WriteLine(Process.GetCurrentProcess().Threads.Count);
             Thread.Sleep(500);
         }
     }
 }

I was expecting the process to just have one thread (and my intuition was backed up by this)

Without the debugger, the process has only (!) 4 threads. Surely any CLR stuff would be hidden from my process?

What count is this? Does the process really have that many threads? Why?

Tillery

just out of curiosity - who do I upvote here? everyone's got the same answer :D – Inae

@obelix: if they all deserve an upvote, you could upvote them all. Your kind of question should be asked on MSO. – Salvidor

@obelix: they all make sense so they've all got an upvote from me. When I'm back in the office on Monday I'll check up a few details and give the most detailed, backed up answer the trophy. – Tillery

@Salvidor - did not think it merited a full blown discussion on meta. ergo just a comment. – Inae

My console application has 16 (!!!) threads. Could it be because I'm using LINQ? – Colander

Answer 1

Try running it outside the debugger (i.e. press Ctrl+F5 instead of F5). You should only see three threads - the main thread, the GC thread & the finalizer thread IIRC. The other threads you see are debugger-related threads.

Valiant

Yes, main thread, GC, and finalizer are exactly what you will see. However you need to A) run outside the debugger and B) turn off Visual Studio Hosting Process which adds a thread or two. – Backfill

do you have a link to an msdn article? – Tillery

is the VS hosting process activated even if I'm in Release mode without running the process through VS? I still see 4 threads... – Tillery

Thread 4 might be a ThreadPool thread for any asynchronous work that needs to be done. Just guessing, though. – Marchese

Need an evidence, It is completely wrong, I have seen the process moves between 4-7 threads outside the debugger!!! it is a very simple console app with an infinite loop! – Unsteel

Answer 2

If you run it without a debugger attached, there are significantly fewer threads. And those would presumably be the finalizer thread, and other house-keeping CLR stuff.

Lardy

Answer 3

Project + Properties, Debugging, untick "Enable the Visual Studio hosting process". I can't discover what it is doing. As soon as I tick the "Enabled unmanaged code debugging" option to try to get a peek at these threads, they no longer get started. No clue. But I'm sure it's for our benefit :)

Walkling

I think the hosting process gives the debugger go faster stripes, or something like that. – Tillery

I beleive the hosting process was designed to give faster startup times for debugging - when you debug, the relevant assemblies get loaded into the vshost process, rather than the debugger having to keep on creating/destroying new processes. – Jorie

Nah, the hosting process is a custom hosted version of the CLR. Mostly for security purposes. – Walkling

Answer 4

Try running it without the debugger (Visual Studio) attached (Ctrl+F5). You'll see that there will be less (probably 3) threads. Most of those threads have to do with the debugger.

Progression