As always, Raymond Chen has the answer on his blog. Note that his test appears to have been run using unmanaged code. My guess is that there's nothing in the .NET framework that actually limits the number of threads per process and that the limit would be enforced by the O/S. If that's truly the case then his test is still valid.
Also, I'm not sure if it's different between 32-bit and 64-bit machines, I would imagine his results are dependent on RAM size and 32bit/64bit CPU along with possibly the number of CPUs. All that said, it looks like he was able to get 13000 threads created.
The big issue with 13k threads running is that the time spent context switching is sure to eat up all the available cpu and you're likely to be getting little to no work done.
If the application you're looking into is creating a lot of threads that are supposed to be doing intense work, you might not be getting a process hang as much as running into issues with the amount of context switching taking place. Obviously the most common issue in a multi-threaded application is a resource deadlock, but there are many tools available to troubleshoot that scenario.
Try the following links about deadlocks to determine if that's what you're actually running into: