Błąd programu VS 2010 Test Runner „Proces agenta został zatrzymany podczas wykonywania testu”.


101

W Visual Studio 2010 mam kilka testów jednostkowych. Kiedy uruchamiam wiele testów jednocześnie przy użyciu list testów, czasami pojawia się następujący błąd dla jednego lub więcej testów:

Proces agenta został zatrzymany podczas wykonywania testu.

Nigdy nie oznacza to, że ten sam test kończy się niepowodzeniem, a jeśli spróbuję ponownie uruchomić test, kończy się on sukcesem.

Znalazłem ten raport o błędzie w Connect , który wydaje się być tym samym problemem, ale nie oferuje rozwiązania.

Czy ktoś jeszcze widział to zachowanie? Jak mogę tego uniknąć?

Edytować

Nadal mam ten błąd, podobnie jak wielu moich kolegów na tej samej konfiguracji oprogramowania / sprzętu. Oceniłem dotychczas odpowiedzi, ale nie rozwiązują one problemu. Rozpoczynam nagrodę za rozwiązanie tego problemu.


Mam to samo. Zagłębiam się w to, ale jak dotąd nie mam rozwiązania
Mark

Jakieś wiadomości na ten temat? Ten sam problem tutaj ...
Peter Gfader

@Peter, zobacz mój komentarz poniżej zaakceptowanej odpowiedzi. To było moje rozwiązanie, ale nie wiem, czy twój problem jest podobny.
driis

Zachowywałem się tak samo z niezauważonym wyjątkiem. Wyjątek był widoczny dla mnie, gdy uruchamiam Visual Studio na serwerze kompilacji i otrzymałem okno Assert. Z powodu okna assert test nie mógł być kontynuowany.

Odpowiedzi:


41

Właśnie doświadczyłem podobnego problemu: niektóre testy kończą się niepowodzeniem i są różne w różnych przebiegach testowych. Nie wiem dokładnie, dlaczego tak się dzieje, ale zaczęło się to dziać, kiedy dodałem finalizator do jednego z moich zajęć. Kiedy wyłączam finalizator - problem znika. Kiedy włączam finalizator - problem wraca.

W tej chwili nie wiem, jak to przezwyciężyć.


16
DZIĘKI - ta odpowiedź doprowadziła mnie do rozwiązania. Mam tylko finalizator dla kilku typów i oczywiście usunięcie ich również rozwiązało problem. Po dalszych badaniach odkryłem subtelny błąd w jednym finalizatorze, który wystąpił tylko wtedy, gdy w konstruktorze został zgłoszony wyjątek, a finalizator próbuje sfinalizować obiekt, który nie jest w pełni skonstruowany. Wniosek: jeśli w finalizatorze typu wystąpi wyjątek, a finalizator zostanie uruchomiony przed zakończeniem wszystkich testów, program Visual Studio wyświetli napotkany przeze mnie błąd; bez dalszych wyjaśnień i na wyrywkowych testach.
driis

6
W moim kodzie nie ma finalizatorów / destruktorów ... ~ MyClass () i otrzymuję ten sam błąd. Testy z Resharperem są zielone
Peter Gfader

6
Problem z nieprzechwyconymi wyjątkami w finalizatorach to szczególny przypadek nieprzechwyconych wyjątków w zadaniach w tle, które mogą zostać uruchomione lub zaplanowane (być może niejawnie) przez jakiś test i mogą kontynuować wykonywanie, nawet jeśli test został zakończony.
satorg

1
Tak samo jak Peter, biegacz testowy Resharper daje mi wszystko zielone. Uruchomienie testów VS 2010 kończy się niepowodzeniem na klasie z destruktorem.
RyBolt

1
Przypadkowo zakodowałem nieskończoną pętlę rekurencyjną w mojej metodzie Dispose (), która również to spowodowała.
Robert

88

Ten komunikat jest spowodowany przez wyjątek w wątku innym niż wątek wykonujący test . Wszystkie dotychczasowe odpowiedzi sprowadzają się do tego prostego wyjaśnienia. Jest to znany błąd programu Visual Studio, który nie wyświetla w takim przypadku żadnych sensownych informacji.

Program uruchamiający testy programu Visual Studio całkowicie się dławi, jeśli wątek inny niż wykonujący wątek testowy zgłosi wyjątek: zostanie połknięty i nie ma wyjścia, nie ma szans na przechwycenie i debugowanie oraz nic poza spalonym, tlącym się bałaganem, który miał być Twoją jednostką test.


