グリーンスクリーンと闘う — RTX64実践デバッグTips【INtime移行者向け】

その他

グリーンスクリーンが出た瞬間、「どこを見ればいいか分からない」のがRTX64開発初期の洗礼です。INtimeではエラーコードと対象プロセスが表示されていたのに、RTX64ではいきなり画面が止まります。この記事では、グリーンスクリーンの読み方から、Visual Studioによるリアルタイムデバッグ、WinDbgポストモーテム解析まで、INtime経験者が知っておくべき実践的なデバッグ手順を解説します。

まず最初にやること：自動再起動を無効にする

デフォルト設定のままでは、グリーンスクリーンやブルースクリーンが発生するとWindowsが自動的に再起動してしまい、止まり際の情報を読む間もなく消えてしまいます。開発環境では必ず自動再起動を無効化してください。

  1. Windowsの「コントロールパネル」→「システム」→「詳細設定」を開く
  2. 「起動と回復」の「設定」をクリック
  3. 「システムエラー」の「自動的に再起動する」のチェックを外す
  4. OKで保存

この設定により、グリーンスクリーン・ブルースクリーン発生時に画面が止まったままになり、エラー情報を確認できるようになります。

グリーンスクリーンの4つのセクションを読む

グリーンスクリーンには4つのセクションが表示されます。それぞれの見方を把握しておくと、原因特定が大幅に速くなります。

セクション内容最初に見るべき情報
Technical InformationRTX64固有のクラッシュ情報・ミニダンプ情報Bugcheckコード（例：RTSS_2_000E）
Thread Contextクラッシュ時のスレッド状態（レジスタ・スタックポインタ等）RIP（実行中のアドレス）
Current thread Stackクラッシュ時のスタックトレースどの関数で止まったか
Windows Blue Screen sectionWindowsのブルースクリーンと同形式の補足情報ドライバや共有リソースのエラー時に参照

最初に見るべきはBugcheckコードです。前の記事で紹介した RTSS_2_000E（Memory Access Fault）や RTSS_2_000C（Stack Fault）といったコードがここに表示されます。コードから原因のカテゴリを絞り込んでから、スタックトレースで発生箇所を特定するのが基本の流れです。

Visual Studioで生きているRTSSプロセスにアタッチする

RTX64 SDKはVisual Studioと統合されており、実行中のRTSSプロセスにデバッガをアタッチしてブレークポイント・ウォッチ・ステップ実行が使えます。グリーンスクリーンになる前の「怪しい動作」を調査するときに使います。

詳しくは、公式の記事（英語になります）を参照してください。

ローカルマシンのRTSSプロセスにアタッチする手順

  1. Visual Studioのメニューから デバッグ → Attach to RTSS Process を選択
  2. 「Attach to RTSS Process」ダイアログに、実行中のRTSSプロセス一覧が表示される
  3. デバッグしたいプロセスを選んで「Attach」をクリック

アタッチ後は通常のVisual Studioデバッグと同様に操作できます。

リモートマシンのRTSSプロセスにアタッチする手順

実機（ターゲットPC）にデプロイしたアプリを開発PC（ホスト）からデバッグする場合は、以下の準備が必要です。

  1. ターゲットPC：Visual Studio Remote Toolsをインストールする
  2. ターゲットPC：RTX64コントロールパネルの「Remote Debug」で「Allow remote debugging connections」を有効化
  3. ターゲットPC：Visual Studio Remote Debugger（msvsmon）を起動する
  4. ホストPC：Visual StudioのDebug → Attach to RTSS Processで「Connection Target」にターゲットPCのIPアドレスを入力
ポート方向プロトコル用途
31094双方向TCPRTX64リモートデバッガ
msvsmon指定ポート受信TCPVisual Studio Remote Debugger
3702送信UDPリモートデバッガの自動検出（任意）

注意：デバッグ中のRTSSプロセスはTask Managerや RtssKill コマンドでは終了できません。終了するには必ずVisual Studioのデバッガからデタッチしてください。

WinDbg拡張コマンドによるポストモーテム解析

グリーンスクリーンが発生した後、ミニダンプファイルを解析してクラッシュ原因を特定するのが「ポストモーテム解析」です。RTX64はWinDbgの拡張コマンドセットを提供しており、RTSSの内部状態を詳細に調査できます。

この拡張機能を読み込むことで、通常のWinDbgだけでは見えにくいRTSSアプリケーションやRTX64 Subsystemの状態を、!rtprocess や !rtthread などの専用コマンドで確認できます。

