vstest.executionengine.x86.exe (32 bit) - Not Closing (VS2012 11.0.50727.1 RTMREL) - by James Grafton

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 771994 Comments
Status Closed Workarounds
Type Bug Repros 15
Opened 11/22/2012 1:59:04 PM
Access Restriction Public


When debugging unit tests, vstest.executionengine.x86.exe (32 bit) opens and closes.

When running unit tests (either run all, or run single test) vstest.executionengine.x86.exe (32 bit) doesn't close automatically. vstest.executionengine.x86.exe seems to keep 3rd party resources (such as sqllite) running, which causes our tests to fail when they're ran twice.

This issue occurs on a new unit test project.

When running MSTEST from the command line, we don't encounter this issue. Our CI server doesn't have an issue running the tests multiple times during the build either.

Running the tests via resharper fixes the issue too.
Sign in to post a comment.
Posted by RPhay on 1/9/2015 at 3:20 PM
We've been running into the same problem however the build servers are also holding the .exe open. Unfortunately since the changes (suggested here) only work on the local machine and do not (appear) to persist anywhere in the solution (and hence can't be checked into source control) the build server continues to keep vstest.executionengine.x86.exe open. I should also note that preemptively killing instances of the process as a post build step on the build server can only be safely done if there's 1 Build Agent per server.

...there's a real lack of documentation regarding how to solve these types of issues on Team Build servers...

I eventually discovered the following article:


It suggested creating a blank test runner file and associating that with the solution. Unfortunately MS fell short here too as the change is only local to the box running Visual Studio, not the Team Build server. Eventually I discovered a setting in the Build Definition where a blank test runner file could be associated with the Build Def and like magic my solution would build on the build server and vstest.executionengine.x86.exe closed when the build completed. Came back this morning ready to convert the rest of our build definitions but lo and behold this solution DOES NOT consistently work. Besides what solutions are built and workspaces are defined the Build Definitions ARE IDENTICAL. I'm completely perplexed as to why adding the blank test runner file fixed the problem in one case but not in others...

Has anyone else encountered this on Team Build servers and if so what was your solution?
Posted by Microsoft on 5/6/2014 at 5:16 AM
in Visual Studio 2013, we added a Menu Option: Test-> Test Settings -> Keep Test Execution Engine Running
You can use turn off this option to kill test execution process automatically at the end of every test run. Can you confirm if you still see the issue after turning off the above setting?

Posted by Dzyann on 4/30/2014 at 6:52 AM
I see this is marked as Solved, but it is really solved? Or it was closed as solved because "It is by design"? I am still encountering this issue.
We have to go and manually kill those processes in the build server because it can not continue building.

I can understand that by design you want the process running, but it is a defective design. Therefore it is a design bug.

Is there a way to solve this in the build server other than having some pre-build event kill all the vstest.executionengine.x86.exe?


Posted by Deon [MSFT] on 4/29/2014 at 12:31 PM
Thank you for reporting this issue. This issue has been fixed in Visual Studio 2013. You can install a trial version of Visual Studio 2013 with the fix from: http://go.microsoft.com/?linkid=9832436
Posted by Microsoft on 11/25/2013 at 8:00 AM
This problem has been resolved in Visual Studio 2013, which has a new menu item "Keep Test Execution Engine Running" under Test / Test Settings.

Oleg Sych
Posted by WindazMate on 11/24/2013 at 7:38 PM
Hello, my company is affected by this bug, when will it become resolved?
Posted by Microsoft on 8/2/2013 at 5:13 PM
The next public release of Visual Studio 2013, will have a new menu item under Test -> Test Settings called "Keep Test Execution Engine Running". This item will be checked by default, which will keep the vstest.executionengine process running between test runs to improve performance. Unchecking this item will make the Test Explorer stop the vstest.executionengine processes automatically at the end of each test run. The value of this item will be stored in the solution user options (.suo) file, allowing you to configure it differently for different solutions.

Feel free to post any further questions or concerns here.

Oleg Sych
Posted by Aseem Bansal [MSFT] on 7/25/2013 at 3:41 AM

I agree with all of you that you should not be required to kill the execution engine manually after each test run, it is too painful. Can you please share the smallest snippet of the code with which I can reproduce the problem so that I can get it fixed?

Aseem Bansal
Posted by PaulRoe on 7/11/2013 at 11:10 AM
If this is functioning as designed then the person that designed it should quit their job at MS and take up more productive work. Perhaps there are openings at McDonalds.

That being said I don't believe that anyone actually thinks that this is working as designed when as a developer I'm forced to open the task manager and kill a process in order to build, happens to me after every test run.

What a pile of crap.
Posted by Keith Hill MVP on 4/15/2013 at 3:42 PM
Happening all the time to me also. Have to say I'm not real impressed with the test framework changes at this point.
Posted by Jeffrey Kotula on 3/22/2013 at 1:12 PM
I agree that this needs to be remedied. This is intolerable. 3 or 4 times a day my builds fail due to this problem, but in no discernible pattern.
Posted by BogusDude on 1/8/2013 at 3:23 AM
You need to re-open this, please. This is a real issue as the process locks the DLL and one cannot build the project again without killing the process.
Posted by Micah Zoltu on 1/6/2013 at 7:14 PM
I'm guessing the theory behind the performance improvements is that you can re-run the tests in quick succession with minimal startup time. However, as it stands now the DLL being tested is locked so you can't make changes to the test and re-run them, therefore negating any performance gains. There is no reason to run tests twice in a row without changing the source code so I can't think of any scenario where this design has an actual performance gain.

Sure, in theory the test running doesn't have to relaunch but all this does is make the developer have to kill the test running (time consuming) which causes a relaunch anyway.

More details: http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/446f42bf-8a35-47ed-b42c-0850794711e9/
Posted by Microsoft on 12/6/2012 at 6:49 AM
Hi Jacqueline

Firstly my apologies for not providing an explanation. I did actually provide one but I dont see this available now.

The reason for why the test execution engine is kept alive is primarily to improve perf. We currently do not have a keep-alive option to change this behavior.

As a workaround, you can create a dummy .testsettings file in TestExplorer->TestSettings , the vstest.executionengine.exe will always be killed at the end of a test run.

Hope that helps.
Allen Mathias
Posted by Jacqueline Peacock on 11/30/2012 at 2:15 PM
This issue is marked as being "Resolved" - because it is working as designed. Could Microsoft please provide a detailed explanation as to why they think this is working as designed?

It seems like a bug to me - given that the behaviour is different between simply running the test (in which case the vstest.executionengine.x86.exe remains running) versus debugging the test (in which case the vstest.executionengine.x86.exe closes automatically after the test completes.

If this is by design - then is there any option that we can set that can change this behaviour? Because our development team is running into the exact same problem - and to workaround the behaviour we have to shut down the vstest.executionengine.x86.exe manually. For a long term solution, we'll need to switch to a 3rdparty product to run our tests.
Posted by Microsoft on 11/22/2012 at 7:06 PM
Thank you for submitting feedback on Visual Studio and .NET Framework. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Microsoft on 11/22/2012 at 2:51 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)