Aplikacja ulega awarii i pojawia się „Błąd wewnętrzny w środowisku wykonawczym .NET”

112

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?

ALEXintlsos
źródło
1
Jeśli jest to pierwszy raz, kiedy ten błąd się zdarzył, przyjrzałbym się wszystkim, co zmieniło się w ciągu ostatnich kilku dni do tygodnia.
Tony Abrams

Odpowiedzi:

121

z kodem wyjścia 80131506

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.

Hans Passant
źródło
3
Miałem problemy z uszkodzeniem sterty przez SQL CE 3.5 , powodując wyjątki w błędach ntdll.dll i .NET.
Phil
4
Są one wymienione w pliku nagłówkowym SDK CorError.h
Hans Passant
2
Skąd wiedziałeś, że zostały wymienione w CorError.h?
Yeonho
6
Użyj tego narzędzia Err.exe microsoft.com/en-au/download/details.aspx?id=985, aby dowiedzieć się, jakie kody błędów szesnastkowych, takie jak 80131506, oznaczają i który plik nagłówkowy je zawiera.
Jeremy Thompson,
2
@HansPassant Myślę, że chodziło o „ze wszystkich plików, które istnieją na świecie, skąd wiedziałeś, że CorError.h był wartym uwagi plikiem do obejrzenia”?
Bacar
41

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 .

thinkbeforecoding
źródło
dziękuję za komentarz - to było rozwiązanie problemu, który miałem przez długi czas!
lenniep
1
Ratujesz życie, to był problem dla nas. Na marginesie możesz również otworzyć plik minizrzutu w programie Visual Studio, skonfigurować ścieżki symboli, jeśli to konieczne, a następnie debugować. To mówi nam, że błąd występuje w pliku clr.dll! WKS :: gc_heap :: mark_object_simple (). Jestem pewien, że WinDbg jest bardzo potężny, ale użycie VS może ci powiedzieć wystarczająco dużo, jeśli tylko weryfikujesz źródło błędu.
Tim
Aplikacja uległa awarii, ale nie znalazłem żadnych mini zrzutów w folderze C: \ Temp \ CrashDump. Są tam inne zrzuty awaryjne i możemy znaleźć zrzuty z katastrof sprzed kilku dni. Czy wiesz, dlaczego nie ma zrzutów awaryjnych? Komunikat o błędzie i kod zakończenia są dokładnie takie same.
Jeffrey Zhao
Właśnie tego szukałem ... zdarzenie awarii aplikacji zawierało wskaźnik instrukcji, który był dla mnie bezużyteczny bez zrzutu. Nigdy nie myślałem, żeby szukać późniejszych wydarzeń. Dziękuję Ci!
laindir
1
Dla innych w tej samej sytuacji przydatne może być skonfigurowanie Raportowania błędów systemu Windows w celu wykonania pełnego zrzutu sterty w przypadku awarii: msdn.microsoft.com/en-us/library/windows/desktop/ ...
laindir
9

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

Jason
źródło
7

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.

johnildergleidisson
źródło
5

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.

park896
źródło
1
Jaki jest numer wersji otrzymanych plików HotFix? Numer wersji podany w KB to 4.0.30319.526, ale mam już 4.0.30319.18052. Czy poprawka jest nadal potrzebna, czy też została wprowadzona do witryny Windows Update?
Automatyzacja
1
Kiedy uruchamiam plik HotFix exe, otrzymuję komunikat „KB2640103 nie ma zastosowania lub jest blokowany przez inny stan komputera”.
Automatyzacja
3

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 .

Odp . : Otrzymaliśmy podobny błąd, ale uważamy, że nasz był spowodowany przez optymalizator pamięci Citrix.
Rozwiązanie polegało na wymuszeniu regeneracji bibliotek .Net core na hoście (ach), na których występuje problem:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force

Główna przyczyna jest nadal nieznana (maszyna nie jest aktualizowana i ma niewielkie zastosowanie), ale to zrobiło to dla mnie !

Astrogator
źródło
2

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.

Arthur Smirnov
źródło
1

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

SiMoStro
źródło
1

Nie jestem pewien, czy może to pomóc wszystkim, ale mógłbym to obejść, biegając

devenv.exe /ResetSettings 

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

Faulting application name: devenv.exe, version: 14.0.25123.0, time stamp: 0x56f22f32
Faulting module name: clr.dll, version: 4.7.2115.0, time stamp: 0x59af88f2
Exception code: 0xc0000005
Fault offset: 0x0015f90e
Faulting process id: 0x3a7c
Faulting application start time: 0x01d353463eaf0c36
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: a232f984-6e80-4f61-9003-e18a035c8f93
Faulting package full name: 
Faulting package-relative application ID: 
Ritesh Varyani
źródło
Dla mnie to też zadziałało. Kontekst: Przekonwertowałem rozwiązanie średniej wielkości (~ 25 projektów) na zestaw .NET Core SDK z prawie pustym projektem aplikacji sieci Web, który zastąpił stary WAP przed konwersją. Najwyraźniej niektóre utrzymujące się ustawienia kolidowały z oczekiwaniami IISExpress w nowym projekcie.
Tomas Aschan
1

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:

  <dependentAssembly>
    <assemblyIdentity name="Lucene.Net" publicKeyToken="85089178b9ac3181"/>
    <bindingRedirect oldVersion="0.0.0.0-2.9.4.0" newVersion="3.0.3.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed"/>
    <bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Lucene.Net" publicKeyToken="85089178b9ac3181"/>
    <bindingRedirect oldVersion="0.0.0.0-2.9.4.0" newVersion="3.0.3.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed"/>
    <bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0"/>
  </dependentAssembly>

Usunięcie wszystkich duplikatów rozwiązało problem.

Mark Gibbons
źródło
0

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:

Nome dell'applicazione che ha generato l'errore: SAP Business One.exe, versione: 9.10.160.0, timestamp: 0x551ad316
Nome del modulo che ha generato l'errore: clr.dll, versione: 4.0.30319.34014, timestamp: 0x52e0b784
Codice eccezione: 0xc0000005
Offset errore 0x00029f55
ID processo che ha generato l'errore: 0x1d7c
Ora di avvio dell'applicazione che ha generato l'errore: 0x01d0e6f4fa626e78
Percorso dell'applicazione che ha generato l'errore: C:\Program Files (x86)\SAP\SAP Business One\SAP Business One.exe
Percorso del modulo che ha generato l'errore: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
ID segnalazione: 3fd8e0e7-52e8-11e5-827f-74d435a9d02c
Nome completo pacchetto che ha generato l'errore: 
ID applicazione relativo al pacchetto che ha generato l'errore: 

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.

niebieskawy
źródło
0

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

user4815065
źródło
0

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.

Nelson J Perez
źródło
0

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.

binki
źródło
-1

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.

Éric Bergeron
źródło