プログラムのクラッシュに関する情報の収集を自動化します

有名な言い回しを言い換えると、「何もエンコードしていない人はバグを作りません。」 各開発者はバグの作成方法を知っており、バグを作成することを好みますが、バグを後で修正することは好みません。 1つの場合のコードのエラーは、プログラムによる誤ったデータ処理につながり、もう1つの場合は例外（クラッシュ、クラッシュ、クラッシュ）につながります。 この投稿では、プログラムのクラッシュに関するデータの収集を自動化して、エラーを解析および修正する際の生活を大幅に簡素化する方法について説明します。



エラーデータの収集を自動化するプロジェクトでライブラリを使用したいと友人に言ったとき、私が見た反応を知っていますか？ 私は文字通り次のことを聞いた。「なぜそんなに複雑なシステムが必要なのでしょうか？ 私のプログラムで何かが起こったら、ユーザーは私に手紙を書き、どのボタンを押し、何をしたのかを見てください。 そして、エラーを再現して修正します。」



はい、プログラマーは怠け者です。 ユーザーが手動で検出したエラーを修正することは有益であると確信したいと思います。 同様に、ユニットテストがなくても、プロジェクトのビルド時にコンパイラが流出するという警告を修正しなくても、高品質のコードを書くことは非常に現実的であると確信しています。 それでも同じように、顧客は「すぐに準備を整える」必要があり、すべてのエラーは後で特定され、解消されます。 そこにテスターが座って、バグを捕まえます。 常に十分な時間がない、期限が切れている、当局が「余計な付加機能」を認めていない。



そのようなプロジェクトは記録的な速さで実行される可能性があり、おそらくほとんどのエラーはテスターに​​よってキャッチされますが、それにもかかわらず、リリース後、ユーザーはプログラムの例外についてサポートに文句を言い、苦情を訴えます。 時間の経過とともに、わかりやすいアーキテクチャ、コードコメント、単体テストなどの欠如が感じられます。 他の誰かのコードに変更を加える各開発者は、新しいバグと例外の可能性を作成します。その一部は再びテスターに​​よってキャッチされ、一部はリリースされます。

ユーザーが助けを求めるメールを送信したとき、私は通常何をしますか？

ユーザーが自分のマシンにインストールされたプログラムで重大なエラーが発生したという通知をサポートサービスに送信すると、通常、サポートにアプリケーションのバージョンとオペレーティングシステムのバージョンを問い合わせます。 ユーザーシステムのソフトウェア環境は、エラーの原因を特定するために非常に重要だからです。



まず、仲介者（サポート）を介してユーザーと通信する必要があります。仲介者は、まだ何をしたいのかを説明する必要があります。次に、コンピューターの電源を入れて起動する方法しかわからないユーザーに技術情報を要求する必要がありますオフィス。 私が話したユーザーのほとんどは、彼らに不快感を与えられず、彼らの考えを表現できず、専門用語を知らないでしょう。 そのようなレジストリキーを変更し、非表示のLocalAppDataフォルダー内のファイルを表示する方法を説明することはできません。



ユーザーが私の要求に答えると、ほとんどの場合追加の質問があります。「しかし、このボタンをクリックして、このオプションを変更してみてください。」 それに応じて、私は沈黙します。 ユーザーは、必要なすべての情報を取得するまで、これを数回行う忍耐力がありません。



私のプロジェクトでは、サービスであるかウィンドウインターフェイスを備えたアプリケーションであるかに関係なく、ログを保持しています。 エラーメッセージと現在の操作をログに書き込みます。 理論的には、ログファイルは、ユーザーが知らない、または知ることができないアプリケーションに関する技術情報をユーザーから取得するのに役立つはずです。



アプリケーションでエラーが発生した場合、ユーザーにログファイルを要求します。 これが問題の始まりです。 ログファイルをどこから取得し、どの時点で取得するかをユーザーに正確に説明することは、簡単な問題ではないことがわかりました。 多くの場合、ユーザーはエラーの発生後にアプリケーションを再起動します。その後、ログファイルが上書きされて空になり、戸惑いを引き起こします。



一般に、バグを分析するときの私の主な目標は、このバグをマシン上で再現することです。 これで修正できます。 ユーザーの言葉から、どのようにアプリケーションをクラッシュさせるのか、アプリケーションで例外をどのように発生させるのかは明確ではありませんか？ この質問に答えるのは困難です。目の前にはログに大量のテキストしかありません。



