32

We just "upgraded" from Visual Studio 2008 to Visual Studio 2012. We updated our unit tests and now they pass when running them individually but when I try to Run All, I got the following error:

The active Test Run was aborted because the execution process exited unexpectedly. To investigate further, enable local crash dumps either 
at the machine level or for process vstest.executionengine.appcontainer.x86.exe. Go to more details: [http://go.microsoft.com/fwlink/?linkid=232477][1]

So I went to the link and followed the instructions to add the registry key to enable local crash dumps. The error message then changed to:

The active Test Run was aborted because the execution process exited unexpectedly. Check the execution process logs for more information. 
If the logs are not enabled, then enable the logs and try again.

Apparently it noticed the changes that I made in the registry to enable crash. However, when I looked in %LOCALAPPDATA%\CrashDumps, no files were being created.

If I run one test at a time (or even a few tests at a time), I can get them all to pass. The problem is only with Run All.

Has anyone else encountered similar problems? If so, how did you solve them?

Essentially the same question was asked on MSDN, but the answer was something like "click the link to the crash dump". That answer doesn't help me because I don't see any link to the crash dump and I am unable to get the crash dump to be generated.

This question on StackOverflow is also similar, and ended up resulting in a bug being logged on Microsoft Connect (which looks to be deferred for some reason), but my problem might be different because my code has nothing to do with "async tasks" (I don't think).

EDIT: The problem went away, seemingly on its own, but the problem was likely an exception that wasn't being caught in the unit test code, as some of the answers below suggest. However, I'm still confused as to why the problem only appeared with Run All, and not when running smaller groups of tests or Debug All.

Community
  • 1
  • 1
sgryzko
  • 2,397
  • 2
  • 22
  • 37
  • Are you able to run subsets of tests and have it crash or not? Without seeing your code it's hard to guess what might be causing the problems. – Mike Parkhill Oct 04 '13 at 00:42
  • @MikeParkhill Yes, if I break up the tests into small enough subsets, they all can run without crashing. – sgryzko Oct 04 '13 at 15:36
  • What I'm trying to get at though is if there's a particular subset that causes a crash. It might be one or two tests together that cause the problem. Knowing which might expose the problem. – Mike Parkhill Oct 04 '13 at 23:21
  • Strangely, no. There doesn't seem to be a pattern. I run all and it fails. Then I run maybe 50 and it fails. Then I run 25 and it works. Then the next 25 work too! In other words, I can't narrow it down to a particular test or group of tests. Every test eventually passes if I try smaller and smaller groups. – sgryzko Oct 06 '13 at 00:33
  • Self-remedy.. interesting VS! – vulcan raven Dec 31 '13 at 09:56
  • Hi, did you manage to create some kind of CrashDump or logs (e.g. log of MSTest.exe like the "execution process logs" mentioned in the error message? I tried to activate logs in MSTest.exe.config but without success. Thx. – Sebastian Mar 08 '17 at 14:22
  • @Sebastian no sorry I didn't get a crash dump – sgryzko Mar 13 '17 at 13:11

8 Answers8

43

I had the same problem, the tests failed for apparently no reason. Later I found that a buggy method was causing a StackOverflowException. When I fixed my bug, the VS bug disappeared.

Maybe it works most of the time because you don't run the faulty code.

Doug
  • 6,322
  • 3
  • 29
  • 48
  • Used @interrobang's answer and got your StackOverflowException. I realized that one of my classes (classA) initialized another class object (classB) and classB initialized a classA. That made some kind of infinite loop, but there was no for loop to look for so I was confused. – Jared Beach Feb 11 '14 at 15:01
  • 8
    Also a `StackOverflowException` for me. Debug All Tests worked and actually produced a program error when the SOE was triggered, allowing me to break and examine the callstack. – Slate Feb 19 '14 at 16:04
  • I too faced StackOverFlowException – Koshimitsu Aug 06 '14 at 20:15
  • I also had a stack overflow bug (via recursive method that never met its base case). I can't call it a StackOverFlowException b/c, obviously/frustratingly, an exception was not thrown. – brntsllvn Jul 31 '16 at 00:50
22

The best workaround I have so far is to debug all. This is done via TEST -> Debug -> All Tests. It's obviously slower but it doesn't crash.

sgryzko
  • 2,397
  • 2
  • 22
  • 37
  • Thanks this helped me identify the issue. It was a stackoverflow exception. – nawfal May 08 '17 at 18:18
  • Any idea as to why this works? My VS crashes when I right-click > Run Test(s). But if I do Test > Run All Tests or Test > Debug All Tests it works fine.... My guess is the right click shortcut runs a different command and that is broken somehow but the commands that start with clicking the Test toolbar button are not? – Ju66ernaut Jun 17 '20 at 16:21
4

This can happen with certain errors, such as a stackoverflow. Presumably this is crashing the test runner and so it can't continue when it hits a test that causes the problem.

The solution, therefore, is to run all tests in debug (from the Test -> Debug menu) and Visual Studio will show errors like these.

noelicus
  • 14,468
  • 3
  • 92
  • 111
4

For anyone else who may need this in future: My test runner was crashing when a console specific command (Environment.Exit(-1);) was executed via the unit test. Even running in debug mode would just crash - I could not get at a useful error message.

So my scenario is different to the main question scenario in that a) debug didn't work at all b) run all vs run individually made no difference. That is because my error scenario always arose but the stack overflows of the original question did not.

The bottom line: test runner is bad and will crash if it finds something it doesn't like. You need to manually isolate and work out what the Bad Thing™ is.

Visser
  • 188
  • 1
  • 10
2

For someone else looking for this: I had some code that was calling System.Environment.Exit(123), and I was unaware of this. So check for any code that terminates the process.

Greg Bair
  • 670
  • 6
  • 20
1

I've just had the same problem. It turned out that was my code - there was an infinite loop of WCF service calls. In your case this might be something else. So my proposal is to either remember (logs in version control system?) or to figure out (by excluding different tests from run, e.g. with bisection method) which place in code leads to this behavior. And wuala! It's cause of the problem and at the same time bug in code.

UPDATE As for questions in your EDIT. It could happen that running smaller groups of tests didn't reproduce the issue. In this case, given those groups included all tests, one can make an assumption that some tests interfere. Maybe some static data or fields in a test class? As for running tests in debug mode - I'm not surprised. Visual Studio test runner behaves different in "Run" mode vs "Debug" one.

EvAlex
  • 2,888
  • 1
  • 20
  • 24
0

I had a similar problem except that it wasn't a stackoverflow exception. It was caused by my project under test using Entity Framework and the NUnit project not having references included to the EntityFramework and EntityFramework.SqlServer modules. Adding the references to Entity Framework modules fixed it.

Community
  • 1
  • 1
GrandMasterFlush
  • 6,269
  • 19
  • 81
  • 104
0

Just had the same problem. Closing and reopening visual studio fixed it for me.

t_warsop
  • 1,170
  • 2
  • 24
  • 38