vstest вылетел при запуске некоторых тестов

Question

Когда я разрешаю запускать все тесты (около 800 тестов) в своем решении, через некоторое время появляется всплывающее окно с ошибкой, что vstest.executionengine.x86.exe перестал работать.

Некоторые примеры деталей проблемы, которые я получаю, находятся здесь:

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.StackruException
  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

В окне вывода VS я получаю:

------ 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) ==========

Когда я попытался включить локальные аварийные дампы, я обнаружил, что такого ключа реестра нет, поэтому я не смог этого сделать.

Я нашел все тесты (22 теста), вызывающие сбой vstest.---. Exe, прокомментировал их и запустил все тесты снова и без этих "неправильных" тестов. Все отлично работает.

Что может быть не так с этими тестами? Все это старые тесты, которые работали в прошлом. Как найти проблему?

Answer 1

По моему опыту, StackoverFlowExeptions очень часто вызывается каким-то рекурсивным вызовом метода, который никогда не завершается. Попробуйте отладить один из этих 22 тестов, чтобы выяснить, является ли рекурсия проблемой.

Answer 2

Есть несколько способов найти причину StackruException в модульном тесте.

Вероятно, самый простой из них - запустить один из 22 тестов, которые вы определили в отладчике Visual Studio. Для этого вы выбираете "Отладить выбранные тесты" в контекстном меню VS Test Explorer. Если произойдет исключение, VS сломается, и вы сможете (очень) заглянуть в стек вызовов, чтобы найти именно то место, где он начинает циклически повторяться в цикле вызова метода.

Для этого цикла могут быть законные причины (например, рекурсивные методы) или может быть ошибка. В первом случае возможно (среди многих других возможностей), что некоторые иерархические данные изменились, и поэтому модульные тесты теперь достигают предела при рекурсивном анализе иерархии.

Если вы не можете запустить модульные тесты в отладчике VS, то вы должны получить дамп памяти сбоя vstest.executionengine.x86.exe с помощью диспетчера задач Windows.

Для этого сначала подождите, пока не появится окно отчетов об ошибках Windows (WER), о котором вы упоминали в своем вопросе. Затем вы открываете диспетчер задач в правильной битности - это 32-битная в вашем случае. Это означает, что если у вас есть 64-битная ОС, вы должны начать C:\Windows\SysWOW64\taskmgr.exe, Если у вас 32-битная ОС, вы можете запустить обычную на C:\Windows\System32\taskmgr.exe,

Затем вы щелкните правой кнопкой мыши на vstest.executionengine.x86.exe обработать и выбрать "Создать файл дампа". Полученный файл.dmp может быть загружен в VS или в WinDbg, где стеки вызовов могут быть проанализированы с использованием расширения SOS.

Для отладки дампа памяти в VS вы можете прочитать больше об этом здесь.

Что касается WinDbg, вы должны загрузить его здесь, установить несколько начальных настроек конфигурации, упомянутых здесь, а затем перечислить потоки и их стеки вызовов, используя команды, указанные здесь.

Теперь вы должны довольно легко найти причину ваших проблем.