25

計算コストの高いマルチスレッドC＃アプリがあり、30〜90分の実行後に一貫してクラッシュするようです。それが与えるエラーは

ランタイムで致命的なエラーが発生しました。エラーのアドレスは、スレッド0xbccの0xec37ebaeにありました。エラーコードは0xc0000005です。このエラーは、CLRのバグ、またはユーザーコードの安全でない部分または検証できない部分のバグである可能性があります。このバグの一般的な原因には、COM-interopまたはPInvokeのユーザーマーシャリングエラーがあり、スタックが破損する可能性があります。

（0xc0000005はアクセス違反のエラーコードです）

私のアプリは、ネイティブコードを呼び出したり、安全でないブロックを使用したり、CLSに準拠していないタイプのようなものを使用したりしませんuint。実際、デバッガーがクラッシュを引き起こしたと言っているコード行は

overallLength += distanceTravelled;

両方の値がタイプの場合double

これらすべてを考慮すると、クラッシュはコンパイラ、CLR、またはJITのバグが原因であるに違いないと思います。何が原因なのかを解明したいのですが、少なくともMicrosoftに送信するための小さな複製を作成したいのですが、どこから始めればよいのかさえわかりません。CILバイナリ、コンパイルされたJIT出力、またはネイティブスタックトレース（クラッシュ時に管理されたスタックトレースはありません）を表示する必要がなかったので、方法がわかりません。クラッシュ時のすべての変数の状態を表示する方法さえ理解できません（残念ながら、VSは管理された例外の後のように私に教えてくれません、そしてそれらをコンソール/ファイルに出力すると遅くなりますアプリは1000倍ですが、これは明らかにオプションではありません）。

では、これをデバッグするにはどうすればよいですか？

[編集]最新バージョンの.Net4.0クライアントプロファイルを実行しているVS2010SP1でコンパイルされました。どうやらそれは「.Net4.0C/.Net 4.0E、.NetCLR1.1.4322」です

4

7 に答える 7

23

何が原因なのかを解明したいのですが、少なくともMicrosoftに送信するための小さな複製を作成したいのですが、どこから始めればよいのかさえわかりません。

「小さい再生」は間違いなくここでは素晴らしいアイデアのように聞こえます...「小さい」は「再生が速い」という意味ではありません。

始める前に、別のマシンでエラーを再現してみてください。別のマシンで再現できない場合は、ハードウェア、インストールなど、まったく異なる一連のテストを実行することをお勧めします。

また、すべての最新バージョンを使用していることを確認してください。これをデバッグするのに何日も費やすのは面倒で（おそらく、私は恐れています）、「はい、これについては知っています。これは.NET4.5で修正された.NET4のバグでした。 " 例えば。さまざまなフレームワークバージョンで再現できるのであれば、それはさらに良いでしょう:)

次に、プログラムでできることをすべて切り取ります。

  • ユーザーインターフェイスはありますか？可能であれば、それを削除します。
  • データベースを使用していますか？すべてのデータベースアクセスを削除できるかどうかを確認してください。後で使用されない出力、理想的には入力も削除できます。アプリ内で入力をハードコーディングできる場合、それは理想的ですが、そうでない場合、ファイルはデータベースアクセスよりも複製が簡単です。
  • データに敏感ですか？繰り返しになりますが、アプリについてあまり知らないと、これが役立つかどうかを知るのは難しいですが、大量のデータを処理していると仮定すると、バイナリ検索を使用して、問題の原因となる比較的少量のデータを見つけることができますか？
  • マルチスレッドにする必要がありますか？すべてのスレッドを削除できる場合は、明らかに問題の再現にはるかに長い時間がかかる可能性がありますが、それでも発生しますか？
  • ビジネスロジックの一部を削除してみてください。アプリが適切にコンポーネント化されている場合は、最初にスタブ実装を作成し、次に呼び出しを削除するだけで、重要なコンポーネント全体を偽造できます。

これらすべてにより、管理しやすくなるまでアプリのサイズが徐々に小さくなります。各ステップで、アプリがクラッシュするか、クラッシュしないと確信するまで、アプリを再度実行する必要があります。利用可能なマシンがたくさんある場合は、それが役立つはずです...

于 2012-10-01T05:58:21.013 に答える
10

tl; dr.Net4.5にコンパイルしていることを確認してください

これは、ここで見つかった同じエラーのように疑わしいように聞こえます。MSDNページから：

このバグは、ガベージコレクターがメモリを解放および圧縮しているときに発生する可能性があります。このエラーは、コンカレントガベージコレクションが有効になっていて、フォアグラウンドガベージコレクションとバックグラウンドガベージコレクションの特定の組み合わせが発生した場合に発生する可能性があります。この状況が発生すると、同じコールスタックが何度も表示されます。ヒープ上に1つの空きオブジェクトが表示され、終了する前に別の空きオブジェクトがヒープを破損しているのが表示されます。

