ドライバー検証ツール

さなえすです。お久しぶりです。

 

早いもので 4 月ですね。桜が咲いて、日に日に春らしくなっていくのを感じられるので、日本の 4 月は大好きです♪

 

さて、いきなり本題に入りますが、みなさんは、Driver Verifier ってご存じですか？

 

Driver Verifier は、OS にインストールされているドライバーの検証ツールです。その他にも WDK で提供しているドライバーの検証ツールもあります。今日は、主に ①Static Driver Verifier (SDV)、②　PREfast、③　Driver Verifier + Gflags の 3 つの使用方法を簡単にご紹介したいと思います。

 

ドライバーの検証ツールとは、いわば、ドライバーの健康診断みたいなもので、いくつかのチェック項目やルールに沿って検査をします。検査方法としては、大きく分けて、”静的“ と “動的“ に分かれます。コードパスをチェックしたり、関数呼び出しのパラメータチェックを行ったりして、ビルド時に解析を行うのが前者で、実際にドライバーをロードさせ動作させながら検証するのが後者という感じです。SDV と、PREfast の２つは、静的ツールで、どちらも WDK に含まれています。ツールの設計上、 SDV のほうが、PREfast よりも詳細な解析ができるようですが（と言ってもカバーしている範囲が異なるので一概には比較できないのですが）、PREfast もその名の通り手軽にチェックできますので、利用シナリオに応じて活用してください。

一方、 Driver Verifier は OS に既定でインストールされている動的なドライバー検証ツールで、カーネルモードドライバーの一般的な挙動をチェックするためのツールとして有効です。 GFlags は、Debugging Tools for Windowsに含まれていて、正確にはドライバーの検証ツールではないのですが、Global Flags を編集することができます。 Global Flags と Driver Verifierと併用することによって、メモリにタグを設定するなどができ、より詳細なログ採取や、メモリダンプファイルの解析などのトラブルシューティング時に役立ちます。

 

我々サポートも、このような使用方法をお客様へ紹介することはもちろん、問題の解析に使用することもあります。そして、実際に、これらのツールの使用によってデッドロックが潜在するコードパスや、関数の使用方法に関する問題点などが判明したというケースも沢山あるんですよ。

 

では以下に、簡単な使用方法をご紹介します。

 

①  Static Driver Verifier (SDV)

 

(1) WDK ビルド環境のウィンドウを開く

(2) ビルドしたドライバのソースファイルを含むディレクトリに移動

(3) ルールの設定を行うことができますが、全てのルールで SDV を実行するには、次のように入力します

      staticdv /rule:*

(※1 ルールに関しては、こちらに解説があります。)

(※2 コード量が多いと、解析にはかなりの時間を要します)

 

↓例として、前回登場したToaster サンプルに対して実行してみました。

 

 

 

(4) Static Driver Verifier が結果を表示して終了します。さらにその結果を UI （Static Driver Verifier Report ）で参照するには、次のように入力します

      staticdv /view

 

(5) Defects ノードが Static Driver Verifier Report に現われる場合、Defects ノードの下の任意の欠陥をダブルクリックします

 

↓ちなみに Toaster サンプルの BusEnum.sys では、下記の結果となりました。

 

 

Defects が発見されると、 マークで表示されます。今回の結果には、明示的な Defect はないようですね。

ただ、この結果を見ますと、PNPIrpCompletion のルールでは、時間が足りなかったのかタイムアウトしています。

また、pendedcompletedrequest のルールでは、メモリーがスペースアウトしていますので、正確に判定できていない可能性があります。

それなので、次のステップとしては、デフォルト値を設定しなおしてもう一度試してみるなどのアクションが考えられます。

なお、デフォルト値の設定は、%BaseDir%\Tools\sdv\data\wdm\sdv-default.xml 内の以下の値を修正することで、変更することができます。

 

SDV_SlamConfig_Timeout　規定値で2000

SDV_SlamConfig_Spaceout　規定値で400

 

(6)  その他にも分からないことがあったらヘルプファイルを参照しましょう

 Static Driver Verifier のヘルプ ファイルを参照するには、次のように入力します

      staticdv /help

 

Static Driver Verifier (SDV)　の使い方はこのような感じで非常にシンプルです。

 

