There appears to be some confusion about this .NET 2.0 SP1 ThreadPool bug I found. Can you believe someone might be wrong on the internet?

If you’ve been following the posts (1, 2, 3), then you’ll know I was in touch with the key guys at Microsoft and the root of the problem is that if you create asynchronous work faster than the ThreadPool can create threads, then that work “misses” the SetMinThreads command and are created more slowly.

That is why the Thread.Sleep(1) probably solves the issue for you. If it doesn’t, sleep slightly longer. It’s a timing issue.

With this insight, you’ll see that this does not really affect true servers such as ASP.NET and WCF but does affect things like Delegate.BeginInvoke and friends called in quick succession.

In short, if your server handles more than 1,000 requests per second, during the first second of startup, then your server may run into this problem (ok, ok, more precisely, if your server handles more than 1 request / millisecond).

Let me address a few common concerns out there:

• Is the sky falling? No.
• Is it great situation? No.
• Will be fixed with .NET 2.0 SP2? Yes
• When? Maybe this summer, maybe later – they aren’t sure.
• Does this affect WCF and ASP.NET? Probably not. The bug, no. The new ThreadPool behavior, yes.
• Is there a work around? Yes, create threads more slowly. This is automatic on the server.