アプリケーションが「.NETランタイムの内部エラー」でクラッシュする

.NET 4.0に対して作成されたアプリケーションがあり、週末にクラッシュし、次のメッセージがイベントログに記録されました。

アプリケーション：PnrRetrieverService.exe Frameworkバージョン：v4.0.30319
説明：終了コード80131506のIP 791F9AAA（79140000）での.NETランタイムの内部エラーのため、プロセスが終了しました。

これは、Windows Server 2003 R2 Standard Editionボックスにあります。このエラーをグーグルしても、関連することは何もありません。たとえば、これはVS Studioでは発生せず、プロダクションボックスで発生します。サービスが最終的に再起動されたとき、それ以上の問題は発生しませんでした。

.NETランタイムのバグを診断するにはどうすればよいですか？

終了コード80131506

厄介なのは、ExecutionEngineExceptionです。.NET 4.0以降、この例外はプログラムを即座に終了させます。一般的な原因は、ガベージコレクションされたヒープの状態の破損です。これは、常にアンマネージコードによって引き起こされます。この例外が発生するコード内の正確な場所は役に立ちません。通常、破損が検出される前に破損が発生しました。

これの正確な原因を見つけるのは難しいでしょう。サービスが使用している可能性のあるアンマネージコードを確認します。明らかな候補がない場合は、環境問題の疑いがあります。不正な動作をするマルウェアスキャナーは悪名高いです。繰り返しが非常に少ない場合は、ソフトRAMエラーなどのハードウェアの問題を疑います。

x64 .Net 4でのガベージコレクションの同時実装のバグは、次のMicrosoft KBエントリに記載されているようにこれを引き起こす可能性があります。

ガベージコレクション中にExecutionEngineExceptionが発生する

最初に詳細なミニダンプ調査を行って、ガベージコレクション中に問題が発生したことを確認する必要があります。

ミニダンプの場所は通常、クラッシュエントリに続くイベントログのWindowsエラー報告エントリにあります。次に、WinDbgをお楽しみください。

<gcConcurrent/>同時または（.NET 4以降では）バックグラウンドガベージコレクションを無効にするための構成要素の使用に関する最新のドキュメントは、こちらにあります。

コードのバグが原因であることが判明した.NETランタイムで「内部エラー」が発生しました。根本的な原因としてコードにバグがないのは、それが.NETランタイムの「内部エラー」であったという理由だけではありません。他の人のせいにする前に、常に自分のコードのせいにしなさい。

うまくいけば、ロギングと例外/スタックトレース情報があり、どこから探し始めるか、またはクラッシュ前のシステムの状態を繰り返すことができます。

グーグルからここに到着した人のために、私は最終的にこのSOの質問に出くわしました、そしてこの特定の答えは私の問題を解決しました。support.microsoft.comのライブチャットを通じて修正プログラムについてマイクロソフトに連絡しましたが、修正プログラムへのリンクが電子メールで送られてきました。

何年にもわたって多くのアプリケーションでこの問題に取り組んできましたが、Microsoftは.NET 4 CLRのバグとして、これを引き起こすバグとしてようやく受け入れたようです。http://support.microsoft.com/kb/2640103。

Think Before CodingがリンクしているMicrosoftの記事で説明されているように、以前はガベージコレクターをサーバーモード（app.configのgcServer enabled = "true"）で実行するように強制して「修正」していた。これは本質的に、アプリケーションのすべてのスレッドを強制的に収集中に一時停止させ、他のスレッドがGCによって操作されているメモリにアクセスする可能性を排除します。私のコードではなく、Microsoftのコードにバグが存在していたため、コードや他のサードパーティのアンマネージライブラリの「バグ」を探すのに何年も無駄になっていたことをうれしく思います。

同時GCのバグである可能性があります http://support.microsoft.com/kb/2679415

私の.NET 4コードの最新ビルドで、WinXPボックスでまったく同じエラーが発生しました。以前のビルドを確認しました-今度はクラッシュします！わかりましたので、私ではありません :) ここ/上記の提案は役に立ちませんでした。

同じ問題に関するより最近の（2018-05-09）レポート：終了コード80131506によるアプリケーションクラッシュ。

