Solution: ProcessInvocation86.exe: Object is in a zombie state

[Zodman]

I've been battling with this issue for quite some time (getting in a
zombie state when running TestDriven in the debugger). After a
lengthy but complete uninstall of VS2010 (including manually wiping
the registry and file system) I got rid of the issue, but it very
quickly came back.

In the end I narrowed it down to the import of my old Visual Studio
settings file. I found I could go back to an older settings file and
the problem would go away. Re-importing my settings made the problem
come back.

In the end I used a file compare on the two settings files and
manually tracked down and added my required settings to the working
configuration and I still don't get the zombie state when debugging in
TestDriven.

There were so many differences between the two files that I couldn't
narrow down the ultimate cause, but potential suspects are:

* Window positions
* Debugging/symbol settings
* Settings for uninstalled features (e.g. I don't have C++ installed
anymore, but have settings in my import file)
* Something else

The solution then is to reset your Visual Studio settings.

I hope this helps save someone from the pain I've experienced living
with, diagnosing, and fixing this issue.

[Fabian Schmied]

Hi Zodman,

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
the disk.

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:
"https://groups.google.com/group/testdrivenusers/browse_thread/thread/26981c2653134702?hl=en".

Best regards,
Fabian

> --
> 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.
>
>

[Fabian Schmied]

By the way, I can't seem to reproduce the issue with VS 2010 SP1. Has
anyone had the problem with SP1?

Fabian

[Jamie Cansdale]

Thanks for the sharing on this tricky issue! I haven't been able to
repro the issue here, so I've had to go on reports like these.

> (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.

Thanks,
Jamie.

--
http://www.testdriven.net
http://twitter.com/jcansdale
http://weblogs.asp.net/nunitaddin