vstest crashed when running some particular tests

Question

When I let run all tests (ca. 800 tests) in my solution, after some time a popup window with error is shown that vstest.executionengine.x86.exe has stopped working.

Some Examples of problem details, that I get are here:

Problem signature:
  Problem Event Name:   CLR20r3
  Problem Signature 01: vstest.executionengine.x86.exe
  Problem Signature 02: 14.0.23107.0
  Problem Signature 03: 559b7b6c
  Problem Signature 04: mscorlib
  Problem Signature 05: 4.6.1076.0
  Problem Signature 06: 56d79fa2
  Problem Signature 07: 0
  Problem Signature 08: ffffffff
  Problem Signature 09: System.StackOverflowException
  OS Version:   6.1.7601.2.1.0.256.48
  Locale ID:    1051
  Additional Information 1: 5cd2
  Additional Information 2: 5cd2742c12da7dd4b1d5bf900186a452
  Additional Information 3: 2fe2
  Additional Information 4: 2fe276cacf1c00cd7a2aed7b27f5a5f9

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: vstest.executionengine.x86.exe
  Application Version:  14.0.23107.0
  Application Timestamp:    559b7b6c
  Fault Module Name:    clr.dll
  Fault Module Version: 4.6.1076.0
  Fault Module Timestamp:   56d7a0ff
  Exception Code:   c00000fd
  Exception Offset: 00003567
  OS Version:   6.1.7601.2.1.0.256.48
  Locale ID:    1051
  Additional Information 1: 0127
  Additional Information 2: 01273c850b3b6fc6378d3f666887788e
  Additional Information 3: 0786
  Additional Information 4: 07866ddaac895bff9a7fa791fcdaa4a7

In VS output window I get:

------ Run test started ------
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.x86.exe. Go to more details: http://go.microsoft.com/fwlink/?linkid=232477
========== Run test finished: 0 run (0:03:55,0267906) ==========

When I tried to enable local crash dumps I found out that there is no such registry key so I haven't been able to do it.

I Located all test (22 tests) causing crash of vstest.---.exe, commented them and run all test again and without those "wrong" tests. Everything runs fine.

What can be wrong with those tests? They all are old tests which was working in past. How to locate a problem?

Answer 1

In my experience, StackoverFlowExeptions are very often caused by some recursive method call that never terminates. Try debugging one of those 22 test to find out if recursion is the issue.

Answer 2

There are multiple ways to find the cause of a StackOverflowException in a unit test.

Probably the easiest one is to run one of the 22 tests you've identified under the Visual Studio debugger. For this you select "Debug selected tests" in the context menu of VS Test Explorer. If the exception happens, VS will break and you will be able to look (very) deep into the call stack to find exactly the place where it begins to cycle in a method call loop.

There might be legitimate reasons for this loop (like recursive methods) or there might be a bug. In case of the former it's maybe possible (amongst many other possibilities) that some hierarchical data changed and therefore the unit tests now hit a limit when analyzing the hierarchy recursively.

If you cannot run the unit tests in the VS debugger then you have to get a memory dump of the crashing vstest.executionengine.x86.exe using Windows Task Manager.

For that you first wait until the window of the Windows Error Reporting (WER), that you mentioned in your question, pops up. Then you open Task Manager in the correct bitness - that is 32-bit in your case. That means if you have a 64-bit OS, you have to start C:\\Windows\\SysWOW64\\taskmgr.exe . If you have a 32-bit OS you can run the normal one at C:\\Windows\\System32\\taskmgr.exe .

Then you right click on the vstest.executionengine.x86.exe process and choose "Create Dump File". The resulting .dmp file can be loaded into VS or into WinDbg where the call stacks can be analyzed using the SOS extension.

For debugging a memory dump in VS you can read more about it here .

Regarding WinDbg you have to download it here , set up a few initial configuration settings mentioned here and then list the threads and their call stacks using the commands stated here .

Now you should pretty easily get to the root cause of your problems.