This is probably old news now, but something which has me concerned as it can cause lots of unseen issues. In .NET 3.5 the default ThreadPool count has been increased ten-fold from 25 to 250 per processor per process! ThreadPools as we know are quite handy - not only do they help when an application comes under load instead of adding more pressure in a stressful situation. They also allow us to readily “reach into” a pool of threads and “pick one” to use - saving the costly overhead of creating and destroying threads (in case you did not know creating and destroying threads is an expensive process).
Yeah OK; so why do I care? Well, most people won’t but there are situations where this will cause unexpected behaviour and even lead to Out of Memory exceptions.
Essentially each thread created takes 1 Mb of stack space. Say you are creating a server app and spawn a different thread for IO and if are running on a 8-proc Win x32 box, with this change your application will cap out now at 2000 threads (8 x 250)! With each of them taking 1 mb that is a total of 2GB - which is the total addressable space in Win x32! Ouch!
Of course you can change this - for a web app this is a simple change to the web.config file; however if it is not a web app then this does require a change to the code albeit simple. So, if you suddenly start seeing out of memory exceptions, with nothing really changing, then this might be the cause.