8

予期しないエラー処理プロセスの書き直しに取り組んでいます。コミュニティに質問したいと思います。

作成したソフトウェアがクラッシュした場合、自動と手動の両方でどのような情報を取得しますか？

今、私はいくつかのアイテムをキャプチャします。そのうちのいくつかは次のとおりです。

自動：

  1. クラッシュしたアプリの名前
  2. クラッシュしたアプリのバージョン
  3. スタックトレース
  4. オペレーティングシステムのバージョン
  5. アプリケーションが使用するRAM
  6. プロセッサの数
  7. スクリーンショット:(非公開アプリケーションのみ）
  8. ユーザー名と連絡先情報（Active Directoryから）

マニュアル：

  1. ユーザーはどのような状況にありますか（つまり、どの会社、テクニカルサポートの電話番号、RA番号など）
  2. ユーザーはいつ起こると思っていましたか？（一般的な応答：「クラッシュしない」）
  3. 再現する手順。

特に、ほとんどのユーザーが何が起こったのかを尋ねられたときにキーボードをマッシュするだけであることを考えると、アプリケーションの問題の真の原因を発見するのに役立つ他の情報をキャプチャします。

記録のために、私はC＃、WPF、および.NETバージョン4を使用していますが、必ずしもそれらに限定したくはありません。

関連：何をすべきか：ソフトウェアがクラッシュしたときに情報を収集する

関連：最先端のエラーおよび例外処理戦略には何を含める必要がありますか？

4

6 に答える 6

1

そして今、パラノイアキャンプから:(

ソフトウェアが対象とする業界を検討してください。ユーザー (Active Directory 名も含む) またはネットワークに関する情報を収集すると、アプリがブラックボール化され、法的責任が生じる可能性があります。つまり、バグ データベースが危険にさらされ、その情報が銀行や政府の研究所のネットワークに侵入するために使用された場合はどうなるでしょうか。IP を含むバグ レポートは通知されますか? 訴えられますか？多分...

たとえば、ネットワークの問題を診断するためにネットワーク固有のデータを収集する必要がある場合は、データが返送される前に、アプリでシステム名または IP をプレースホルダーに置き換えることを検討してください。(emailSrvr1、bankAcctNumSrv は srvr1 および srvr2 になります) 問題を追跡するのはより大きな苦痛ですが、その価値があるかもしれません。これは、問題を引き起こす可能性のある情報をキャプチャしますが、役立つ場合があります.

私はハイエンドの企業や政府と数年間仕事をしてきましたが、それは私の見解を彩っていますが、収集しているものとそれがどのように保管されているかを検討する価値があるでしょう.

于 2010-05-16T12:06:24.077 に答える
0

私はあなたのリストに最も重要な情報を見ていません（dotnet / javaレベルのコードについて話しているとき）。
例外タイプ、メッセージ、およびトレース。
簡単なコードを使用して、例外をキャッチし、「ログに書き込む」/「電子メールに直接送信する」ことができます。

于 2010-05-15T22:37:56.007 に答える
0

プロセスログについては言及していません（Linuxのsyslog、Windowsのイベントビューアなど）。私はシステム管理者のバックグラウンドも持っているので、ログ機能を備えたプログラムに心から感謝しています。冗長レベルを選択できればさらに良いです。

環境について詳しく知ることは良いことであり、ユーザーが他のツールと何らかの統合作業を行う必要がある場合にも役立ちます。

ユーザーがより技術的な場合は、ログの詳細度を最大に設定してエラーを再度再現するようにユーザーに依頼できます。

于 2010-05-15T14:06:39.413 に答える
0

LA Transtar は、障害の場合にのみ保存される主要なログも保持します。このログには、進行中のプログラムの入力とトレースが含まれています。ログは、新しいトランザクションが開始されるたびにリセットされます。

于 2010-05-13T20:34:37.797 に答える
0

基本的に、すべてのアプリケーションで従わなければならないゴールデン ルールはありません。ビジネス アプリケーションとシナリオに応じて、エラーが発生した場合の情報収集に含めるのに最適なものが異なります。

あなたが言及したものは問題ありませんが、ログに記録するのに適したものはもう少しあります：

  • 重要で複雑な操作の入力パラメータ
  • プログラムのコンテキスト - 重いアルゴリズムを持ついくつかのオブジェクト - 最もリスクのあるクラス
  • あなたのプログラムの状態

例 : プログラムの流れは状態オートマトンのようなもので、5 つの状態があり、状態 3 に達しています。

  • サーバークライアントのアプリケーションがある場合は、両方のログを収集します - プロバイダー側​​と消費側から

  • メモリ ダンプは一般的には良い提案ではありません。制御できないフレームワークや JVM (たとえば) の問題を理解する必要がある場合にのみ行ってください。たとえば、OutOfMemoryError

于 2010-05-15T17:04:41.310 に答える
0

（これはWindows / .NET固有のものですが、質問で指定したものであり、そのコンテキストでは非常に役立つ情報だと思います。）

アプリケーションが厳密にシングルスレッドでない限り、例外をスローしたスレッドのスタック トレースだけでなく、ダンプ ファイル (少なくともすべてのスレッドのスタックを提供します) が必要です。

大きすぎず、有用なマネージド スタック トレースを提供するのに十分な情報を含むダンプを生成するのは少し注意が必要ですが、 clrdumpという非常に便利なユーティリティがあり、厄介な詳細の一部を処理してくれます。

Clrdump は、ほとんどが Microsoft の DbgHelp.dll のラッパーです。DbgHelp を直接使用できます -この質問を参照してください- ただし、アプリケーションの仮想アドレス空間と同じ大きさの「完全なミニダンプ」が得られますが、これはかなり大きくなる可能性があります。Clrdump は、スタック トレースだけでなく、SOS がそれらを読み取るのに十分な情報を含む小さなダンプを作成するという素晴らしい仕事をします。

于 2010-05-14T18:07:52.240 に答える