プロジェクトフォルダを開く
ソースとビルドファイルを含むフォルダをチャットの作業フォルダとして選択してください。ファイルツールはそのフォルダ内のみで読み書きを行います。保存したスタックとノートもそこに置けば、ケース全体が1か所に集まり、エージェントがすべて読み取ることができます。
ワークフロー
ラボPC 2台間のWindowsリモートデバッガ設定
03
ラボマシンを2台準備する
リモートWindowsデバッガセッションは、1台のマシン上のデバッガをネットワーク経由で別マシンのプログラムにアタッチするもので、あくまで自分のラボマシン間でのみ行うべきものです。シンボルが最優先です。1台をホスト、もう1台をターゲットと名付けます。プログラムをデバッグシンボル付きでビルドし、そのビルドに正確に一致するPDBを保管してください。PDBが一致しない場合、関数名が正しく表示されず、シンボルなしのスタックではアドレスのみが表示されます。StatusRivetを作業用のホストにインストールし、ターゲットはテスト対象のプログラムのみを配置してください。どちらのマシンでも変更した設定は後で元に戻せるよう記録してください。考えられる最小の入力でクラッシュを再現してください。短いケースは短いスタックと、比較しやすい差分をもたらします。エージェントに指示を出す前に、ホストとターゲットが互いに通信可能か確認してください。接続失敗はデバッガの失敗と見なされるためです。
Ask firstに切り替える
Ask firstは、何らかの変更を行うアクションの前に一時停止するため、実行前に各アクションを確認できます。Plan onlyは、まず手順を確認してから実行したい場合に使用します。プランは再起動後も維持されるため、後で戻って作業を続けることができます。
クラッシュを説明する
プログラム、ホストとターゲットのマシン名、症状を明記し、マシンが自分のものだと伝えてください。ラボのノートから接続詳細を記載し、推測で値を入力しないでください。ターゲットで実行中のビルドと、それに対応するPDBを明記してください。
結果を確認する
差分を読み、ビルドコマンドで再ビルドし、ターゲット上でテストコマンドを再実行してください。変更点のノートはチェックリストと一緒に保管し、新しいテストでも失敗した場合は古いダンプを保管してください。そうすれば、次の試行は記憶ではなく証拠から始まります。
セッションチェックリスト
ターゲットのプログラムにアタッチし、ダンプとコールスタックを保存してから、スタックを読み取ります。
- Shell
attach your debugger to the targetattached - Shell
save the dump on the targetsaved - Shell
write the call stack to stack.txtsaved - read_file
stack.txtread - grep
0xC0000005 stack.txt1 match
次のステップに進む前に承認を待機中拒否承認
debug-session.txt
# Debug session checklist
1. Build the app with debug symbols and keep the PDB
2. Note the build the crash happened on
3. Start the debugger on the host machine
4. Attach to the app running on the target
5. Reproduce the crash with the smallest input
6. Save a crash dump on the target
7. Save the faulting thread's call stack to stack.txt
8. Read the exception code and the top frames
9. Match the first frame to a source line
10. Propose a minimal fix and rebuild
11. Run the test again and note what changed2台のラボマシン間の1つのデバッグセッション用のプレーンテキストチェックリストです。シンボル付きビルド、アタッチ、最小入力でのクラッシュ再現、ダンプとコールスタックの保存、トップフレームの解析、修正後のテスト実行、および変更点の記録をカバーしています。プロジェクトフォルダにコピーしてラボに合わせて編集してください。コピーして編集してください。
リモートWindowsデバッガでクラッシュを分析する
ホストマシンからアタッチする
タスク：ラボのターゲットで実行中の自分のプログラムに、ホストマシンからアタッチします。まずアタッチします。StatusRivetでプロジェクトフォルダを開き、Ask firstに切り替えて設定を説明します。Shellは、あなたが指定した接続詳細を使ってデバッガのコマンドラインモードを実行し、カードには実際の終了コードを通じてアタッチできたかが表示されます。エージェントは接続設定を勝手に発明しないため、ホスト、ターゲット、ポートは自分のラボのノートから確認してください。リモートデバッグは自分のラボマシン専用であり、所有していないコンピュータには使用しません。次のステップに進む前にカードを読んでください。アタッチに失敗した場合は他の処理は行わず、まず接続を修正してから再度試してください。カードには正確なコマンドも記録されるため、後でそれを繰り返すことができます。
ダンプとコールスタックを保存する
タスク：ターゲットで最小入力を使ってクラッシュを再現した後、証拠を保存します。両方のファイルを保存してください。Shellはデバッガにクラッシュダンプの書き出しと、障害スレッドのコールスタックをテキストファイルへの保存を指示し、カードには両方の結果が表示されます。ターゲット上のWindows JITデバッガのエントリは、アプリケーションがクラッシュした際にデバッガを自動的に起動します。これはシステム設定なので、テストマシンでのみ変更し、以前の値を記録して後で復元してください。ミニダンプからのシステムクラッシュの原因を見つけるには、保存されたコールスタックから始めてください。Ask firstモードでは各ステップを承認し、次の人がケースを読むために両方のファイルをチェックリストと一緒に保管してください。ファイル名はビルドに合わせて名付け、混同されないようにしてください。
フレームをソース行に一致させる
タスク：トップフレームを自分のコードに結び付けます。シンボルから始めます。read_fileはstack.txtを開き、grepはプロジェクト内で関数名と例外コード（アクセス違反の場合は0xC0000005など）を検索し、read_fileはその行のソースファイルを開きます。一致するPDBがあれば、スタックには関数名、ソースファイル、行番号が表示され、PDBがない場合はアドレスのみが表示されます。カーネルセキュリティチェック失敗のBSODでフリーズするマシンは、まさにこのルーチン（ダンプ、スタック、ソース）の対象です。エージェントが何か編集する前に、証拠を自分で読んでください。エージェントはテキストから作業するため、プログラムをステップ実行することはできません。ステップ実行には自分のデバッガを使用し、エージェントに観察結果を伝えてください。
修正を提案しテストを再実行する
タスク：発見を修正に変えます。edit_fileは最小限の差分（例えば欠落したnullチェックや不適切なインデックスなど）を提案し、Ask firstモードではエージェントが変更された行を読めるよう一時停止します。Shellはその後、シンボル付きでビルドコマンドを実行し、テストコマンドを実行します。カードには実際の終了コードが報告されます。あなたが書いたドライバーでのカーネルモードヒープ corruption BSODは、悪い書き込みのずっと後で現れることがあるため、最後のフレームだけでなく、スタックで以前に書き込まれたバッファを確認してください。ラボターゲットでの予期せぬストア例外BSODも同じ方法で処理します。テストがパスしてから差分を受け入れ、変更点を記録してください。テストは受け入れ前に行ってください。テストがまだ失敗する場合は、新しいスタックを保管し、2番目のステップからループを再開してください。
