O aplicativo trava com “Erro interno no .NET Runtime”


112

Temos um aplicativo escrito em .NET 4.0 que travou no fim de semana, colocando a seguinte mensagem no log de eventos:

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

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

Como diagnosticar um bug no .NET Runtime?


1
Se esta for a primeira vez que esse erro ocorre, eu verificaria qualquer coisa que mudou nos últimos dias a uma semana.
Tony Abrams

Respostas:


121

com código de saída 80131506

Essa é desagradável, ExecutionEngineException. A partir do .NET 4.0, essa exceção encerra imediatamente o programa. A causa genérica é a corrupção do estado do heap da coleta de lixo. O que, por sua vez, é invariavelmente causado por código não gerenciado. A localização exata no código em que essa exceção é gerada 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, os scanners de malware com comportamento inadequado são notórios. Se ele se repetir muito mal, suspeite de problemas de hardware, como erros de RAM de software.


3
Tive problemas com o SQL CE 3.5 corrompendo o heap, causando exceções em erros de tempo de execução ntdll.dll e .NET.
Phil

4
Eles estão listados no arquivo de cabeçalho do SDK CorError.h
Hans Passant

2
Como você sabia que eles estavam listados no CorError.h ??
Yeonho

6
Use esta ferramenta Err.exe microsoft.com/en-au/download/details.aspx?id=985 para descobrir o que significam códigos de erro hexadecimais como 80131506 e qual arquivo de cabeçalho os contém.
Jeremy Thompson

2
@HansPassant Acho que a pergunta que se pretendia era 'de todos os arquivos que existem no mundo, como você sabia que CorError.h era um arquivo que valia a pena olhar'?
bacar

41

Um bug na implementação simultânea da Coleta de Lixo em x64 .Net 4 pode causar isso, conforme indicado na seguinte entrada da KB da Microsoft:

ExecutionEngineException ocorre durante a coleta de lixo

Você deve primeiro fazer uma exploração profunda de minidespejo para ter certeza de que o problema ocorreu durante uma coleta de lixo.

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

A documentação mais recente sobre o uso do <gcConcurrent/>elemento de configuração, para desativar a coleta de lixo simultânea ou (no .NET 4 e posterior) em segundo plano, pode ser encontrada aqui .


obrigado por este comentário - esta foi a solução para um problema que tenho há muito tempo!
lenniep

1
Você é um salva-vidas, esse era o problema para nós. Como um aparte, você também pode abrir o arquivo minidespejo no Visual Studio, configurar os caminhos de símbolo se necessário e, em seguida, depurar. Isso nos disse que o erro ocorre em clr.dll! WKS :: gc_heap :: mark_object_simple (). Tenho certeza de que o WinDbg é muito poderoso, mas usar o VS pode dizer o suficiente se você está apenas verificando a origem do erro.
Tim

O aplicativo travou, mas não encontrei nenhum mini dumps na pasta C: \ Temp \ CrashDump. Existem alguns outros despejos de memória lá, e podemos encontrar os despejos de falhas de dias atrás. Você sabe por que não há despejos de memória? A mensagem de erro e o código de saída são exatamente os mesmos.
Jeffrey Zhao

Isso é exatamente o que eu estava procurando ... o evento de falha do aplicativo continha um ponteiro de instrução, que era inútil para mim sem um dump. Nunca pensei em procurar eventos posteriores. Obrigado!
laindir

1
Para outras pessoas na mesma situação, pode ser útil configurar o Relatório de Erros do Windows para fazer um despejo de heap completo na falha: msdn.microsoft.com/en-us/library/windows/desktop/…
laindir

9

Eu experimentei "erros internos" no tempo de execução do .NET que acabaram sendo causados ​​por bugs em meu código; não pense que só porque foi um "erro interno" no tempo de execução do .NET, não há um bug em seu código como causa raiz. Sempre sempre culpe o seu próprio código antes de culpar o de outra pessoa.

Esperançosamente, você tem informações de registro e exceção / rastreamento de pilha para apontar onde começar a procurar, ou que você pode repetir o estado do sistema antes do travamento.



5

Depois de anos lutando com esse problema em vários aplicativos, parece que a Microsoft finalmente o aceitou 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 ser executado no modo de servidor (gcServer enabled = "true" em app.config), conforme descrito no artigo da Microsoft vinculado a Think Before Coding. Em essência, isso força todos os threads no aplicativo a pausar durante a coleta, removendo a possibilidade de outros threads acessarem a memória que está 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 infrutíferos porque o bug estava no código da Microsoft, não no meu.


1
Qual é o número da versão dos arquivos HotFix que você recebeu? O número da versão listado no KB é 4.0.30319.526, mas eu já tenho 4.0.30319.18052. O HotFix ainda é necessário ou foi incluído no Windows Update?
Automatizar

