知っておくと便利な「Visual Studio 2012」によるドライバのトラブルシューティング：Windows 8 デバイスドライバ開発入門（2）（1/3 ページ）

Windows 8対応のデバイスドライバを開発する際に、“知っておくと便利なポイント”を実践的な観点から紹介する連載「Windows 8 デバイスドライバ開発入門」。第2回では、デバイスドライバのトラブルシューティングついて取り上げる。

[橋口友美（サイエンスパーク），MONOist]

　連載第1回「知っておくと便利な『Visual Studio 2012』によるテスト署名」では、マイクロソフトの開発環境「Visual Studio 2012」を使用した“ドライバのテスト署名方法”について解説しました。

　ドライバのビルド後、テスト署名が終わると、次はいよいよ“動作確認”の段階です。しかし、いざ動かしてみたら、インストール直後にブルースクリーン（BSOD：Blue Screen of Death）が発生し、デバイスが認識できない!? 何ていうトラブルがよく起こります。

　そこで連載第2回となる今回は、“デバイスドライバのトラブルシューティング”にフォーカスし、知っておくと便利なポイントを実践的な観点から説明していきます。なお、以降の内容は、Windows Desktop OS、およびWindows Embedded Standard OS用のデバイスドライバ開発に共通した内容となります。

1．デバイスドライバが引き起こす現象は？

　まず、自分で開発したデバイスドライバがソフトウェア的な問題を抱えている場合、どのようなことが起こり得るのでしょうか？ まれにニュースでも取り上げられていますが、最も有名なのはBSODです。画面が突然“真っ青”になり、PCが再起動してしまう現象です。その際、ユーザーがどんな作業をしていたかなんて一切お構いなしに、勝手に再起動してしまいます。例えば、データのコピー中にBSODが起きると、ファイルが破損する可能性もあります。まさに「死のお告げ」ですね……。

図1　ブルースクリーン（BSOD：Blue Screen of Death）画面。左が「Windows 7」以前、右が「Windows 8」以降　※画像クリックで拡大表示

　この現象は、アプリケーションでいうところの「アプリケーションが強制終了しました」に相当します。

図2　アプリケーションの強制終了

　アプリケーションがメモリアクセス違反などを起こすと、OSが「コイツは危ない！」と判断して、アプリケーションを強制終了します。これと同様に、デバイスドライバがメモリアクセス違反を起こすと、OSはデバイスドライバを強制終了しようとします。ですが、OSとカーネルモードのデバイスドライバ（注1）は仮想メモリ空間を共有しているため、“デバイスドライバの強制終了＝OSの強制終了”となり、OSは自爆してしまいます。その結果がBSODというわけです。

注1：ユーザーモードのデバイスドライバの場合は、仮に問題が起きてもBSODとはなりません。ユーザーモードのプログラムは、OSと仮想メモリ空間を共有しないためです。

　デバイスドライバには制限や決まりごとが複数あり、BSODが起きる原因はメモリアクセス違反だけでなく多岐にわたります。BSODの発生時、「STOP CODE」と呼ばれるエラーコードが画面に表示されますが、その種類の多さを見てもお分かりいただけるかと思います。

BSOD：STOP CODE

http://msdn.microsoft.com/en-us/library/windows/hardware/hh994433%28v=vs.85%29.aspx

　BSODの他にも、PCのフリーズやデバイスと通信できなくなるなど、デバイスドライバが原因で引き起こされる問題はどれも致命的です。もちろん、こうしたトラブルは未然に防ぐことが一番ですが、フィールド上では予期しない問題が発生する場合もあります。

　実際にこれらの問題が発生した場合、解析の手掛かりとなるのは以下の2つです。

（1）ダンプファイル　
（2）トレースログ

　本稿では、主に（2）のトレースログについて説明しますが、先に（1）のダンプファイルについて紹介しておきます。

2．BSODが起きたらまずはダンプファイルを見るべし！

　カーネルモードのプログラムで致命的なエラーが起きるとBSODが発生しますが、OSはその際に「Dying Message（ダイイングメッセージ）」を残します。それが、「ダンプファイル」と呼ばれるものです。

　ダンプファイルとは、BSOD発生時の物理メモリの中身をコピーしたファイルのことで、「MEMORY.DMP」というファイル名で“%SYSTEMROOT%”の直下に作成されます。BSODが発生した場合、PC再起動後に、このファイルが生成されているはずなのでチェックしてみてください。

　このダンプファイルから読み取れることは、大まかに以下の3点です。

1. BSODが起きた原因（＝STOP CODE）
2. BSODを起こしたカーネルモードプログラム（＝犯人）
3. BSODが起きたときの実行スレッド（＝Call Stack）

　ダンプファイルはバイナリファイルですので、一般的なテキストエディタでは表示できませんが、Visual Studio 2012を使用して開くことができます。

　ドライバのプロジェクトファイル（.sln）を開き、メニューから［ファイル］―［開く］―［Crash Dump...］で、ダンプファイル（MEMORY.DMP）が存在するパスを指定します。

図3　ダンプファイルを開く

　また、以下のコマンドで「シンボルファイル」の指定が可能です。シンボルファイルとは、ドライバをビルドすると生成される、拡張子が「.PDB」のファイルのことです。通常は、ビルド時にドライバ本体（.sysファイル）と同一フォルダ内に作成されます。

.sympath <シンボルファイルパス>   // シンボルファイルの指定
.reload                             // シンボルファイルの再読み込み

.sympath C:\Users\test\Desktop\KMDFSampleDriver\Win7Release
.reload

入力例

　以降のドライバ解析の手順については、「Windows 7」以前のドライバと同じく、「WinDbg（ Windowsデバッガー）」を使用して解析しますので、ここでは割愛します。

　続いて、今回のメインであるトレースログについて説明します。