To samo stało się ze mną - mój test generował oddzielny wątek, który otrzymywał wyjątek. Wyłapanie wyjątku w wątku pozwala mi przynajmniej go wydrukować i wiedzieć, co się dzieje. Uważaj jednak, aby nie umieścić Assert.Fail () w bloku catch wątku - powoduje to oddzielny wyjątek, który przenosi Cię z powrotem do miejsca, w którym zacząłeś.
Kyle Krull

4
To samo dla mnie, z wyjątkiem przepełnienie stosu, które są o wiele trudniejsze do wyśledzenia w języku C # w porównaniu do Java ...
John Gardner

Rzeczywiście, zauważyłem, że stało się to, gdy zacząłem używać obiektów Thread i wywoływałem Abort (), aby je zatrzymać.
espaciomore

1
Dzieje się tak również, gdy async voidmetoda, która jest wywoływana podczas testu, zgłasza wyjątek
Mathias Becher

1
Zwróć uwagę, że trx może zawierać informacje o błędzie, możesz je zobaczyć, otwierając je w edytorze tekstu lub w programie Visual Studio i klikając hiperłącze Błąd uruchomienia testowego w oknie Wyniki testu .
Ohad Schneider

16

Miałem ten problem i okazało się, że jest to problem w moim kodzie, którego Framework Testów nie wychwytuje poprawnie. Mała przypadkowa refaktoryzacja pozostawiła mi ten kod:

public void GetThingy()
{
    this.GetThingy();
}

Jest to oczywiście nieskończona rekurencja i spowodowała wyjątek StackOverflowException (chyba). Powodowało to przerażające: „Proces agenta został zatrzymany podczas wykonywania testu”.

Szybka inspekcja kodu pokazała mi problem, a moje testy działają teraz poprawnie. Mam nadzieję, że to pomoże - może warto sprawdzić kod w poszukiwaniu problemów, a może wyodrębnić trochę do aplikacji konsolowej i sprawdzić, czy tam działa poprawnie.


3
To nie jest problem (wiem, ponieważ za każdym razem są różne testy, które kończą się niepowodzeniem), ale dziękuję za poświęcenie czasu na odpowiedź.
przejazd

6
+1, ponieważ jest to jedna z wielu prawidłowych odpowiedzi na ten problem. Wyjątek SO w metodzie sstatic na jednej z moich klas spowodował ten problem.
Peter T. LaComb Jr.

6
+1, też to widziałem. Debugowanie testu (w VS 11) znajduje problem dość szybko.
Jeremy McGee

Zgadzam się z Jeremym. Jeśli debugujesz testy jednostkowe, należy je zatrzymać w miejscu zgłoszenia wyjątku. Jeśli jednak po prostu uruchomisz testy jednostkowe, wszystkie pojawią się z zielonymi światłami. Bardzo dziwne.
Andrew Stephens

8

