Mamy aplikację napisaną przeciwko .NET 4.0, która zawiesiła się w weekend, umieszczając w dzienniku zdarzeń następujący komunikat:
Aplikacja: PnrRetrieverService.exe Framework Wersja: v4.0.30319
Opis: Proces został zakończony z powodu błędu wewnętrznego środowiska wykonawczego .NET pod adresem IP 791F9AAA (79140000) z kodem zakończenia 80131506.
To jest w pudełku z systemem Windows Server 2003 R2 Standard Edition. Wyszukiwanie tego błędu w Google nie przyniosło żadnych istotnych wyników. Na przykład to nie występuje w VS Studio, ale zamiast tego na pudełku produkcyjnym; gdy usługa została ostatecznie ponownie uruchomiona, nie wystąpiły dalsze problemy.
Jak można zdiagnozować błąd w środowisku wykonawczym .NET?
.net
runtime-error
executionengineexception
ALEXintlsos
źródło
źródło
Odpowiedzi:
To paskudny, ExecutionEngineException. Począwszy od .NET 4.0, ten wyjątek natychmiast kończy działanie programu. Ogólną przyczyną jest uszkodzenie stanu sterty zebranych śmieci. Co z kolei jest niezmiennie powodowane przez niezarządzany kod. Dokładna lokalizacja w kodzie, w której zgłaszany jest ten wyjątek, nie jest pomocna, ponieważ uszkodzenie zwykle występowało na długo przed wykryciem uszkodzenia.
Znalezienie dokładnej przyczyny tego stanu rzeczy będzie trudne. Przejrzyj niezarządzany kod, którego może używać Twoja usługa. Podejrzewane problemy środowiskowe, jeśli nie ma oczywistego kandydata, źle działające skanery złośliwego oprogramowania są znane. Jeśli powtarza się bardzo słabo, podejrzewaj problemy sprzętowe, takie jak miękkie błędy pamięci RAM.
źródło
Błąd we współbieżnej implementacji usługi Garbage Collection na platformie x64 .Net 4 może powodować to, jak określono w następującym wpisie bazy wiedzy firmy Microsoft:
ExecutionEngineException występuje podczas wyrzucania elementów bezużytecznych
Najpierw powinieneś przeprowadzić głęboką eksplorację minidump, aby upewnić się, że problem wystąpił podczas czyszczenia pamięci.
Lokalizację minizrzutu można zwykle znaleźć we wpisie raportowania błędów systemu Windows w dzienniku zdarzeń następującym po wpisie awarii. Następnie baw się dobrze z WinDbg!
Najnowszą dokumentację dotyczącą korzystania z
<gcConcurrent/>
elementu konfiguracji, aby wyłączyć współbieżne lub (w .NET 4 i nowszych) wyrzucanie elementów bezużytecznych w tle, można znaleźć tutaj .źródło
Wystąpiły „błędy wewnętrzne” w środowisku wykonawczym .NET, które okazały się być spowodowane błędami w moim kodzie; Nie myśl, że tylko dlatego, że był to „błąd wewnętrzny” w środowisku wykonawczym .NET, nie ma błędu w kodzie jako głównej przyczyny. Zawsze zawsze obwiniaj swój własny kod, zanim obwiniasz kogoś innego.
Miejmy nadzieję, że masz rejestrowanie i informacje o wyjątkach / śladach stosu, które wskazują, gdzie zacząć szukać, lub że możesz powtórzyć stan systemu przed awarią.
źródło
Dla tych, którzy przyjeżdżają tu z Google, w końcu natknąłem się na to pytanie SO , a ta konkretna odpowiedź rozwiązała mój problem. Skontaktowałem się z firmą Microsoft w sprawie poprawki za pośrednictwem czatu na żywo w witrynie support.microsoft.com i wysłali mi łącze do poprawki pocztą e-mail.
źródło
Po latach zmagania się z tym problemem w wielu aplikacjach wydaje się, że Microsoft w końcu zaakceptował go jako błąd w .NET 4 CLR, który to powoduje. http://support.microsoft.com/kb/2640103 .
Wcześniej „naprawiałem” to, zmuszając garbage collectora do działania w trybie serwera (gcServer enabled = „true” w app.config), jak opisano w artykule Microsoftu, do którego link Think Before Coding. To w istocie zmusza wszystkie wątki w aplikacji do wstrzymania podczas zbierania danych, usuwając możliwość dostępu innych wątków do pamięci manipulowanej przez GC. Cieszę się, że moje lata próżnych poszukiwań „błędu” w moim kodzie lub innych niezarządzanych bibliotekach innych firm były bezowocne tylko dlatego, że błąd tkwił w kodzie Microsoftu, a nie w moim.
źródło
Może to być błąd w współbieżnym GC http://support.microsoft.com/kb/2679415
źródło
Wystąpił ten sam dokładny błąd w oknie WinXP z najnowszą kompilacją mojego kodu .NET 4. Sprawdzono poprzednie wersje - teraz też się zawieszają! Ok, więc to nie ja :). Żadne sugestie tutaj / powyżej nie pomogły.
Znacznie nowszy (09.05.2018) raport dotyczący tego samego problemu: Awaria aplikacji z kodem zakończenia 80131506 .
Główna przyczyna jest nadal nieznana (maszyna nie jest aktualizowana i ma niewielkie zastosowanie), ale to zrobiło to dla mnie !
źródło
W moim przypadku ten wyjątek wystąpił, gdy miejsce na dysku się skończyło i .NET nie może przydzielić pamięci w pamięci wirtualnej systemu Windows.
W dzienniku zdarzeń widziałem ten błąd:
Wyskakujące okienko aplikacji: Windows - Za mało pamięci wirtualnej: W systemie brakuje pamięci wirtualnej. System Windows zwiększa rozmiar pliku stronicowania pamięci wirtualnej. Podczas tego procesu żądania pamięci dla niektórych aplikacji mogą zostać odrzucone.
I poprzedni błąd:
Dysk C: osiągnął pełną lub prawie pojemność. Może być konieczne usunięcie niektórych plików.
źródło
W moim przypadku problemem była biblioteka C ++ / CLI, w której było wywołanie NtQuerySystemInformation ; czasami z jakiegoś powodu (i to w tajemniczych okolicznościach ), gdy został wywołany, sterta CLR uległa uszkodzeniu i aplikacja uległa awarii.
Rozwiązałem problem używając "sterty niestandardowej" utworzonej za pomocą HeapCreate i przydzielając tam bufory używane przez tę funkcję.
źródło
Nie jestem pewien, czy może to pomóc wszystkim, ale mógłbym to obejść, biegając
...na ścieżce
{Visual_Studio_root}\Common7\Ide
Miałem następujące błędy w dzienniku zdarzeń, a VS ciągle się zawieszał i restartował:
źródło
W moim przypadku problem był spowodowany zduplikowanymi przekierowaniami powiązań w moim pliku web.config. Więcej informacji tutaj .
Zakładam, że było to spowodowane modyfikacją przez NuGet przekierowań powiązań, ale na przykład wyglądało to tak:
Usunięcie wszystkich duplikatów rozwiązało problem.
źródło
W moim przypadku ten błąd wystąpił podczas logowania do aplikacji SAP Business One 9.1. W zdarzeniach Windows znalazłem również inne zdarzenie błędu oprócz tego zgłoszonego przez OP:
Maszyna działa w systemie Windows 8.1 z zainstalowanym .NET Framework 4.0 i bez wersji 4.5. Ponieważ z internetu wydawało się, że może to być również błąd w .NET 4, próbowałem zainstalować .NET Framework 4.5.2 i rozwiązałem problem.
źródło
Wersja platformy: v4.0.30319 Opis: proces został zakończony z powodu nieobsługiwanego wyjątku. Informacje o wyjątku: System.Reflection.TargetInvocationException
Napotkałem ten błąd, aplikacja działała dobrze na niektórych komputerach i na niektórych komputerach, dając powyższy błąd. Odinstalowałem Framework 4.5 i ponownie zainstalowałem to rozwiązało mój problem.
Dopingować.
źródło
Może to być wyjątek występujący w finalizatorze. Jeśli wykonujesz wzorzec ~ Class () {Dispose (false); } sprawdź, co usuwasz jako niezarządzany zasób. Po prostu spróbuj ... złap tam i powinno być dobrze.
Znaleźliśmy problem, ponieważ mieliśmy tę tajemniczą awarię bez dzienników. Wykonaliśmy zwykły zalecany wzorzec, używając metody „void Dispose (bool disposing)”.
Patrząc na odpowiedzi na to pytanie dotyczące finalizatora, znaleźliśmy możliwe miejsce, w którym Likwidacja niezarządzanych zasobów może zgłosić wyjątek.
Okazuje się, że gdzieś nie umieściliśmy obiektu poprawnie, więc finalizator przejął diposal niezarządzanych zasobów i oto wystąpił wyjątek.
W tym przypadku używano interfejsu API Kafka Rest do czyszczenia klienta z Kafki. Wygląda na to, że w pewnym momencie rzucił wyjątek, a następnie pojawił się ten problem.
źródło
W moim przypadku problem dotyczył „ Odwoływania się do standardowej biblioteki .NET w klasycznych projektach asp.net ” i tych dwóch problemów
https://github.com/dotnet/standard/issues/873
https://github.com/App-vNext/Polly/issues/628
a przejście na wersję Polly v6 wystarczyło, aby to obejść
źródło
Nigdy nie zrozumiałem, dlaczego to się dzieje ze mną. Był powtarzalny dla jednej z moich aplikacji, ale zniknął po prostu po ponownym uruchomieniu.
Używam systemu Windows 2004 Build 19582.1001 (Insider Preview) z .net-4.8 i również nie zdziwiłbym się, gdyby było to spowodowane czymś w rodzaju błędu pamięci sprzętowej. Ponadto moja aplikacja ładuje niezarządzany kod i inicjalizuje go, więc nie mogę udowodnić, że awaria nie pochodzi z tego.
źródło
Co 5-10 minut moja pula aplikacji ulegała awarii z tym kodem zakończenia. Nie chcę zrujnować twojego zaufania Garbage Collectora, ale poniższe rozwiązanie zadziałało.
Dodałem Job, który dzwoni
GC.GetTotalMemory(true)
co minutę.Przypuszczam, że z jakiegoś powodu GC nie sprawdza automatycznie pamięci wystarczająco często pod kątem dużej liczby obiektów jednorazowego użytku, których używam.
źródło