".NET 런타임의 내부 오류"와 함께 응용 프로그램 충돌


112

주말 동안 충돌 한 .NET 4.0에 대해 작성된 응용 프로그램이 있으며 이벤트 로그에 다음 메시지를 기록합니다.

응용 프로그램 : PnrRetrieverService.exe Framework 버전 : v4.0.30319
설명 : 종료 코드 80131506과 함께 IP 791F9AAA (79140000)에서 .NET 런타임의 내부 오류로 인해 프로세스가 종료되었습니다.

이것은 Windows Server 2003 R2 Standard Edition 상자에 있습니다. 이 오류를 검색해도 관련성이없는 것으로 나타났습니다. 예를 들어, 이것은 VS Studio에서 발생하는 것이 아니라 프로덕션 상자에서 발생합니다. 서비스가 결국 다시 시작되었을 때 더 이상 문제가 발생하지 않았습니다.

.NET 런타임에서 버그를 진단하는 방법은 무엇입니까?


1
이 오류가 처음 발생한 경우 지난 며칠에서 일주일 동안 변경된 사항을 조사합니다.
Tony Abrams

답변:


121

종료 코드 80131506 포함

그것은 불쾌한 ExecutionEngineException입니다. .NET 4.0부터이 예외는 즉시 프로그램을 종료합니다. 일반적인 원인은 가비지 수집 힙 상태의 손상입니다. 이는 결국 비 관리 코드로 인해 발생합니다. 이 예외가 발생한 코드의 정확한 위치는 도움이되지 않습니다. 일반적으로 손상이 감지되기 ​​훨씬 전에 손상이 발생했습니다.

이에 대한 정확한 원인을 찾는 것은 어려울 것입니다. 서비스에서 사용할 수있는 비 관리 코드를 검토합니다. 명백한 후보가없는 경우 환경 문제를 의심하고 오작동하는 맬웨어 스캐너는 악명이 높습니다. 매우 느리게 반복되면 소프트 RAM 오류와 같은 하드웨어 문제를 의심합니다.


3
SQL CE 3.5로 인해 힙이 손상되어 ntdll.dll 및 .NET 런타임 오류에서 예외 가 발생하는 문제가 발생했습니다.
Phil

4
그들은 SDK 헤더 파일 CorError.h에 나열되어 있습니다
한스 옆모습을

2
CorError.h에 나열된 것을 어떻게 알았습니까 ??
연호

6
이 Err.exe 도구 microsoft.com/en-au/download/details.aspx?id=985 를 사용하여 80131506과 같은 16 진 오류 코드가 의미하는 것과이를 포함하는 헤더 파일을 확인하십시오.
Jeremy Thompson

2
@HansPassant 내가 의도 한 질문은 '세계에 존재하는 모든 파일 중 CorError.h가 볼만한 가치가있는 파일이라는 것을 어떻게 알았습니까?'라고 생각합니다.
bacar 2017-10-17

41

x64 .Net 4 에서 가비지 수집을 동시에 구현할 때 발생하는 버그로 인해 다음 microsoft KB 항목에 설명 된대로이 문제가 발생할 수 있습니다.

가비지 수집 중에 ExecutionEngineException 발생

먼저 가비지 수집 중에 문제가 발생했는지 확인하기 위해 미니 덤프를 자세히 살펴 봐야합니다.

미니 덤프 위치는 일반적으로 충돌 항목 다음에 나오는 이벤트 로그의 Windows 오류보고 항목에서 찾을 수 있습니다. 그런 다음 WinDbg로 재미있게 보내십시오!

<gcConcurrent/>동시 또는 (.NET 4 이상에서) 백그라운드 가비지 수집을 비활성화하기 위한 구성 요소 사용에 대한 최신 설명서는 여기 에서 찾을 수 있습니다 .


이 의견에 감사드립니다-이것은 제가 오랫동안 가지고 있었던 문제에 대한 해결책이었습니다!
lenniep 2013 년

1
당신은 생명의 은인이고 이것이 우리의 문제였습니다. 그 외에도 Visual Studio에서 미니 덤프 파일을 열고 필요한 경우 기호 경로를 설정 한 다음 디버그 할 수도 있습니다. 이것은 clr.dll! WKS :: gc_heap :: mark_object_simple ()에서 오류가 발생했음을 알려줍니다. WinDbg가 매우 강력하다고 확신하지만 VS를 사용하면 오류의 원인을 확인하는 것만으로도 충분히 알 수 있습니다.
Tim

