A aplicação trava com “erro interno no tempo de execução do .NET”

Temos um aplicativo escrito no .NET 4.0, que durante o final de semana falhou, colocando a seguinte mensagem no log de events:

Aplicação: PnrRetrieverService.exe Versão do Framework: v4.0.30319
Descrição: O processo foi finalizado devido a um erro interno no .NET Runtime no IP 791F9AAA (79140000) com o código de saída 80131506.

Isso está em uma checkbox do Windows Server 2003 R2 Standard Edition. Pesquisando este erro não apareceu nada pertinente. Por exemplo, isso não está ocorrendo no VS Studio, mas sim em uma checkbox de produção; quando o serviço foi eventualmente reiniciado, não houve mais problemas.

Como se faz para diagnosticar um bug no .NET Runtime?

com o código de saída 80131506

Isso é um desagradável, ExecutionEngineException. A partir do .NET 4.0, esta exceção encerra imediatamente o programa. A causa genérica é a corrupção do estado do heap do lixo coletado. Que por sua vez é invariavelmente causado por código não gerenciado. A localização exata no código em que esta exceção é levantada não é útil, a corrupção geralmente ocorreu bem antes de o dano ser detectado.

Encontrar a causa exata para isso vai ser difícil. Revise qualquer código não gerenciado que seu serviço possa estar usando. Suspeite de problemas ambientais, se não houver um candidato óbvio, mal-intencionado mal-intencionado scanners de malware são notórios. Se ele repetir muito mal, suspeite de problemas de hardware como erros de RAM.

Um bug na implementação simultânea da garbage collection no x64 .net 4 pode causar isso, conforme indicado na seguinte input do Microsoft microsoft:

ExecutionEngineException ocorre durante a garbage collection

Você deve primeiro fazer uma profunda exploração minidump para ter certeza de que o problema ocorreu durante uma garbage collection.

O local do minidump geralmente pode ser encontrado em uma input do Relatório de Erros do Windows no log de events após a input de falha. Então, divirta-se com o WinDbg!

A documentação mais recente sobre o uso do elemento de configuração , para desativar a garbage collection simultânea ou (no .NET 4 e posterior), pode ser encontrada aqui .

Eu experimentei “erros internos” no tempo de execução do .NET que acabaram sendo causados ​​por erros no meu código; Não pense que só porque foi um “erro interno” no tempo de execução do .NET que não há um bug no seu código como causa raiz. Sempre sempre culpe seu próprio código antes de culpar alguém.

Espero que você tenha informações de log e rastreamento de exceção / pilha para apontar onde começar a procurar ou que você possa repetir o estado do sistema antes da falha.

Para aqueles que chegam aqui do google, eu finalmente me deparei com essa pergunta , e essa resposta específica resolveu o meu problema. Eu entrei em contato com a Microsoft para o hotfix através do chat ao vivo em support.microsoft.com e eles me enviaram um link para o hotfix por e-mail.

Poderia ser um bug com o GC concorrente http://support.microsoft.com/kb/2679415

Após anos lutando com esse problema em vários aplicativos, parece que a Microsoft finalmente aceitou isso como um bug no .NET 4 CLR que faz com que isso ocorra. http://support.microsoft.com/kb/2640103 .

Eu já havia “consertado” isso forçando o coletor de lixo a executar no modo de servidor (gcServer enabled = “true” no app.config), conforme descrito no artigo da Microsoft vinculado ao Think Before Coding. Isso basicamente força todos os threads no aplicativo a pausar durante a coleta, removendo a possibilidade de outros threads acessarem a memory sendo manipulada pelo GC. Fico feliz em descobrir que meus anos de busca em vão por um “bug” no meu código ou em outras bibliotecas não gerenciadas de terceiros foram apenas infrutíferas porque o bug estava no código da Microsoft, não no meu.

No meu caso, esta exceção ocorreu quando o espaço em disco acabou e o .NET não pode alocar memory na Memória Virtual do Windows.

No log de events, vi esse erro:

Pop-up da aplicação: Windows – Memória Mínima Mínima: O seu sistema está com pouca memory virtual. O Windows está aumentando o tamanho do seu arquivo de paginação de memory virtual. Durante esse processo, solicitações de memory para alguns aplicativos podem ser negadas.

E erro anterior:

O disco C: está na capacidade ou perto dela. Você pode precisar excluir alguns arquivos.

Versão do Framework: v4.0.30319 Descrição: O processo foi finalizado devido a uma exceção não tratada. Informação de excepção: System.Reflection.TargetInvocationException

Eu enfrentei este erro, o aplicativo estava funcionando bem em alguns PCs e em alguns PCs dando o erro acima. Eu desinstalo o Framework 4.5 e re-instalar isso resolveu o meu problema.

Elogio

Eu não tenho certeza se isso pode ajudar a todos, mas eu poderia contornar isso correndo

 devenv.exe /ResetSettings 

… no caminho {Visual_Studio_root}\Common7\Ide

Eu tive os seguintes erros no log de events e o VS estava apenas travando e reiniciando o tempo todo:

 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: 

No meu caso, o problema era uma biblioteca C ++ / CLI na qual havia uma chamada para o NtQuerySystemInformation ; por algum motivo, às vezes (e em circunstâncias misteriosas ), quando foi chamado o heap CLR foi corrompido e o aplicativo falhou.

Resolvi o problema usando um “heap personalizado” criado com o HeapCreate e alocando os buffers usados ​​por essa function.

No meu caso, esse erro ocorreu ao efetuar login no aplicativo SAP Business One 9.1. Em events do Windows, também encontrei outro evento de erro além do reportado pelo 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: 

A máquina executa o Windows 8.1, com o .NET Framework 4.0 instalado e sem a versão 4.5. Como parecia da internet que poderia ser também um bug no .NET 4, tentei instalar o .NET Framework 4.5.2 e resolvi o problema.

Isso pode ser uma exceção ocorrendo no finalizador. Se você estiver fazendo o padrão de ~ Class () {Dispose (false); } verifique o que você está descartando como um recurso não gerenciado. Basta colocar uma tentativa..catch lá e você deve estar bem.

Nós encontramos o problema como nós tivemos esta falha misteriosa sem registros Nós fizemos o padrão usual recomendado de usar um “vazio Dispose (bool disposição)”.

Observando as respostas sobre essa questão sobre o finalizador, encontramos um possível local onde o descarte dos resources não gerenciados poderia gerar uma exceção.

Acontece que em algum lugar nós não dispomos o object adequadamente, assim, o finalizador assumiu a falha de resources não gerenciados, portanto, observe uma exceção ocorrida.

Neste caso, estava usando a API Kafka Rest para limpar o cliente do Kafka. Parece que fez exceção em algum momento, em seguida, este problema ocorreu.

A cada 5-10 minutos, meu pool de aplicativos ficava bloqueando esse código de saída. Eu não quero estragar sua confiança do Garbage Collector, mas a solução a seguir funcionou para mim.

Eu adicionei um trabalho que chama GC.GetTotalMemory(true) cada minuto.

Suponho que, por algum motivo, o GC não esteja inspecionando automaticamente a memory com freqüência suficiente para o grande número de objects descartáveis ​​que eu uso.