I also struggled with the problem. I think it is a race condition
between three actions:
1 - The Visual Studio debugger detects an uncaught exception.
2 - The Visual Studio debugger loads symbols for mscorlib and other
system assemblies that are on the call stack.
3 - The test runner process terminates due to the exception.
It seems that step 3 sometimes occurs while step 2 is still running.
(Why this is, I can't say. Jamie, if you're reading this: any idea?
Does the TestDriven.NET add-in terminate the test runner process?)
Therefore, when step 2 is finished, the debugger can no longer find
the process it wanted to debug, it (process) is in a zombie state.
Unfortunately, the debugger doesn't recover well from that scenario -
it will wait for several timeouts and sometimes keep files locked on
I've found that you can circumvent the problem in two ways:
- Configure the Visual Studio .NET debugger to break on exceptions
_being thrown_. This causes the debugger to execute steps 1 and 2 long
before the process is terminating (step 3). (If you have it break for
_uncaught_ exceptions only, the issue will occur.)
- Clear your local symbol cache directory (or configure the Visual
Studio .NET debugger not to load any symbols for the system
assemblies). See also this thread:
> You received this message because you are subscribed to the Google Groups "TestDriven.NET Users" group.
> To post to this group, send email to testdri...@googlegroups.com.
> To unsubscribe from this group, send email to testdrivenuse...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/testdrivenusers?hl=en.
> (Why this is, I can't say. Jamie, if you're reading this: any idea?
> Does the TestDriven.NET add-in terminate the test runner process?)
No, it doesn't terminate the test runner process. It simply detaches
from the process and leaves it running. I've ended up being super
paranoid about how I interact with the debugger due to hard to fix
issues over the years. I've got to the point where I only execute
built in commands (that a user could have executed themselves), rather
than using the debugger automation API. I figured that because more
people use the built in commands, they should be better tested and
less prone to strange race conditions! I suspect the zombie state
issue may also happen when a user attaches and detaches from a process
using the same commands as TestDriven.Net.
> By the way, I can't seem to reproduce the issue with VS 2010 SP1. Has
> anyone had the problem with SP1?
I really hope it has been fixed in SP1! Please let me know if this
does eventually reappear.