응용 프로그램이 충돌했지만 C : \ Temp \ CrashDump 폴더에서 미니 덤프를 찾지 못했습니다. 거기에 다른 크래시 덤프가 있으며 며칠 전 크래시 덤프를 찾을 수 있습니다. 크래시 덤프가없는 이유를 아십니까? 오류 메시지와 종료 코드는 정확히 동일합니다.
제프리 조

이것이 바로 제가 찾던 것입니다. 앱 충돌 이벤트에는 덤프 없이는 쓸모가없는 명령 포인터가 포함되어 있습니다. 이후의 이벤트를 찾을 생각은 없었습니다. 감사합니다!
laindir

1
같은 상황에있는 다른 사람들의 경우 충돌시 전체 힙 덤프를 수행하도록 Windows 오류보고를 구성하는 것이 유용 할 수 있습니다. msdn.microsoft.com/en-us/library/windows/desktop/…
laindir

9

.NET 런타임에서 내 코드의 버그로 인해 발생한 "내부 오류"를 경험했습니다. .NET 런타임의 "내부 오류"라고해서 코드에 버그가 근본 원인이 아니라고 생각하지 마십시오. 항상 다른 사람을 비난하기 전에 항상 자신의 코드를 비난하십시오.

바라건대 로깅 및 예외 / 스택 추적 정보가있어 검색을 시작할 위치를 알려주거나 충돌 전에 시스템 상태를 반복 할 수 있습니다.



5

여러 응용 프로그램에서이 문제와 수년간 씨름 한 끝에 Microsoft는 마침내이 문제를 발생시키는 .NET 4 CLR의 버그로 받아 들인 것으로 보입니다. http://support.microsoft.com/kb/2640103 .

이전에는 Think Before Coding에 링크 된 Microsoft 문서에 설명 된대로 가비지 수집기가 서버 모드 (app.config의 gcServer enabled = "true")에서 실행되도록 강제하여 "수정"했습니다. 이것은 본질적으로 애플리케이션의 모든 스레드가 GC에 의해 조작되는 메모리에 액세스하는 다른 스레드의 가능성을 제거하는 동안 수집 중에 일시 중지되도록합니다. 내 코드 나 다른 타사 관리되지 않는 라이브러리에서 "버그"를 헛되이 검색했던 수년 동안 버그가 내 것이 아니라 Microsoft 코드에 있었기 때문에 성과가 없었다는 사실을 알게되어 기쁩니다.


1
받은 HotFix 파일의 버전 번호는 무엇입니까? KB에 나열된 버전 번호는 4.0.30319.526이지만 이미 4.0.30319.18052가 있습니다. HotFix가 여전히 필요합니까 아니면 Windows 업데이트에 포함 되었습니까?
2013 년

1
HotFix exe를 실행하면 "KB2640103이 적용되지 않거나 컴퓨터의 다른 조건에 의해 차단되었습니다."라는 메시지가 나타납니다.
2013 년


3

내 .NET 4 코드의 최신 빌드를 사용하여 WinXP 상자에서 동일한 오류가 발생했습니다. 이전 빌드를 확인했습니다-이제 충돌도 발생합니다! 좋아, 그래서 내가 아니야 :). 여기 / 위의 제안이 도움이되지 않았습니다.

동일한 문제에 대한 훨씬 더 최근 (2018-05-09) 보고서 : 종료 코드 80131506이있는 애플리케이션 충돌 .

A : 비슷한 오류가 발생했지만 Citrix 메모리 최적화 프로그램이 원인이라고 생각합니다.
해결 방법은 문제가 발생한 호스트에서 .Net 코어 라이브러리를 강제로 재생성하는 것이 었습니다.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force

근본 원인은 아직 알려지지 않았지만 (시스템이 업데이트되지 않고 거의 사용되지 않음) 저를 위해 해냈습니다 !


2

필자의 경우이 예외는 디스크 공간이 끝나고 .NET이 Windows 가상 메모리에 메모리를 할당 할 수 없을 때 발생했습니다.

이벤트 로그에서이 오류를 보았습니다.

응용 프로그램 팝업 : Windows-가상 메모리 최소 너무 낮음 : 시스템에 가상 메모리가 부족합니다. Windows에서 가상 메모리 페이징 파일의 크기를 늘리고 있습니다. 이 과정에서 일부 응용 프로그램에 대한 메모리 요청이 거부 될 수 있습니다.

그리고 이전 오류 :

C : 디스크의 용량이 거의 다되었습니다. 일부 파일을 삭제해야 할 수 있습니다.


1