A：同様のエラーが発生しましたが、Citrixメモリーオプティマイザーが原因であると考えられます。
解決策は、問題が発生していたホストで.Netコアライブラリを強制的に再生成することでした。
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force

根本的な原因はまだ不明です（マシンは更新されておらず、ほとんど使用されていません）が、私にはそれが実現しました！

私の場合、この例外はディスク領域がいっぱいになり、.NETがWindows仮想メモリにメモリを割り当てることができないときに発生しました。

イベントログに次のエラーが表示されました。

アプリケーションポップアップ：Windows-Virtual Memory Minimum Too Low：システムの仮想メモリが不足しています。Windowsは仮想メモリページングファイルのサイズを増やしています。このプロセス中に、一部のアプリケーションのメモリ要求が拒否される場合があります。

そして以前のエラー：

C：ディスクの容量が限界に近づいている。一部のファイルを削除する必要がある場合があります。

私の場合、問題はNtQuerySystemInformationへの呼び出しがあったC ++ / CLIライブラリでした。ある種の理由で（そして不思議な状況下で）、CLRヒープが呼び出されたときに破損し、アプリケーションがクラッシュしました。

HeapCreateで作成された「カスタムヒープ」を使用して、その関数で使用されるバッファーを割り当てる問題を解決しました。

それがみんなを助けるかもしれないとは思いませんが、実行することでこれを回避できました

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: 

私の場合、問題は私の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>

すべての重複を削除すると問題が解決しました。

私の場合、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: 

マシンはWindows 8.1を実行し、.NET Framework 4.0がインストールされ、4.5バージョンはインストールされていません。インターネットからは.NET 4のバグである可能性もあると思われたので、.NET Framework 4.5.2をインストールしてみて問題を解決しました。

フレームワークバージョン：v4.0.30319説明：未処理の例外が原因でプロセスが終了しました。例外情報：System.Reflection.TargetInvocationException

このエラーに直面しました。一部のPCおよび一部のPCでアプリケーションが正常に動作し、上記のエラーが発生しました。Framework 4.5をアンインストールし、再インストールして問題を解決しました。

乾杯。

これは、ファイナライザで発生する例外である可能性があります。〜Class（）{Dispose（false）;のパターンを実行している場合 非管理対象リソースとして何を破棄するかを確認します。そこにtry..catchを置くだけで大丈夫です。

ログがないという不可解なエラーが発生したため、問題が見つかりました。「void Dispose（bool disposing）」を使用するという通常の推奨パターンを実行しました。

ファイナライザに関するこの質問の回答を見てみると、アンマネージリソースの破棄が例外をスローする可能性のある場所が見つかりました。

オブジェクトが適切に破棄されなかったことが判明したため、ファイナライザがアンマネージリソースの処理を引き継いだため、例外が発生しました。

この場合、Kafka Rest APIを使用して、Kafkaからクライアントをクリーンアップしました。ある時点で例外が発生したようで、この問題が発生しました。

私の場合、問題は「クラシックasp.netプロジェクトでの.NET標準ライブラリの参照」とこれら2つの問題に関連していた

https://github.com/dotnet/standard/issues/873

https://github.com/App-vNext/Polly/issues/628

Polly v6にダウングレードするだけで回避できました

なぜこれが私のために起こったのか、私には決してわかりませんでした。それは私のアプリケーションの1つで一貫して再現可能でしたが、単に再起動しただけでなくなりました。

私はWindows 2004ビルド19582.1001（Insider Preview）を.net-4.8で実行していますが、これがハードウェアメモリエラーのようなものであったとしても、驚くことはありません。また、私のアプリケーションはアンマネージコードをいくつかロードして初期化するため、クラッシュがその原因ではないことを証明できません。

アプリケーションプールが5〜10分ごとにこの終了コードでクラッシュし続けました。ガベージコレクターの信頼を台無しにしたくはありませんが、次の解決策がうまくいきました。

呼び出すジョブを追加しました GC.GetTotalMemory(true)毎分。

何らかの理由で、私が使用する多数の使い捨てオブジェクトに対して、GCがメモリを自動的に頻繁に検査していないと思います。