5

私はこれを尋ねることによってさえ王室の炎に自分自身を開いていることを知っています、しかし私はStackOverflowが私が抱えている問題に対する解決策を持っているかどうか見るだろうと思いました...

ローカルで再現できない方法でクライアントサイトで失敗しているC#アプリケーションがあります。残念ながら、問題の原因を特定するのに役立つ情報を入手することは非常に困難です(不可能です)。

私は、通常のすべての場所で未処理の例外を監視する、かなり広範なエラー監視フレームワークを配置しています。

  • 私が制御するスレッドのバックストップ例外ハンドラ
  • WinForms例外のApplication.ThreadException
  • AppDomain.CurrentDomain.UnhandledException

私がアクセスできる場所に詳細情報を記録します。

これは、過去に本番コードの問題を特定するのに非常に役立ちましたが、現在の一連の問題に関する情報を私に提供していません。

私の推測では、コアの問題は「失礼な」例外タイプ(スレッドの中止、メモリ不足、スタックオーバーフロー、アクセス違反など)の1つであり、失礼なシャットダウンにエスカレートし、プロセスをリッピングします。何が起こっているのかを見るチャンス。

プロセスがクラッシュしているときにスナップショット情報に対して実行できることはありますか?理想的には、カスタムログ形式を書き出すことができますが、クラッシュダンプがどこかに書き込まれることを保証する信頼できる方法があれば幸いです。

私はCriticalFinalizerObjectから派生したクラスを実装し、それが破棄されるときにラストチャンスエラーログアウトを吐き出すことができることを望んでいましたが、それは私がテストしたStackOverflowシナリオではトリガーされないようです。

コード署名証明書がないため、Windowsエラー報告などを使用できません。

私は恣意的な例外から「回復」しようとしているのではなく、途中で何が悪かったのかを書き留めようとしているだけです。

何か案は?

4

2 に答える 2

1

ミニダンプファイルを作成してみてください。これはC++APIですが、アプリケーションを起動してプロセスへのハンドルを保持し、プロセスハンドルを待機し、アプリケーションが停止したときにプロセスハンドルを使用してミニダンプを作成する小さなC++プログラムを作成できるはずです。

于 2010-02-04T02:25:49.583 に答える
1

あなたが主張することをした場合:

  • Application.Run の Try-Catch
  • 未処理のドメイン例外
  • 未処理のスレッド例外
  • すべてのスレッドで Catch ハンドラーを試す

サード パーティまたは COM コンポーネントによって例外がスローされた場合を除いて、例外をキャッチしたことになります。

あなたは確かに十分な情報を提供していません。

  • クライアントはどのような出来事が例外につながると言っていますか?
  • どの COM またはサードパーティ コンポーネントを使用していますか? (これらのコンポーネントを適切にインスタンス化して参照していますか? COM 関数呼び出しに有効な引数を渡していますか?)
  • 管理されていない安全でないコードを使用していますか?
  • すべての throw 可能な呼び出しが try-catch でカバーされていることに確信があります?

もっと多くの情報を投稿しない限り、誰もあなたに有益なアドバイスを提供することはできず、それでも問題の原因について推測することしかできないと言っているだけです.

コードを新鮮な目で見てもらいます。

一部のエラーは、ログではキャッチできません。

詳細については、この同様の質問を参照してください。

.NET の StackOverflowException

非同期例外 (およびそれらから回復できない理由) を説明するリンクを次に示します。

http://www.bluebytesoftware.com/blog/PermaLink.aspx?guid=c1898a31-a0aa-40af-871c-7847d98f1641

于 2010-02-04T02:52:38.467 に答える