제 경우 문제는 NtQuerySystemInformation 에 대한 호출이있는 C ++ / CLI 라이브러리였습니다 . 어떤 종류의 이유로 때때로 (그리고 신비한 상황에서 ) CLR 힙이 손상되고 응용 프로그램이 충돌했습니다.

HeapCreate로 만든 "사용자 지정 힙"을 사용하고 해당 함수에서 사용하는 버퍼를 할당 하여 문제를 해결했습니다 .


1

모든 사람에게 도움이 될지 모르겠지만 실행하면이 문제를 해결할 수 있습니다.

devenv.exe /ResetSettings 

... 경로에서 {Visual_Studio_root}\Common7\Ide

이벤트 로그에 다음 오류가 있었고 VS가 항상 충돌하고 다시 시작되었습니다.

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: 

이것은 나에게도 효과적이었습니다. 컨텍스트 : 중간 크기의 솔루션 (~ 25 개 프로젝트)을 .NET Core SDK로 변환했으며, 변환 전에 이전 WAP를 대체하는 거의 비어있는 웹 애플리케이션 프로젝트가 앞에있었습니다. 분명히 일부 느린 설정은 새 프로젝트에서 IISExpress의 기대와 충돌했습니다.
Tomas Aschan

1

제 경우에는 web.config의 중복 바인딩 리디렉션으로 인해 문제가 발생했습니다. 여기에 더 많은 정보가 있습니다 .

NuGet이 바인딩 리디렉션을 수정했기 때문이라고 가정하지만 예를 들어 다음과 같이 보입니다.

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

모든 중복을 제거하면 문제가 해결되었습니다.


0

제 경우에는 SAP Business One 9.1 애플리케이션에 로그인 할 때이 오류가 발생했습니다. Windows 이벤트에서 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: 

이 컴퓨터는 .NET Framework 4.0이 설치되어 있고 4.5 버전없이 Windows 8.1을 실행합니다. 인터넷에서 .NET 4에서도 버그가 될 수있는 것처럼 보였기 때문에 .NET Framework 4.5.2를 설치해 보았고 문제를 해결했습니다.


0

프레임 워크 버전 : v4.0.30319 설명 : 처리되지 않은 예외로 인해 프로세스가 종료되었습니다. 예외 정보 : System.Reflection.TargetInvocationException

이 오류에 직면했습니다. 일부 PC에서는 응용 프로그램이 제대로 작동하고 일부 PC에서는 위의 오류가 발생했습니다. Framework 4.5를 제거하고 다시 설치하여 문제가 해결되었습니다.

격려.


0

종료 자에서 발생하는 예외 일 수 있습니다. ~ Class () {Dispose (false); 패턴을 수행하는 경우 } 관리되지 않는 리소스로 처리하는 항목을 확인합니다. 그냥 시도 해봐 .. 거기 잡으면 괜찮을거야.

로그가없는 신비한 오류가 발생하여 문제를 발견했습니다. "void Dispose (bool disposing)"를 사용하는 일반적인 권장 패턴을 사용했습니다.

종료 자에 대한이 질문에 대한 답변을 살펴보면 관리되지 않는 리소스의 폐기가 예외를 throw 할 수있는 가능한 위치를 찾았습니다.

어딘가에서 객체를 적절하게 처리하지 않았으므로 종료자가 관리되지 않는 리소스의 폐기를 인수하여 예외가 발생했습니다.

이 경우 Kafka Rest API를 사용하여 Kafka에서 클라이언트를 정리했습니다. 이 문제가 발생했을 때 어느 시점에서 예외가 발생한 것 같습니다.



0

왜 이런 일이 일어나고 있는지 전혀 알지 못했습니다. 내 응용 프로그램 중 하나에서 일관되게 재현 가능했지만 단순히 재부팅하면 사라졌습니다.

.net-4.8로 Windows 2004 Build 19582.1001 (Insider Preview)을 실행 중이며 이것이 하드웨어 메모리 오류와 같은 이유로 인한 것인지도 놀라지 않을 것입니다. 또한 내 응용 프로그램은 일부 관리되지 않는 코드를로드하고 초기화하므로 충돌이 그 원인이 아님을 증명할 수 없습니다.


-1

5-10 분마다 내 응용 프로그램 풀이이 종료 코드와 함께 계속 충돌했습니다. Garbage Collector에 대한 귀하의 신뢰를 망치고 싶지는 않지만 다음 솔루션이 저에게 효과적이었습니다.

GC.GetTotalMemory(true)매분 호출하는 작업을 추가했습니다 .

어떤 이유로 GC가 내가 사용하는 많은 수의 일회용 개체에 대해 충분히 자주 메모리를 자동으로 검사하지 않는다고 생각합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.