コマンド内容使いどころ
!rtanalyze現在のRTSS例外情報を表示グリーンスクリーン直後の原因確認に最初に実行
!rtcurrentprocess各RTSSコアで実行中のプロセス情報どのプロセスがクラッシュしたか特定
!rtcurrentthread各RTSSコアで実行中のスレッド情報クラッシュ時のスレッド状態を確認
!rthandle指定プロセスのRTSSハンドル情報ハンドルリークや未解放オブジェクトの調査
!rtimsプロセスの内部メモリ空間（MSpace）の統計メモリ使用量・断片化の確認
!rtemsプロセスの外部メモリ空間（MSpace）の統計拡張メモリ使用状況の確認
!rthelp利用可能なコマンド一覧コマンドを忘れたとき

基本的な解析の流れ

// WinDbgでの解析手順（コマンド例）

// 1. まず !rtanalyze でクラッシュの概要を確認
// !rtanalyze
//
// 出力例：
// RTSS Exception: RTSS_2_000E - Memory Access Fault
// Faulting Address: 0x0000000000000000  ← NULLポインタ参照
// Process: myapp.rtss (PID: 0x1234)

// 2. クラッシュしたプロセスを特定
// !rtcurrentprocess

// 3. そのプロセスのメモリ使用状況を確認
// !rtims

// 4. ハンドルのリークがないか確認
// !rthandle

INtimeのデバッグ（ステップ実行でエラーコードを追う）とは大きく異なり、RTX64ではダンプファイルから「死後の状態」を読み解くスキルが重要になります。!rtanalyze から始めれば原因の8割は絞り込めます。

参考情報

  • Debugging with the RTX64 WinDbg Extension
    RTX64 WinDbg Extension は、Microsoft の64bit版 WinDbg を拡張し、RTSSアプリケーションとRTX64 Subsystemの状態を解析・解釈するためのもの、と説明されています。ライブターゲットへのBreak-In解析や、Windowsクラッシュ時に生成されたメモリーダンプの事後解析に使える、とあります。
  • RTX64 WinDbg Extension Commands Reference
    ここが「拡張コマンドセット」の本体です。!rtanalyze、!rtcurrentprocess、!rtcurrentthread、!rtprocess、!rtthread、!rtsubsysinfo、!rtversion など、RTX64用のWinDbg拡張コマンド一覧が載っています。
  • Using RTX64 WinDbg Extension Commands
    使い方のページです。RtDbgExt.dll をWinDbgでロードしてから、!rtversion などのRTX64拡張コマンドを実行する流れが説明されています。

デバッグ効率を上げる5つのTips

  • 開発中はRTSSDebugビルドを使う：デバッグ情報（/Zi）が含まれスタックトレースが読みやすい。RTSSReleaseビルドは最適化で行番号がずれるため原因特定が難しくなる。
  • スタックサイズは余裕を持って設定する：RTX64のStack Faultは即死。INtimeより厳しいため、再帰処理や大きなローカル変数には特に注意。
  • UNDER_RTSS_UNSUPPORTED_CRT_APIS を定義してビルドする：RTSSで使えないC標準ライブラリ関数をコンパイルエラーとして検出できる。移行初期に特に有効。
  • プロセスをKillせずグレースフルシャットダウン：RtssKill で強制終了するとサブシステムが不安定になることがある。デバッグ後はVisual Studioからデタッチして正常終了させる。
  • WatchdogタイムアウトをControlPanelで調整する：デバッグ中にブレークポイントで止めるとWatchdogが発動してプロセスがフリーズすることがある。開発中はタイムアウト値を大きめに設定する。

まとめ

  • 最初にやること：Windowsの自動再起動を無効化してStop Messageを確実に読めるようにする。
  • グリーンスクリーンの読み方：4セクションのうちBugcheckコードとスタックトレースを最初に確認する。
  • 生きているプロセスのデバッグ：Visual Studioの「Attach to RTSS Process」でブレークポイント・ステップ実行が使える。
  • クラッシュ後の解析：WinDbg拡張の !rtanalyze から始め、!rtcurrentprocess・!rtims で絞り込む。
  • 「死なない」設計：RtAttachShutdownHandler を必ず実装し、BSOD後も緊急停止処理を走らせる。
  • INtimeとの最大の違い：エラーコードで追うデバッグから、ダンプ解析・リアルタイムアタッチへのマインドチェンジが必要。

あとがき

INtime開発でも、問題の原因がすぐにわからないことはあります。

ただ、INtimeの場合はWindows上で操作できるため、ログなどを手がかりにしながら、少しずつ原因を追っていくことができます。このあたりの調査がしやすいのは、大きな安心材料ですね。

一方でRTXで発生する問題は、調査の取っかかりが見つけにくく、まるで突然、道具を取り上げられたような感覚がありました。RTXの知識がまだ少なかったころは、正直かなりしんどかったです。

最近は、メモリーダンプからブルースクリーンの原因を少しずつ探れるようになってきました。こうした経験を積むことで、以前は見えなかった手がかりも、少しずつ見つけられるようになってきたと感じています。

トラブルから身を守るための技術を、これからも一緒に学んでいきましょう！

コメント

タイトルとURLをコピーしました