vstest.executionengine.x86.exe not closing

Question

I\'ve encountered an error when running unit tests. If I Debug the unit tests vstest.executionengine.x86.exe runs, then closes when the tests pass.

If I just run the

Answer 1

For what its worth, I ran into this same situation and it turned out that I had a test that did not properly clean up all of its resources. In my specific case there was a background thread with a network connection open that did not get closed before the test exited. Not sure why exiting the test did not close this for me, but when i fixed my code to properly dispose of all the resources I opened, everything worked as expected. I did not have to add any hacks to kill the vstest.executionengine.exe, nor did I have to opt out of Test -> Test Settings -> Keep Test Execution Engine Running

Answer 2

This is by design.

The vstest.executionengine.exe is restarted only when we detect a change in the configuration between two consecutive test runs. This helps ensure we aren't taking a perf hit on process restarts unnecessarily.

Product Update With VS2013 we have a new menu item under Test -> Test Settings called "Keep Test Execution Engine Running". You can uncheck this to opt out of the default behavior.

Answer 3

The easiest approach is to go to windows task manager. Look out for vstest.executionengine.exe process running in the background. Kill that process and it should work fine now.

Answer 4

I worked around this by using the following as a pre-build event on the affected test projects:

for 64-bit:

taskkill /F /IM vstest.executionengine.exe /FI "MEMUSAGE gt 1"

or for 32-bit:

taskkill /F /IM vstest.executionengine.x86.exe /FI "MEMUSAGE gt 1"

This silently kills the execution engine before building the test project. The /FI "MEMUSAGE gt 1" stops the command (and therefore the build) from failing if the execution engine isn't running.

Answer 5

I had this issue when running test using Resharper's test runner which doesn't seem to respect the Test-->Test Settings-->Keep Test Execution Engine Running setting. In my case it was causing the build to fail with the following error:

warning MSB3026: Could not copy "...\SQLite.Interop.dll" to "bin\Debug\x86\SQLite.Interop.dll". Beginning retry 10 in 1000ms. The process cannot access the file 'bin\Debug\x86\SQLite.Interop.dll' because it is being used by another process.

Adding a pre-build event to the test project as @HappyCat suggested worked for me. I also needed to wrap it in an if statement to prevent it from running on the build server and interfering with other jobs.

if $(ConfigurationName) == Debug (
    echo "attempting to kill vstest to prevent access denied on sqlite.interop.dll"
    taskkill /F /IM vstest.executionengine.x86.exe /FI "MEMUSAGE gt 1"
)

Answer 6

I know this is old but I thought I'd throw in something I just discovered.

A test I was running had some objects in it that implemented IDisposable, so the code analysis told me so should my test class. It took a while to realize it, but when this.Dispose(); was getting called on the implementation of that interface when I put it on my test class, it was actually throwing a StackOverflow exception. So I just yanked the interface and let CA continue to whine.

I did not need to toggle 'Keep Test Execution Engine Running'.