参照：

- Static Driver Verifier

( https://www.microsoft.com/japan/whdc/devtools/tools/sdv.mspx )

 

次に、PREfast の使用方法ですが、SDV 同様にビルド環境で行います。

 

② PREfast

 

(1) WDK ビルド環境のウィンドウを開く

(2) ビルドしたいドライバのソースファイルを含むディレクトリに移動

(3) PREfast を実行するには、次のように入力します

      prefast build –cZ

 

↓C:\WinDDK\6001.18002\Tools\pfd\samples で実行した場合の例

 

 

 

(4) 以下のコマンドで UIから参照することができます

      prefast view

 

↓Message List では、各 Defect の一覧を確認できます。（31 個、見つかりました！）

 

 

 

↓各 Defect をダブルクリックしますと、”View Annotated Source” スクリーンに切り替わり、その Defect の詳細をコードとともに表示してくれます。この例では、「初期化してないパラメータを使っちゃだめよ」 と、指摘されたわけですね。

 

 

 

 

SDV もそうですが、PREfast のテスト結果も、多くの Warning を検出します。あくまでもツールですので、全てのシナリオを網羅しているわけではありませんし、残念ながら誤診もありますが、警告レベルを指定し直すことによってある程度の調節が可能ではあります。ただ、注意していただきたいのは、時々、「Warning だから問題ない」と言って、軽視してしまう場合をよく見かけることです。その Warning には、ドライバーセキュリティ上の重大な問題が潜んでいるかもしれません。そのため、安易に警告レベルを下げることはお勧めしません。各ツールが「なぜ」そのコードを Warning として検出したのかを十分に理解した上で、適切な判断していただきたいと思います。

 

参照：

- PREƒast for Drivers

( https://www.microsoft.com/japan/whdc/devtools/tools/prefast.mspx )

 

 

続いて、Driver Verifier と Global Flags (gflags.exe) を併せて使用する場合の設定方法を紹介します。

メモリーリークやメモリの不正アクセスに関連する問題のトラブルシューティング等に有効です。

 

③ Driver Verifier ＋ GFlags

 

■Global Flagsの設定

Global Flagsでメモリーアロケート時にタグを設定するモードに設定を行います

 

(1) Debugging Tools For Windows をインストールします

(2) [スタート] --> [Debugging Tools for Windows] --> [Global Flags] で gflags.exe を起動します

(3) [System Registry] タブを選択し、チェックを行う項目のチェックボックスをONにします

   - Enable pool tagging

   - Create user mode stack trace database

   - Create kernel mode stack trace database

   - Disable paging of kernel stacks　等

 

↓System Registry タブの設定の一例

 

 

 

(4) OK をクリックします

 

参照：

- GFlags

( https://msdn.microsoft.com/en-us/library/cc265942.aspx )

 

 

■Driver Verifier の設定

(1) [スタート] --> [ファイル名を指定して実行] --> verifier.exe を起動します

(2) [カスタム設定を作成する(コード開発者用)] を選択します

 

 

 

(3) [一覧から個別の設定を選択する] を選択します

 

 

 

(4) チェックを行う項目にチェックボックスを ON にします

 

 

 

(5) [一覧からドライバを選択する] より検証対象のドライバーを選択します

 

 

 

 

 

 

 

 

(6) OS を再起動しますと、Driver Verifier が検証を開始します

（※なお、設定を解除する場合には、再度 verifier.exe を起動して、[既存の設定を削除する]を選択します）

 

(7) 検証・デバッグ・コード修正 そしてそれを繰り返す！

 

 

以上が、手順です。（1）~（6）の設定は結構簡単ですね。

実際に重要なのは、ステップ (7) です。

 

ここでちょっと考えてみましょう。

Driver Verifier は何か問題が見つかった場合、どのように知らせてくれるのでしょうか？

「カーネルモードドライバーを実際に動作させながら検証する」とはどういうことでしょうか？

 

「検証ツール」というと、「自動的にいろいろ解析してくれて、その結果を分かりやすく UI で表示してくれるのかしら？」と想像するかもしれません。実際、SDV や PREfast などはそういった側面も持っています。しかし、Driver Verifier はちょっと違います。Driver Verifier は、不正な処理を検出すると、DRIVER_VERIFIER_DETECTED_VIOLATION (Bug Check 0xC4) などを通知し、例外処理される仕組みになっています。つまり、カーネルモードでの例外処理ですから、ブルースクリーンが発生し、メモリダンプファイルが作成されることになるわけです。（WinDBG などのカーネルデバッガーが接続されていれば、デバッガーへ制御が移ります。）つまり、問題が検出される際の挙動がどうなるかというと、検証対象のドライバーによっては、ブルースクリーンが頻発したり、ブート時の検証に引っ掛かる場合はシステムがブートできない状態になる場合があるということです。それなので、Driver Verifier が検出した問題をヒントに、一歩ずつ頑張ってデバッグを進めていくことになります。Driver Verifier とはそんなツールです。

 

参照：

- Windows 7 の Driver Verifier

( https://www.microsoft.com/japan/whdc/devtools/tools/Win7DriverVer.mspx )

- Windows Vista の Driver Verifier

( https://www.microsoft.com/japan/whdc/DevTools/tools/vistaverifier.mspx )

 

その他にも Driver Verifierについて日本語で解説している技術資料を集めてみました。

 

- Driver Verifier で検出されるエラー コードのリストの一部

( https://support.microsoft.com/kb/229903/ja )

- Driver Verifier を使用して Windows ドライバをトラブルシューティングする方法

( https://support.microsoft.com/kb/244617/ja )

- Drive Verifier ユーティリティの I/O Verification について

( https://support.microsoft.com/kb/813001/ja )

- 運用サーバーで Driver Verifier Manager を有効にする前に考慮すべき（機械翻訳ですが。。）

( https://support.microsoft.com/kb/251233/ja )

- NDIS Verifier を有効にして使用する方法

( https://support.microsoft.com/kb/266403/ja )

 

 

カーネルモードドライバーの開発の場合は、以上の 3 つが主な検証ツールとなるかと思います。

ちなみに、ユーザーモードのアプリケーションであれば、 Application Verifier (AppVerifier) もあります。（以前「ドライバーがインストールできない」という問い合わせをいただいた際に、実際、蓋を開けてみたらインストーラー側の問題ということがありました。この時、コールスタックもばっちり取って大活躍してくれたのがこの AppVerifier でした。）ここではドキュメントのみの紹介とさせていただきますが、ユーザーモードでのデバッグの際には、是非ご活用ください。

 

- Application Verifier (AppVerifier)

( https://msdn.microsoft.com/ja-jp/library/aa480483.aspx )

- Windows Application Verifier についてよく寄せられる質問

( https://www.microsoft.com/japan/windows/appcompatibility/appverifier_faq.mspx )

 

 

今日はドライバーの検証ツール＋α について触れてみましたが、いかがでしたでしょうか？

より詳細について知りたいという方は、WHDCの以下のページを見てみてください。

各ツールの一般的な紹介だけでなく、詳細なホワイトペーパーがリンクされています。様々なシナリオを想定したテスト方法や、OS毎のバージョンの違いなんかについても解説があります。またその他にも、一般的なドライバーの信頼性やセキュリティに関する文書などもありますので、是非目を通していただきたいなと思います。

 

- 検証とテスト ツール

( https://www.microsoft.com/japan/whdc/driver/tools/default.mspx )

- ドライバー用テストツール

( https://www.microsoft.com/japan/whdc/DevTools/tools/default.mspx )

 

 

これらのツールを活用していただいて、バグの早期発見＆早期治療に少しでも役立てていただければ幸いです。

 

長くなってしまいました。

私からは以上です。

それでは、また♪

 

さなえす＠そういう私も再来週には健康診断...

 

P.S.

 

今日のトピックと全然関係ないのですが、余談です。

先日WHDCのニュースレターを見ていたら、WDKのドキュメントに関するアンケート（英語）が実施されていました。

このページを見ていただいている方は、日頃 WDK のドキュメントを使用されている方が多いのではないかと思います。

もし、お時間があるようでしたら是非ご参加いただき、WDKドキュメントチームへの意見をお寄せ下さい。

（詳しくは、“Microsoft Hardware Newsletter 日本語版 (2009/3/27)” でも紹介されていますので、ご覧ください。）