Udało mi się znaleźć źródło mojego problemu, przeglądając plik wyników testu (/TestResults/*.trx). Zawierał on wszystkie szczegóły wyjątku, który wystąpił w wątku w tle, a kiedy rozwiązałem ten wyjątek, agent przetworzył zatrzymany ... ”błąd zniknął.

W moim przypadku przypadkowo uruchomiłem GUI w moim teście jednostkowym, co ostatecznie spowodowało wyrzucenie wyjątku System.ComponentModel.InvalidAsynchronousStateException.

Więc mój plik .trx zawierał:

   <RunInfo computerName="DT-1202" outcome="Error" timestamp="2013-07-29T13:52:11.2647907-04:00">
    <Text>One of the background threads threw exception: 
System.ComponentModel.InvalidAsynchronousStateException: An error occurred invoking the method.  The destination thread no longer exists.
at System.Windows.Forms.Control.WaitForWaitHandle(WaitHandle waitHandle)
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at System.Windows.Forms.Control.Invoke(Delegate method)
...
</Text>
  </RunInfo>

Nie dostarczyło to żadnych informacji o tym, który test spowodował błąd, ale pokazało mi, gdzie był wyjątek, co było bardzo przydatne.


5

Ten komunikat jest zwykle generowany, gdy proces testowy ulega awarii i może się zdarzyć, gdy wystąpi nieobsługiwany wyjątek w wątku w tle, nastąpi przepełnienie stosu lub jawne wywołanie Process.GetCurrentProcess().Kill()lub Environment.Exit. Inną możliwą przyczyną jest naruszenie dostępu w niezarządzanym kodzie.

Coś, o czym nikt nie wspomniał, to fakt, że w dzienniku zdarzeń mogą znajdować się dodatkowe informacje. Zwykle nie dostaniesz zbyt wielu informacji o tym, dlaczego test zakończył się awarią w wynikach, jednak w przypadku nieobsłużonego wyjątku w wątku w tle, struktura testowa zapisuje szczegóły do ​​dziennika zdarzeń aplikacji ze źródłem VSTTExecution. Jeśli w dzienniku zdarzeń nie ma żadnych informacji, prawdopodobnie jest to jedna z innych przyczyn wymienionych powyżej.


4

W moim przypadku rozwiązanie zostało rozwiązane przez sprawdzenie okna wyjściowego .

„QTAgent32.exe” (Managed (v4.0.30319)): załadowano „C: \ TestResults \ bdewey_XXXXXX072 2011-01-11 17_00_40 \ Out \ MyCode.dll”, załadowano symbole. E, 9024, 9, 2011/01/11, 17: 00: 46.827, XXXXX072 \ QTAgent32.exe, Unhandled Exception Caught, raportowanie przez Watson: [Komunikat o wyjątku]

W moim przypadku miałem FileSystemWatcher, który generował błąd w osobnym wątku.


jak to rozwiązałeś Używam przykładowego kodu z M $, który opakowuje FileSystemWatcher w usługę i tworzy wokół tego przepływ pracy WF. Dostaję ich dużo ...
ekkis

W moim przypadku dwa testy zakończyły się niepowodzeniem. Kiedy przeszedłem do okienka Wyjście i wybrałem Testy , wspomniałem: „Jeden z wątków w tle zgłosił wyjątek” ... w rzeczywistości czekało na mnie 9 NullReferenceExceptions ze śladami stosu. Dzięki, to było bardzo pomocne!
Qwertie

3

Napotkałem ten sam problem i rozwiązałem go podczas usuwania

Environment.Exit(0);

Jestem więc prawie pewien, że ten błąd występuje, gdy test lub testowana metoda powoduje zakończenie procesu wykonywania.


2

Dzięki za zadanie pytania. Właśnie natknąłem się na ten problem i znalazłem przyczynę, na którą możesz się natknąć.

Mógł wystąpić asynchroniczny wyjątek

Podczas konfiguracji testowej tworzę obiekt, który kolejkuje wątek roboczy w puli wątków. Jeśli przeprowadzę debugowanie wystarczająco szybko, mój kod przechodzi.

Jeśli wątek roboczy uruchamia się i pojawia się błąd PRZED zakończeniem konfiguracji testu, otrzymuję wynik Przerwano bez podania przyczyny.

Jeśli wątek roboczy uruchamia się i pojawia się błąd PO rozpoczęciu testu, otrzymuję wynik: Błąd - Proces agenta został zatrzymany podczas wykonywania testu.

Ważna uwaga: jest to komponent, którego używam w kilku moich testach. Jeśli środowisko testowe napotka zbyt wiele z tych błędów, przerywa pozostałe testy.

Mam nadzieję że to pomoże


Dziękuję za Twoją odpowiedź. Zdaję sobie sprawę, że asynchroniczne wyjątki mogą powodować coś podobnego do tego, co widzę, ale jestem prawie pewien, że tak nie jest. Kod jest przeznaczony dla aplikacji internetowej i nie robimy niczego asynchronicznie. Wydaje się również, że test, który się nie powiedzie, jest losowy.
driis

2

Dodałem bloki try / catch do descructora ~ ClassName () {}, które zostały zdefiniowane w dowolnej klasie biorącej udział w moich testach. To rozwiązało problem.

~MyClass()
{
    try
    {
        // Some Code
    }
    catch (Exception e)
    {
        // Log the exception so it's not totally hidden
        // Console.WriteLine(e.ToString());
    }
}

2

Aby dowiedzieć się, gdzie został zgłoszony wyjątek, kliknij hiperłącze „Błąd uruchomienia testowego” obok ikony wykrzyknika w oknie Wyniki testu. Otworzy się okno ze śladem stosu.

To bardzo pomaga w wyśledzeniu błędu!


1

Miałem ten sam problem i był on spowodowany przez finalizator niezarządzanego zasobu (program zapisujący plik, który z jakiegoś powodu nie został prawidłowo usunięty).

Po zawinięciu kodu finalizatora w próbny chwyt, który połyka wyjątek, problem zniknął. Nie polecam połykania takich wyjątków, więc oczywiście mądrze byłoby dowiedzieć się, dlaczego wyjątek występuje w pierwszej kolejności.


1

Zdarzało mi się to przy dziwnych okazjach, a winowajca prawie zawsze się nawija.

O dziwo, wszystkie testy działałyby dobrze na maszynach programistycznych, a następnie losowo kończyły się niepowodzeniem na serwerach kompilacji.

Po bliższym przyjrzeniu się okazało się, że chociaż testy były wymieniane jako zaliczone na dev boxach, były wyjątki. Wyjątki były umieszczane w osobnym wątku, który nie został odebrany jako błąd.

Szczegóły wyjątku były rejestrowane w śladzie testu, więc byliśmy w stanie zidentyfikować, który kod / testy wymagają modyfikacji.

Mam nadzieję, że to komuś pomoże.


0

W moim przypadku miałem kilka testów jednostkowych dla usługi WCF. Ta usługa WCF uruchamiała 2 liczniki czasu.
Te timery spowodowały efekty uboczne.
-> Domyślnie wyłączam te timery i wszystko jest w porządku!

BTW: Używam WCFMock do fałszowania usługi WCF, więc mam „prawdziwe” testy jednostkowe wokół mojej usługi WCF


0

Ten błąd został również spowodowany przez Finalizer dla mnie.
Finalizer aktywnie wywoływał kod bazy danych, który nie został wyszydzony. Znalezienie go zajęło mi trochę czasu, ponieważ nie była to klasa, którą napisałem, a odniesienie do niego było pogłębione o kilka klas.


0

Napotkałem podobny problem, gdy test kończy się niepowodzeniem w TestInitialize, a także uruchamia kod z ddl z innego z moich projektów. Otrzymuję komunikat o błędzie opisany powyżej i jeśli spróbuję zdebugować test, test jest po prostu przerywany bez żadnych szczegółów wyjątku.

Podejrzewam, że problem może polegać na tym, że biblioteki DLL z mojego innego projektu pochodzą z projektu Visual Studio 2012 i przeprowadzam testy w projekcie VS2010 i / lub prawdopodobnie wersje dll UnitTestFramwork z 2 projektów są niezgodne.


0

Problem może również zostać wywołany przez wyjątek lub Stackoverflow w konstruktorze klasy TestClass.


0

Ponieważ ten błąd może mieć wiele różnych przyczyn, chciałbym dodać kolejną dla kompletności tego wątku.

Jeśli wszystkie testy są przerywane zgodnie z opisem w OP, przyczyną może być nieprawidłowa konfiguracja projektu. W moim przypadku docelowy framework został ustawiony na .NET Framework 3.5. Ustawienie go na wyższą wersję za pośrednictwem strony właściwości projektu (zakładka Aplikacja ) rozwiązało problem.


0

Udało mi się ustalić, co jest przyczyną mojego problemu, przeglądając Dzienniki systemu Windows > wpisy dziennika aplikacji w Podglądzie zdarzeń systemu Windows . Poszukaj wpisów w czasie, gdy test został zbombardowany. Miałem Error wpis podobny do poniżej:

QTAgent32_40.exe, PID 10432, Thread 2) AgentProcess:CurrentDomain_UnhandledException: IsTerminating : System.NullReferenceException: Object reference not set to an instance of an object.
   at XXX.YYY.ZZZ.cs:line 660
   at XXX.YYY.AAA.Finalize() in C:\JenkinsSlave\workspace\XXX.YYY.AAA.cs:line 180

To rzeczywiście był zerowy wyjątek odwołania w metodzie wywołanej z finalizatora klasy.


0

Oto wskazówka dla każdego, kto zadaje sobie to stare pytanie i zastanawia się, co jest wyrzucane z ich wątków. Korzystanie z Task.Run (w przeciwieństwie do, powiedzmy, Thread.Start) zgłosi wyjątki wątków potomnych znacznie bardziej niezawodnie. Krótko mówiąc, zamiast tego:

Thread t = new Thread(FunctionThatThrows);
t.Start();
t.Join();

Zrób to:

Task t = Task.Run(() => FunctionThatThrows());
t.Wait();

Twoje dzienniki błędów powinny być znacznie bardziej przydatne.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.