Hello, the well respected german computer magazine c't reports in an article of its release 26/03 on page 214, that the .Net multithreading support currently suffers from several strangeness factors. The class ThreadPool suffers from several anomalies: The thread pool of a process is limited by 25 threads per processor. GetMaxThreads() and GetAvailableThreads() deliver the values 25/25 with .Net 1.0 and 25/1000 with .Net 1.1. The new threads obey to a pretty ackward activation pattern, new threads are started with individual offsets of 500ms to each other! The garbage collector starts after one minute after the demise of a thread. If new threads are requested in between, one again suffers the 500ms penalties from above. Further experiments trying to start all required threads in advance suffered from being queued automatically from thread 25 on, so this didn't help so much either. Running one thread under full load, makes the system take up to 5 seconds to start another thread. Attempts to work without ThreadPool suffered also from several anomalies and could even crash the .Net executive: The executive is quiet sensitive when one tries to Resume() an already running process etc, which might mean some extra private bookkeeping. Attempts with subclassing BaseThread worked but occasionally resulted in a termination with return code 0 with .Net 1.0 and a reported stack overflow with .Net 1.1. Closing a window while one owns homemade background thread is running creates a zombie thread. Altogether the authors hope, that further releases of .Net like .Net 2.0 will help to improve the situation. Regards, Martin