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

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?

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.

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 .

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

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.

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.

Może to być błąd w współbieżnym GC http://support.microsoft.com/kb/2679415

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 !

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.

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

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: 

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.

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.

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

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.

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

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.

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.