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

В окне вывода 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) ========== 

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

I Находится все испытания (22 теста), вызывающие сбой vstest .---. Exe, прокомментировали их и снова проверили все тесты и без этих «неправильных» тестов. Все работает нормально.

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

Answer 1

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

Answer 2

Существует несколько способов найти причину ошибки StackOverflowException в модульном тесте.

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

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

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

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

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

Для отладки дампа памяти в VS вы можете узнать больше об этом here.

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

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