したがって、ユーザーとのコミュニケーションの次のステップは、スクリーンショットを撮るか、ビデオを記録して、アクションを表示するか、アプリケーションでエラーが発生したかを確認することです。 多くのユーザーが私にビデオを送っていると思いますか？ いいえ、しかし、それにもかかわらず、そのような職人は私に会いました。 また、このようなビデオは、エラーを再現するのに最も便利な場合がありました。



そのため、アプリケーション内の重大なエラーに関するデータを手動で収集する主な欠点は、ユーザーが怠け者であり、縛られていることです。 彼はあなたの仮説をテストしてエラーの原因を特定しません-彼はこれに対する欲求、忍耐、技術的な知識を持っていません。

結局のところ、エラー情報を手動または自動で収集する方がよいのでしょうか？

エラーレポートの自動収集と配信のアイデアは、2000年代初頭のMicrosoft [1]で登場し、多数の製品（WindowsやOfficeを含む）で発生するエラーのhに困惑しました。 Windows開発チームは、システムのコアをダンプして分析できるツールを開発しました。



とにかく、Officeチームは、未処理の例外をキャッチしてミニダンプを作成できるツールを作成しました 。 ミニダンプには、ダンプとは異なり、例外が発生したスレッドのスタックのスナップショットを読み取るために必要なプロセスの仮想メモリの小さな断片のみが含まれていました。 ミニダンプは、インターネット経由で自動的に送信できるため、非常に便利であることがわかりました。



この開発はWindowsエラー報告（WER）と呼ばれ、Windows XPに実装されました。 それ以来、すべてのマイクロソフト製品がWERエラーをキャッチしています。 マイクロソフト製品でWERを使用することの有効性について、次の統計[2]があります。

• 「上位」で検出されたエラーの20％を修正すると、顧客の問題の80％を解決できます。
• エラーのわずか1％の原因を修正することにより、顧客の問題の50％を修正できます。

開発者は誰でもWERを使用して、アプリケーションのエラーデータの収集を自動化できます。 WERはMicrosoftサーバーにエラーレポートを送信し、開発者はこのサーバーに「無料で」アクセスできます。 ただし、このためには、VeriSign証明書が必要です。 このような証明書の購入には、年間500ドルの費用がかかります。 実際、Windows用に開発している場合は、証明書を購入する必要があるため、WERサーバーに無料でアクセスできると想定します。



WERに加えて、プログラムのクラッシュに関するデータを収集するためのその他の無料ライブラリがあります。 たとえば、Windows上のC ++プロジェクトでは、CrashRpt [3]というオープンソースライブラリを使用しています。 linuxoidsにオープンなGoogleライブラリブレイクパッドを使用するようアドバイスできます[4]。



個人的には、CrashRptの方が好きです。なぜなら、私はWindowsでしか書かないからです。 さらに、このライブラリを使用すると、エラーレポートファイルをHTTP経由でサーバーに送信できるだけでなく、メールボックスへの手紙として送信することもできます。 さらに、このライブラリでできることは他にあります。

どのエラーデータを自動的に収集できますか？

そのため、アプリケーションで例外が発生しました。 例外は、メモリ内のゼロアドレスへのアドレッシング、スタックオーバーフロー、メモリ枯渇など、さまざまな理由でトリガーされる可能性があります。 MSDNでは、Cランタイムが例外をキャッチ（処理）するために提供する約12の関数を見つけることができます。 CrashRptライブラリもこれらの関数を使用します。



例外が発生すると、CrashRptハンドラーが起動され、まず最初に例外ポインター（これは例外アドレス、そのコード、およびタイプを含む構造体）を保存します。 次に、CrashRptは新しいプロセスを開始し、例外ポインターをそれに渡します。 例外が発生した親アプリケーションは不安定で、すべてのエラーデータが取得されるとすぐに終了します。

ミニダンプ

新しいプロセスでは、主な作業はエラーデータを収集します。



まず、Microsoftのdbghelp.dllシステムライブラリを使用してミニダンプが作成されます。 これを行うには、親プロセスのすべてのスレッドが中断され、プロセスの「スナップショット」が実行されます。 プロセスにロードされたすべてのDLLモジュールの名前とバージョンが記録されます。 プロセスで動作したスレッドの識別子が保存されます。 スタックのスナップショットは、スレッドごとに記録されます。 ミニダンプには、オペレーティングシステムのバージョン、CPUの数、およびブランドに関する情報も保存されます。 数十キロバイトのオーダーのミニダンプの重量があります。



ミニダンプファイルを受け取った後、Visual Studioでそれを開いて、クラッシュ時のプログラムの状態を視覚的に確認できます：アプリケーションのバージョン、オペレーティングシステムのバージョンを確認し、例外が発生したコード内の場所を確認します（下図を参照）。 人生は人生を楽にしますか？

