QTAgent32_35.exe & QTAgent32.exe System.ExecutionEngineException running unittest in VS2012.2 - by Sebastiaan Rieter

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 783668 Comments
Status Closed Workarounds
Type Bug Repros 13
Opened 4/15/2013 4:22:41 AM
Access Restriction Public


Since the VS2012 update 2 our unit tests will no long work. We did narrow the issue down to the following pre-requisites:

 - VS 2012 Update 2 (prior versions worked fine)
 - Unittest project targetted at 3.5 (targeted to .net 4 is OK)
 - Use a <name>.testsettings file (without such a file, it works fine)

I validated this with a new solution, with just a new c# unittest project, with a single unittest and a newly created test.testsettings file. If I run or debug the test the qtagent just crashed with a "An unhandled exception of type 'System.ExecutionEngineException' occurred in mscorlib.dll"
Sign in to post a comment.
Posted by Sebastiaan Rieter on 3/28/2014 at 12:46 AM
I can confirm that this issue is definitely not solved. Even with Visual Studio 2013.1 we are having these issues (in 2013.1 the workaround deleting the DLL's did not even work). And we eventually decided to move the Unittest project to .NET 4.5 instead of 3.5.
Posted by zpittman on 9/16/2013 at 2:05 PM
I am using visual studio 2012 update 3 and every unit test project targeting the 3.5 framework fails with qtagent crashing. Running the unit test library through vstest.console.exe manually all tests pass successfully.

What does visual studio use to process the unit tests, not vstest I am guessing?
Posted by Vishnu [MSFT] on 8/20/2013 at 9:18 AM
We are investigating the root cause in Dev11 Updates version.

Meanwhile, Please use vstest.console.exe to run your tests. This issue doesn't happen for vstest runner.
If you are using Team build definition, Please use 'Agile Test Runner' instead of MSTest Runner.
Posted by Bebo on 8/16/2013 at 11:33 AM
The workaround does not work on our build server. For now we have had to turn off the unit tests for all of the versions of our software that target the 3.5 Framework. *cringe*
Posted by Bebo on 8/16/2013 at 6:30 AM
Is Aseem Bansal going to find the correct command for the workaround and post it or has he forgotten? :-)
Posted by thijsk on 7/22/2013 at 1:11 AM
Also still broken in Update 3.
Posted by Aseem Bansal [MSFT] on 7/9/2013 at 12:36 AM
Thanks Purni for your feedback and apologies for corrupting your machine. We had tested the command but by mistake the person put a space which caused this problem.

Let me find out what is the best way to delete these 2 ni images forever and then get back.

Aseem Bansal
Posted by Purni Siddarth on 6/12/2013 at 2:52 PM
Managed to get over the access denied issue. The commands specified in the 2nd workaround end up deleting a lot of core files. Now I am unable to open VS 2012. I get the error - "Microsoft.VisualStudio.Shell.Interop.10.0,Version=, culture=neutral,PublicKeyToken=....." or one of its dependencies. The system cannot find the file specified.

Were the 2 commands mentioned in the workaround 2 even tested?
Posted by Purni Siddarth on 6/12/2013 at 10:15 AM

I tried the following and unit tests using Resharper still throw the mscorlib error, IntelliSense has stopped working when I suspended Resharper 7.1.3. Did the work around suggested and installed update 3 and problem still exists. Tried doing the 2nd work around suggested to delete the dlls from Native Image Cache. I get access denied errors even though I am the admin on my machine. This is getting way too frustrating and need a fix please.
1. On 6/3 - Installed Update 2. Unit tests stopped working
2. On 6/4 - Installed Resharper 7.1.3 - Started getting mscorlib exceptions and unable to use unit tests that were working just fine prior to Update 2.
3. On 6/5 - Uninstalled Resharper from my machine and re-installed Resharper 7.1.3 - Same mscorlib exception.
4. On 6/6 - Repaired VS 2012 using the VS 2012 premium installation disc - Same mscorlib exception
5. On 6/8 - Uninstalled Reharper, uninstalled VS 2012. Re-installed VS 2012, re-installed Resharper 7.1.3 - same mscorlib exception
6. On 6/9 - Found this article and tried work around 1 - Installed Update 3 - No change, same mscorlib exception
7. On 6/12 - Saw the update to this article and want to try work around 2 - Get error Access Denied errors even though I am the admin on my machine.
Access is denied.
Access is denied.

Please help. Unable to do my job as a .Net developer with a corrupted VS 2012.

Purni Siddarth
Posted by Sebastiaan Rieter on 4/29/2013 at 1:33 AM
If I add the 10.0 private assembly path instead of the 12.0, it crashes again when I run the unittests and have the test settings file selected.
Posted by Microsoft on 4/28/2013 at 5:40 AM
Hi Sebastiaan,

Thanks for trying this out and sharing further information on it.

Can you please share whether things work if instead of specifying path to 11.0 private assemblies folder, you specify path to 10.0 private assemblies folder?

Visual Studio Product Team
Posted by Sebastiaan Rieter on 4/26/2013 at 2:43 AM
Hi there, I am very glad that you were able to reproduce this issue.

I tried the suggested work around and added the private assembly path of VS 2012. The agent does no longer crash but I get an error now, because my tests (targeted at .net 3.5) expect the VS 2010 assemblies, not the VS2012.

Result Message:    Method ......MyClassInitialize has wrong signature. Parameter 1 should be of type Microsoft.VisualStudio.TestTools.UnitTesting.TestContext.

If I add the VS2010 private assembly path, it crashes again.

Posted by Microsoft on 4/25/2013 at 3:29 AM
Hi Sebastiaan,

Thanks for reporting this issue.

We were able to reproduce the problem and have fixed it in the latest sources. As you stated we also observed that it does not occur when test settings file is not selected in test explorer.

Additionally we also observed that if the test settings file contains the privateAssemblies folder(Like: - %ProgramFiles%\Microsoft Visual Studio 11.0\Common7\IDE\PrivateAssemblies) in the resolution paths, then also the problem does not occur. To add this folder, you should open test settings, go to Unit test -> "Folder to use when the tests are run" section and add the privateAssemblies folder under "path" and make sure that "use load context" is enabled.

Please try this out and do let us know in case it does not work.

Visual Studio Product Team
Posted by Microsoft on 4/17/2013 at 6:39 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Ralph Brandt on 4/17/2013 at 12:39 AM
I had also the same problem with unit tests in Update 2 CTP4 and also only for .NET 3.5.
Posted by Sebastiaan Rieter on 4/16/2013 at 12:14 AM
When testing the solution files, make sure to set the test settings file first from Visual Studio.
Posted by Sebastiaan Rieter on 4/16/2013 at 12:08 AM
I attached a demo solution (visible to Microsoft only). Please let me know if you need more information.
Posted by Microsoft on 4/15/2013 at 7:49 PM
Thank you for submitting feedback on Visual Studio and .NET Framework. In order to efficiently investigate and reproduce this issue, we are requesting additional information outlined below.

Could you please give us a demo project to demonstrate this issue so that we can conduct further research?

Please submit this information to us within 4 business days. We look forward to hearing from you with this information.

Microsoft Visual Studio Connect Support Team
Posted by Rutix on 4/15/2013 at 6:25 AM
We are having the same issue. It indeed only happens for .NET 3.5. I tried it with .NET 4 and .NET 4.5 which works. A fix for this will be greatly appreciated since I now had to deinstall Update 2 to get it back to work again.
Posted by Microsoft on 4/15/2013 at 4:50 AM
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)