修正は、.Net4.5にコンパイルすることです。何らかの理由でこれを実行できない場合は、ファイルを無効にすることで同時ガベージコレクションを無効にすることもできます。gcConcurrentapp.config

<configuration>
   <runtime>
       <gcConcurrent enabled="false"/>
   </runtime>
</configuration>

または、にコンパイルするだけx86です。

于 2012-12-22T07:55:45.343 に答える
6

Debug DiagnosticToolv1.2をダウンロードします

  1. プログラムを実行する
  2. ルール「クラッシュ」を追加
  3. 「特定のプロセス」を選択します
  4. ページの詳細設定どの例外で失敗するかがわかっている場合は例外を設定するか、このページをそのままにします
  5. ユーザーダンプの場所を設定する

プロセスがクラッシュするのを待ちます。ログファイルはDebugDiagによって作成されます。次に、[ Advanced Analysis ]タブをアクティブにし、上部のリストで[Crash / Hang Analyzers]を選択し、下部のリストでファイルをダンプして、[StartAnalysis ]をクリックします。これにより、HTMLレポートが生成されます。そのレポートで役立つ情報を見つけていただければ幸いです。分析に問題がある場合は、HTMLレポートをどこかにアップロードし、ここにURLを配置して、それに集中できるようにします。

于 2012-10-05T13:35:02.050 に答える
4

私のアプリはネイティブコードを呼び出したり、安全でないブロックを使用したり、uintのようなCLSに準拠していないタイプを使用したりしません

これを考えるかもしれませんが、スレッド化、セマフォを介した同期、ミューテックス、すべてのハンドルはすべてネイティブです。.netはオペレーティングシステム上のレイヤーです。.net自体はマルチスレッドアプリの純粋なclrコードをサポートしていません。これは、OSがすでにサポートしているためです。

ほとんどの場合、これはスレッド同期エラーです。おそらく、複数のスレッドがclr境界の外側にあるファイルなどの共有リソースにアクセスしようとしています。

comなどにアクセスしていないと思われるかもしれませんが、デスクトップフォルダパスの取得などの特定のAPIを呼び出すと、シェルcomAPIを介して呼び出されます。

次の2つのオプションがあります。

  1. ボトルネックを確認できるように、コードを公開してください
  2. .net並列スレッドフレームワークを使用してアプリを再設計します。これには、CPUを集中的に使用する操作を必要とするさまざまなアルゴリズムが含まれています。

ほとんどの場合、コレクションが大きくなり、他のスレッドが干渉する前に操作が実行に失敗するため、一定期間後にプログラムが失敗します。たとえば、生産者/消費者問題の場合、生産者が遅くなるか、消費者が開始する前に操作を終了できなくなるまで、問題に気付くことはありません。

clrは非常に安定しているため、clrのバグはまれです。ただし、コードの記述が不十分だと、エラーがclrのバグとして表示される可能性があります。Clrは、バグがコードにあるのかclr自体にあるのかを検出できず、検出することもありません。

于 2012-10-01T06:21:55.240 に答える
1

  • 私が同等の症状を示したとき、私のDIMMの1つに欠陥があることが判明したため、マシンのメモリテストを実行しましたか（非常に優れたメモリテスタがWin7に含まれています; http：//www.tomstricks.com/how-to- test-your-ram-or-memory-with-windows-memory-diagnostic-tool-in-windows-7 /）

  • この期間の後にCPUが熱くなりすぎると、加熱/スロットルの問題になる可能性もあります。それは私見より早く起こるでしょうが。

  • 分析できるダンプファイルがあるはずです。これを行ったことがない場合は、行った人を見つけるか、Microsoftに送信してください

于 2012-10-01T06:27:13.903 に答える
0

サポート担当者が必要な情報を収集する方法を教えてくれるので、すぐにhttp://support.microsoft.comからサポートケースを開くことをお勧めします。

一般的に、@ paulsm4や@psulekが言ったように、WinDbgまたはDebug Diagを利用して、プロセスのクラッシュダンプをキャプチャでき、その中に必要なすべての情報が埋め込まれています。ただし、これらのツールを初めて使用する場合は、戸惑うかもしれません。マイクロソフトのサポートチームは、ステップバイステップのガイダンスを提供できます。また、プログラムが頻繁にクラッシュするため、データをキャプチャするためにライブミーティングセッションを設定することもできます。

ツールに慣れたら、将来的には同様のトラブルシューティングをより簡単に実行できるようになります。

http://blogs.msdn.com/b/lexli/archive/2009/08/23/when-the-application-program-crashes-on-windows.aspx

ところで、「バグを見つけた」と言うのは時期尚早です。プログラム内でネイティブコードへの依存関係を明らかに見つけることはできませんが、それでもネイティブコードへの依存関係がある可能性があります。問題をさらにデバッグする前に結論を出すべきではありません。

于 2012-10-06T02:31:22.760 に答える