ログ

プログラムのクラッシュに関する情報の収集を自動化しても、通常のログを強制的に破棄することにはなりません。 以前と同様に、現在の操作をログに書き込むことができます。クラッシュすると、ログがエラーレポートに自動的に追加されます。 これにより、「手動」ユーザーログ要求で以前に発生した可能性がある誤解がなくなります。 これで、プログラムがクラッシュした時点でログに常に最新のデータが含まれるようになり、ユーザーは非表示のLocalAppDataフォルダーを開く方法とそこから取得するファイルを説明する必要がなくなります。



ログに加えて、エラーレポートに必要な他のファイルを追加できます。

スクリーンショット

ミニダンプとログが気に入らないのは、エラーを再現できないことが多いことです。 はい、プログラム内でクラッシュが発生した場所を確認でき、発生する可能性から仮説を立てることができます。 たとえば、クラッシュは多くの場合、変数が初期化されておらず、メモリ内のガベージアドレスへの呼び出しがあるという事実から発生します。



しかし、どのように戦っても、ほとんどの場合、マシンでクラッシュを再現できるアクションを選択することはできません。 ポイントは、各ユーザーが自分のマシンの環境とは異なる独自のソフトウェア環境を持っていることだけではありません。 問題は、ユーザーがプログラムを操作する独自のパターンを持っていることです。 プログラムの使用方法、プログラムで実行するアクションは、ユーザーの操作とは根本的に異なります。



したがって、エラーに関する非常に有用な情報は、クラッシュ時のユーザーの画面のスクリーンショットです。 CrashRptライブラリを使用すると、このようなスクリーンショットを自動的に作成し、JPEG形式（圧縮品質をカスタマイズ可能）またはPNGで保存できます。 その結果、エラー時にユーザーがどのボタンを押したかを確認できます。これは、エラーを再現するのに非常に役立ちます。



次の図では、アプリケーションのクラッシュ時に撮影したスクリーンショットの例を示しました。 スクリーンショットにはアプリケーションウィンドウ領域のみが含まれ、残りの領域は自動的に黒く塗りつぶされます（ユーザーのプライバシーを保護します）。

動画

プログラムがクラッシュする直前に行ったアクションを描いたビデオをユーザーから数回送られたことを覚えていますか？ したがって、CrashRptライブラリを使用すると、ユーザーにビデオを作成するように頼む必要はありません。 ライブラリ自体がそれらを作成します（もちろん、ユーザーの同意を得て）。



クラッシュがいつ発生するかを予測できないことは明らかです。 したがって、CrashRptは定期的に（指定した間隔で）画面のスクリーンショットを取得し、非圧縮形式で（BMPファイルとして）ディスクに保存します。 スクリーンショットが蓄積されると、古いスクリーンショットが削除され、新しいスクリーンショットが代わりに使用されます。 私のマシンでのテストでは、CPUリソースの約5〜7％と数百メガバイトのディスクが必要です。



例外が発生した場合、記録されたスクリーンショットはOGG Theoraコーデック[5]によって圧縮され、ChromeまたはFirefoxブラウザー、または任意のビデオプレーヤーで開くことができるビデオファイルが取得されます。



はい、ビデオ録画操作はかなりリソースを消費しますが、常に含める必要はありません。 たとえば、ユーザーとのトライアルが行き詰まっていて、エラーを再現する最後の機会が残っている場合にのみオンにできます-ビデオを削除します。

おわりに

エラーデータの収集を自動化せずに、クラッシュを引き起こすプログラムのバグを修正することは可能だとは言いません。 しかし、自動化により、これを非常に効率的に行うことができます。 開発者の生活を楽にします。 そして、必ずしもリリース後だけではありません。 たとえば、プログラムのベータテストの初期段階ですでに自動化を使用して、スクリーンショットの撮影方法やビデオクリップの記録方法を常に理解していないテスターとのコミュニケーションを促進します（テスターは不快感を感じることはありません）。



ちなみに、C [6]で最も短い落下プログラムは何か知っていますか？

main(){main();}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

参照資料

1. カーク・グレラム等。 （非常に）大規模なデバッグ：実装と経験の10年。 第22回オペレーティングシステムの原則に関するACMシンポジウム（SOSP '09）、2009年の議事録。
2. Windowsエラー報告：はじめに 、MSDN
3. CrashRpt-Windowsアプリケーション用のクラッシュ報告システム。 Google Project Hosting。
4. breakpad-クラッシュレポート。 Google Project Hosting。
5. Theoraビデオ圧縮
6. Cの最短「落下」プログラム 、RSDNフォーラム