1
Quando executo o exe HotFix, recebo "KB2640103 não se aplica ou está bloqueado por outra condição em seu computador".
Automatizar


3

Tive exatamente o mesmo erro na caixa WinXP com a última compilação do meu código .NET 4. Verificou as compilações anteriores - agora também travam! Ok então não sou eu :). Nenhuma sugestão aqui / acima ajudou.

Relatório muito mais recente (09/05/2018) do mesmo problema: Falha de aplicativo com código de saída 80131506 .

R : Estávamos recebendo um erro semelhante, mas acreditamos que o nosso foi causado pelo otimizador de memória Citrix.
A resolução era forçar uma regeneração das bibliotecas principais .Net no (s) host (s) onde o problema estava ocorrendo:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force

A causa raiz ainda é desconhecida (a máquina não está sendo atualizada e tem pouco uso), mas isso funcionou para mim !


2

No meu caso, essa exceção ocorreu quando o espaço em disco acabou e o .NET não pode alocar memória na memória virtual do Windows.

No log de eventos, vi este erro:

Pop-up do aplicativo: Windows - Mínimo de memória virtual muito baixo: O sistema está com pouca memória virtual. O Windows está aumentando o tamanho do arquivo de paginação da memória virtual. Durante esse processo, as solicitações de memória para alguns aplicativos podem ser negadas.

E o erro anterior:

O disco C: está no limite ou próximo à capacidade. Pode ser necessário excluir alguns arquivos.


1

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

Resolvi o problema usando um "heap personalizado" criado com HeapCreate e alocando lá os buffers usados ​​por essa função.


1

Não tenho certeza se isso pode ajudar a todos, mas eu poderia contornar isso executando

devenv.exe /ResetSettings 

... no caminho {Visual_Studio_root}\Common7\Ide

Eu tive os seguintes erros no log de eventos e o VS estava 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: 

Isso funcionou para mim também. Contexto: Eu tinha convertido uma solução de tamanho médio (cerca de 25 projetos) para o SDK do .NET Core, liderada por um Projeto de aplicativo da Web quase vazio que substituiu o WAP antigo antes da conversão. Aparentemente, algumas configurações remanescentes conflitavam com as expectativas do IISExpress no novo projeto.
Tomas Aschan de

1

No meu caso, o problema era devido a redirecionamentos de ligação duplicados em meu web.config. Mais informações aqui .

Presumo que tenha sido por causa do NuGet modificando os redirecionamentos de vinculação, mas, por exemplo, era assim:

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

Remover todas as duplicatas resolveu o problema.


0

No meu caso, esse erro ocorreu ao fazer login no aplicativo SAP Business One 9.1. Nos eventos do Windows pude encontrar também outro evento de erro além do relatado 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 roda Windows 8.1, com .NET Framework 4.0 instalado e sem a versão 4.5. Como parecia da internet que também poderia ser um bug no .NET 4, tentei instalar o .NET Framework 4.5.2 e resolvi o problema.


0

Versão da estrutura: v4.0.30319 Descrição: o processo foi encerrado devido a uma exceção não tratada. Informações de exceção: System.Reflection.TargetInvocationException

Eu enfrentei este erro, o aplicativo estava funcionando bem em alguns PCs e em alguns PCs apresentando o erro acima. Desinstalar o Framework 4.5 e reinstalar isso resolveu meu problema.

Viva


0

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

Encontramos o problema porque tínhamos uma falha misteriosa sem registros. Fizemos o padrão recomendado de usar um "void Dispose (bool disposing)".

Olhando para as respostas a esta pergunta sobre o finalizador, encontramos um possível lugar onde o Descarte de recursos não gerenciados poderia lançar uma exceção.

Acontece que em algum lugar não descartamos o objeto corretamente, portanto, o finalizador assumiu a disposição dos recursos não gerenciados, portanto, eis que ocorreu uma exceção.

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



0

Eu nunca descobri por que isso estava acontecendo comigo. Era reproduzível de forma consistente para um de meus aplicativos, mas desapareceu após a simples reinicialização.

Estou executando o Windows 2004 Build 19582.1001 (Insider Preview) com .net-4.8 e também não ficaria surpreso se isso fosse devido a algo como um erro de memória de hardware. Além disso, meu aplicativo carrega algum código não gerenciado e o inicializa, então não posso provar que a falha não veio disso.


-1

A cada 5-10 minutos, meu pool de aplicativos travava com esse código de saída. Não quero arruinar sua confiança no Coletor de Lixo, 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 memória com a frequência suficiente para o grande número de objetos descartáveis ​​que uso.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.