こんにちは、Windows Driver Kit サポートチームです。

2019 年1 月をもちまして、弊社システム刷新の都合により、本Blog を終了いたします。

今後、同様の情報公開は、以下の情報公開専用フォーラムにて行ってまいります。

Windows Driver Kit サポートチーム フォーラム
< https://social.msdn.microsoft.com/Forums/ja-JP/home?forum=wdksupportteamja >

2009 年2 月に開始以来、多くのお客様にご覧いただき、誠にありがとうございました。

読者の皆様のビジネスに多少なりとも貢献できておりましたら幸甚です。

今後ともどうぞよろしくお願いします。

Authenticode 署名のドライバインストールのトラブルシューティングの一例をご紹介します。

特定の環境でのみ、ドライバインストールが失敗する場合、ドライバの署名の検証に失敗しているか確認するため、正常な環境と現象の発生する環境の2 パターンで以下のcertutil の出力結果を比較します。

- 手順

1. ドライバの署名に使用した証明書をご用意ください。

   既に.cer　形式の証明書がお手元にございましたら、次のステップへ進んでください。

  .cer 形式の証明書がない場合は、署名を行った環境ににてcertmgr.msc を起動していただき、署名に使用した証明書をエクスポートしてください。

   エクスポートする際は、「いいえ。秘密鍵はエクスポートしません」を選択し、「DER encoded binary X.509 (.CER)」にてエクスポートしてください。

2. 対象の環境へ証明書をコピーして、コマンドプロンプトより以下のコマンドを実行し、出力結果をテキストに保存してください。

  > certutil -verify -urlfetch <証明書のパス>

その結果、「URL の取得エラー: サーバー名またはアドレスは解決されませんでした0x80072ee7 (WinHttp: 12007 ERROR_WINHTTP_NAME_NOT_RESOLVED)」というエラーが出ている場合、ドライバの署名に使用された証明書の正常性を検証するために、認証局のURL へアクセスを試みたところ、名前解決に失敗したことを示しております。この結果、証明書は無効と判定され、ドライバのインストールにも失敗いたします。

上記のようなエラーは、一般的に、インターネットへアクセスできないオフラインの環境で発生いたします。

お手数ですが、異常端末がインターネット(上記エラーに併記されているURL) へアクセス可能な状態にしていただき、ドライバのインストールの成功するかどうかご確認ください。

なお、上記は、あくまでも初期調査の切り分けの一例のため、該当しないパターンも多くあります点は、予めご了承ください。

以上の情報がお役に立てば幸いです。

WDK サポートチーム 津田

ユーザーモードのプログラムで、クラッシュダンプでは原因がわからない問題を、問題が発生するまでの経緯をさかのぼって調べたいと思ったことはありませんか？それを実現してくれるのがTime Travel Debugging (TTD) です。TTD は、まだプレビューですが、WDK 1803 で TTD の使い方についてのLab が以下のドキュメントとして公開されました。

Time Travel Debugging - Sample App Walkthrough

< https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-walkthrough >

そこで、今回は、このLab の手順をご案内します。これにより、読者の方のデバッグの作業効率が上がれば幸いです。

手順の概要

1. 1. 失敗するプログラムのTime Travel Trace をキャプチャします。

2. 2. dx (Display Debugger Object Model Expression) コマンドを使って、Time Travel Trace に記録された例外イベントを見つけます。

3. 3. !tt (time travel) コマンドを使って、そのトレースの中の例外イベントの位置まで移動(travel) します。

4. 4. トレースのその位置から、失敗したコードまでステップ実行でさかのぼります。

5. 5. 失敗したコードで、ローカル変数を確認し、誤った値を含む変数の仮説を立てます。

6. 6. 誤った値を持つ変数のメモリアドレスを確認します。

7. 7. 疑わしい変数のアドレスに、メモリアクセス時のブレークポイントをba (Break on Access) コマンドを使ってセットします。

8. 8. g- を使って、疑われる変数へのメモリアクセスの最後の位置までさかのぼります。

9. 9. その位置、またはそれ以前のいくつかの命令が、失敗したコードフローの場所であれば、完了です。もし誤った値がほかの変数からのものであれば、別の変数にメモリアクセス時のブレークポイントをセットします。

10. 10. g- を使って、疑われる変数へのメモリアクセスの最後の位置までさかのぼります。その位置、またはそれ以前のいくつかの命令が、失敗したコードフローの場所であれば、完了です。

11. 11. この手順を、エラーを引き起こした誤った値をセットするコードが見つかるまで繰り返します。

Lab が前提とする環境

• • Windows 10 が動作するラップトップまたはデスクトップ PC (ホスト)

• • WinDbg Preview (インストール手順は、WinDbg Preview – Installation をご参照ください。概要としては、Microsoft Store のアプリを開いて “WinDbg Preview” で検索するか、< https://www.microsoft.com/store/apps/9pgjgd53tn86 > のリンクから入手します。)

• • サンプルC++ コードをビルドできる Visual Studio

今回は、例として、WinDbg を動作させるホストPC では Windows 10 1803 x64 が動作しています。Visual Studio 2017 を使用します。

1. 1. サンプルコードのビルド

ここの手順では、Visual Studio を使って、サンプルコードをビルドします。

少し経つとこのウィンドウが閉じますが、実は例外が発生しています。実際、イベントビューアーのアプリケーションログを見ると、以下のようなエラーになっています。

以降の手順では、サンプルアプリの実行を記録し、この例外がなぜ発生したのか見ていきます。

2. 2. “DisplayGreeting” サンプルのトレースの記録

ここの手順では、誤った動作を行うDisplayGreeting アプリの TTD トレースログを記録します。

サンプルアプリを起動し、TTD トレースを記録するには、以下の手順を行います。一般的な手順は、Time Travel Debugging - Record a trace のドキュメントをご参照ください。

Keyframe とは、インデックスに使われるトレース内の位置です。Keyframe は自動的に生成されます。大きなトレースファイルほど、多いKeyframe を含みます。

TTD トレースがあれば、トレースをリプレイしたり、トレースファイルを他の人と共有して協業することもできます。詳細は Time Travel Debugging - Working with Trace Files のドキュメントをご参照ください。

以降の手順では、トレースファイルを解析し、サンプルコードの問題を特定していきます。

3. 3. コードの問題特定のためのトレースファイルの解析

ここの手順では、コードの問題を特定するためにトレースファイルを解析します。

WinDbg 環境の設定

0:000> .sympath+ C:\Blog\TTD\DisplayGreeting\Debug

Symbol search path is: srv*;C:\Blog\TTD\DisplayGreeting\Debug

Expanded Symbol search path is: cache*;SRV*https://msdl.microsoft.com/download/symbols;c:\blog\ttd\displaygreeting\debug

************* Path validation summary **************

Response                         Time (ms)     Location

Deferred                                       srv*

OK                                             C:\Blog\TTD\DisplayGreeting\Debug

0:000> .reload

.........

例外の確認

(1) トレースファイルがロードされると、発生した例外の情報が表示されます。

(53dc.37ec): Break instruction exception - code 80000003 (first/second chance not available)

Time Travel Position: E:0

eax=00f71041 ebx=009d7000 ecx=77d91d40 edx=00000000 esi=00000000 edi=00000000

eip=77d91d40 esp=007cfb7c ebp=00000000 iopl=0         nv up ei ng nz na po cy

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000283

ntdll!LdrInitializeThunk:

77d91d40 8bff            mov     edi,edi

(2) dx コマンドを使って記録されたすべてのイベントをリストします。例外イベントが、それらのイベントの中にリストされます。

0:000> dx -r1 @$curprocess.TTD.Events

...

    [0x8]            : Module Loaded at position: A:0

    [0x9]            : Thread created at E:0

    [0xa]            : Exception at 97:0

    [0xb]            : Thread terminated at 114:0

...

(3) その例外イベント(上記の例では[0xa] ) をクリックして、TTD イベントについての情報を表示します。

0:000> dx -r1 @$curprocess.TTD.Events[10]

@$curprocess.TTD.Events[10]                 : Exception at 97:0

    Type             : Exception

    Position         : 97:0 [Time Travel]

    Exception        : Exception of type Hardware at PC: 0X540020

(4) Exception フィールドをクリックし、例外データの詳細をさらに確認します。

0:000> dx -r1 @$curprocess.TTD.Events[10].Exception

@$curprocess.TTD.Events[10].Exception                 : Exception of type Hardware at PC: 0X540020

    Position         : 97:0 [Time Travel]

    Type             : Hardware

    ProgramCounter   : 0x540020

    Code             : 0xc0000005

    Flags            : 0x0

    RecordAddress    : 0x0

例外データは、これがCPU によってスローされたハードウェア フォールトであることを示しています。また、0xc0000005 の例外コードが、これはアクセスバイオレーションであることも示しています。これは、一般に、アクセスしてはいけないメモリへの書き込みを行おうとしたことを示します。

0:000> dx @$curprocess.TTD.Events[10].Position.SeekTo()

Setting position: 97:0

(53dc.37ec): Break instruction exception - code 80000003 (first/second chance not available)

Time Travel Position: 97:0

@$curprocess.TTD.Events[10].Position.SeekTo()

0:000> r

eax=00000000 ebx=009d7000 ecx=974872f8 edx=010e3a74 esi=00f71041 edi=00f71041

eip=00540020 esp=007cfd74 ebp=00520055 iopl=0         nv up ei pl zr na pe nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246

00540020 0000            add     byte ptr [eax],al          ds:002b:00000000=??

レジスタの出力から、スタックとベースポインタが2つの全く異なるアドレスを指していることがわかります。

これは、スタック破壊 － おそらく関数がリターンしてスタックが破壊されたように見受けられます。これを確認するために、CPU ステートが壊れる前までさかのぼり、スタック破壊が起きた時を見つけられるか見てみる必要があります。

ローカル変数の確認とブレークポイントのセット

トレース上の失敗のポイントでは、エラー処理コードの本当の原因よりも数ステップ後であることが一般的です。タイムトラベルで、命令をさかのぼり、本当の原因を調べます。

0:000> t-

Time Travel Position: 96:41

eax=00000000 ebx=009d7000 ecx=974872f8 edx=010e3a74 esi=00f71041 edi=00f71041

eip=00540020 esp=007cfd74 ebp=00520055 iopl=0         nv up ei pl zr na pe nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246

00540020 0000            add     byte ptr [eax],al          ds:002b:00000000=??

0:000> t-

Time Travel Position: 96:40

eax=00000000 ebx=009d7000 ecx=974872f8 edx=010e3a74 esi=00f71041 edi=00f71041

eip=00f716bd esp=007cfd70 ebp=00520055 iopl=0         nv up ei pl zr na pe nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246

DisplayGreeting!main+0x4d:

00f716bd c3              ret

0:000> t-

Time Travel Position: 96:3A

eax=0000004c ebx=009d7000 ecx=974872f8 edx=010e3a74 esi=00f71041 edi=00f71041

eip=00f716b5 esp=007cfcbc ebp=007cfd6c iopl=0         nv up ei pl nz na po nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202

DisplayGreeting!main+0x45:

00f716b5 33c0            xor     eax,eax

上記コマンド出力の通り、UI メニューのオプション(Home リボンの、Step Into Back コマンド) の代わりに、コマンドライン(t-) を使うこともできます。

なお、今回の例では、コードがとても小さなサンプルのため、コード上で問題を見つけるのは簡単ですが、何百行もあるコードや、何十ものサブルーチンがある場合、ここでの方法は、問題を見つけるのに時間を節約する役に立ちます。

TTD とブレークポイント

ブレークポイントを使うことは、興味のある何らかのイベントのコード実行で停止するための一般的な方法です。TTD は、記録されたトレースの中で、ブレークポイントをセットして、そのブレークポイントにヒットするまで時間をさかのぼらせることができます。

メモリアクセスのブレークポイント

あるメモリの場所にアクセスされたらブレークするブレークポイントをセットするには、ba (break on access) コマンドを以下のシンタックスで使用します。

任意の時点で4 つのデータ ブレークポイントのみセットできる点にご留意ください。また、データが正しくアラインされていること(Word は2, Dword は4, Quadword は0 または8)。

ベースポインタへのメモリアクセスのブレークポイントのセット

(1) ベースポインタへの書き込みメモリアクセスにブレークポイントをセットします。ここでのebp は、0x007cfd6c です。

(2) [View] の [Breakpoints] をクリックし、上記がセットされていることを確認します。

(3) [Home] の[Go Back] をクリックし、ブレークポイントがヒットするまでさかのぼります。

0:000> g-

Breakpoint 0 hit

Time Travel Position: 7A:4BB

eax=00f75b96 ebx=009d7000 ecx=007c0052 edx=007cfd6e esi=00f71041 edi=00f71041

eip=01064707 esp=007cfbf4 ebp=007cfc34 iopl=0         nv up ei pl nz na po nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202

ucrtbased!common_tcscpy_s<wchar_t>+0x187:

01064707 8b55f8          mov     edx,dword ptr [ebp-8] ss:002b:007cfc2c=007cfd6e

(4) [View] の[Locals] をクリックします。Locals ウィンドウで、source が全てのテキストを持っているのに対し、変数destination が、メッセージの一部のみを持っています。この情報が、スタックが破壊されたという考えの裏付けになります。

(5) ここでスタックがどのコードをアクティブにしているか見てみます。[View] の[Stack] をクリックします。

Microsoft が提供している wcscpy_s() 関数がこのようなコードバグを持っているとは考えにくいため、スタックをさらに見ていきます。スタックでは、DisplayGreeting!main が、DisplayGreeting!GetCppConGreeting を呼び出しています。今回のような小さなサンプルでは、コードを開いて誤りを見つけるのは非常に簡単です。しかし、より大きく複雑なプログラムで使えるように、さらに調べるための新たなブレークポイントをセットします。

GetCppConGreeting 関数へのアクセスのブレークポイントのセット

0:000> dx &DisplayGreeting!GetCppConGreeting

&DisplayGreeting!GetCppConGreeting                 : 0xf71560 [Type: void (__cdecl*)(wchar_t *,unsigned int)]

    [Type: void __cdecl(wchar_t *,unsigned int)]

0:000> ba r4 0xf71560

0:000> !tt 0

Setting position to the beginning of the trace

Setting position: E:0

(53dc.37ec): Break instruction exception - code 80000003 (first/second chance not available)

Time Travel Position: E:0

eax=00f71041 ebx=009d7000 ecx=77d91d40 edx=00000000 esi=00000000 edi=00000000

eip=77d91d40 esp=007cfb7c ebp=00000000 iopl=0         nv up ei ng nz na po cy

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000283

ntdll!LdrInitializeThunk:

77d91d40 8bff            mov     edi,edi

0:000> g

Breakpoint 0 hit

Time Travel Position: 7A:8C

eax=007cfd08 ebx=009d7000 ecx=007cfd08 edx=00f71041 esi=00f71041 edi=00f71041

eip=00f71561 esp=007cfcac ebp=007cfd6c iopl=0         nv up ei pl nz ac pe nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216

DisplayGreeting!GetCppConGreeting+0x1:

00f71561 8bec            mov     ebp,esp

0:000> g-u

Time Travel Position: 7A:89

eax=007cfd08 ebx=009d7000 ecx=007cfd08 edx=00f71041 esi=00f71041 edi=00f71041

eip=00f71697 esp=007cfcb4 ebp=007cfd6c iopl=0         nv up ei pl nz ac pe nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000216

DisplayGreeting!main+0x27:

00f71697 e827faffff      call    DisplayGreeting!ILT+190(?GetCppConGreetingYAXPA_WIZ) (00f710c3)

サイズをさらに見ると、message は75 文字で、終端文字を含めると76 文字あります。

または、sizeof(greeting) をsize(greeting) に変更する必要があります。

Source ウィンドウでのブレークポイントのセット

0:000> !tt 0

Setting position to the beginning of the trace

Setting position: E:0

(53dc.37ec): Break instruction exception - code 80000003 (first/second chance not available)

Time Travel Position: E:0

eax=00f71041 ebx=009d7000 ecx=77d91d40 edx=00000000 esi=00000000 edi=00000000

eip=77d91d40 esp=007cfb7c ebp=00000000 iopl=0         nv up ei ng nz na po cy

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000283

ntdll!LdrInitializeThunk:

77d91d40 8bff            mov     edi,edi

0:000> g

Breakpoint 0 hit

Time Travel Position: 7A:43

eax=010e4738 ebx=009d7000 ecx=00000001 edx=00f77550 esi=00f71041 edi=00f71041

eip=00f7167c esp=007cfcbc ebp=007cfd6c iopl=0         nv up ei pl nz na po nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202

DisplayGreeting!main+0xc:

00f7167c 6a64            push    64h

変数 greeting へのアクセスのブレークポイントのセット

この調査を行う別の方法として、疑わしい変数にブレークポイントをセットして、どのコードがそれらを変更しているか確認する方法があります。例えば、GetCppConGreeting メソッドの変数greeting にブレークポイントをセットしてみます。ここでは、以前のセクションでセットしたブレークポイントがセットされたままとします。

このトレースでは、greeting は 0x7cfd08 のアドレスにあります。

0:000> ba w4 0x7cfd08

0:000> !tt 0

Setting position to the beginning of the trace

Setting position: E:0

(53dc.37ec): Break instruction exception - code 80000003 (first/second chance not available)

Time Travel Position: E:0

eax=00f71041 ebx=009d7000 ecx=77d91d40 edx=00000000 esi=00000000 edi=00000000

eip=77d91d40 esp=007cfb7c ebp=00000000 iopl=0         nv up ei ng nz na po cy

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000283

ntdll!LdrInitializeThunk:

77d91d40 8bff            mov     edi,edi

0:000> g

Breakpoint 0 hit

Time Travel Position: 55:309

eax=974874b8 ebx=009d7000 ecx=010e4cd4 edx=00f71740 esi=00000000 edi=00f71041

eip=01010613 esp=007cfd08 ebp=007cfd1c iopl=0         nv up ei ng nz na pe nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000286

ucrtbased!try_get_FlsGetValue+0x3:

01010613 8bec            mov     ebp,esp

他にも、トレースの最後まで移動して、逆に戻ることで、メモリへ書き込んだ、トレース上の最後のポイントに移動することができます。

TTD.Memory オブジェクトでのメモリアクセスの表示

トレース内のメモリがどの時点でアクセスされたか確認するために、TTD.Memory オブジェクトと dx コマンドを使う方法があります。

(1) dx コマンドで配列 greeting を確認します。

このトレースでは、0x7cfd08 にgreeting があります。

(2) dx コマンドで、そのアドレスから4 バイト分へのRead/Write アクセスを見てみます。

0:000> dx -r1 @$cursession.TTD.Memory(0x7cfd08,0x7cfd0c, "rw")

@$cursession.TTD.Memory(0x7cfd08,0x7cfd0c, "rw")                

    [0x0]           

    [0x1]           

    [0x2]           

    [0x3]           

    [0x4]           

(3) [0x*] のリンクをクリックして、メモリアクセスが発生した時の詳細情報を表示します。

0:000> dx -r1 @$cursession.TTD.Memory(0x7cfd08,0x7cfd0c, "rw")[5]

@$cursession.TTD.Memory(0x7cfd08,0x7cfd0c, "rw")[5]                

    EventType        : MemoryAccess

    ThreadId         : 0x37ec

    UniqueThreadId   : 0x2

    TimeStart        : 55:37C [Time Travel]

    TimeEnd          : 55:37C [Time Travel]

    AccessType       : Read

    IP               : 0x759bdfff

    Address          : 0x7cfd08

    Size             : 0x4

    Value            : 0x1010fd6

0:000> dx @$cursession.TTD.Memory(0x7cfd08,0x7cfd0c, "rw")[5].TimeStart.SeekTo()

Setting position: 55:37C

(53dc.37ec): Break instruction exception - code 80000003 (first/second chance not available)

Time Travel Position: 55:37C

@$cursession.TTD.Memory(0x7cfd08,0x7cfd0c, "rw")[5].TimeStart.SeekTo()

0:000> dx -r1 @$cursession.TTD.Memory(0x7cfd08,0x7cfd0c, "rw").Last()

@$cursession.TTD.Memory(0x7cfd08,0x7cfd0c, "rw").Last()                

    EventType        : MemoryAccess

    ThreadId         : 0x37ec

    UniqueThreadId   : 0x2

    TimeStart        : 84:10DB [Time Travel]

    TimeEnd          : 84:10DB [Time Travel]

    AccessType       : Read

    IP               : 0x1055c94

    Address          : 0x7cfd0a

    Size             : 0x2

    Value            : 0x45

上記の内容が、ユーザーモードのプログラムを開発される方のお役に立てば幸いです。

WDK サポートチーム 津田

Hyper-V 仮想マシンに仮想 COM ポート経由のカーネルデバッガ接続方法では、レスポンスが遅く感じられたことはありませんか？今回は、Hyper-V 仮想マシンへのネットワーク経由のカーネルデバッガ接続方法をご案内します。これにより、読者の方のデバッグの作業効率が上がれば幸いです。

今回は、例として、WinDbg を動作させるホストPC では Windows 10 1803 x64、カーネルデバッガを接続される仮想マシンではWindows 10 1803 x86 が動作しています。ホストPC 側には、WDK 10 1803 がインストールされているものとします。仮想マシンは、第一世代のものを使用しています。

1. 1. ホストPC と仮想マシンをネットワーク接続します。

仮想スイッチは、以下の図のように、以下の3点を満たす必要があります。

・外部ネットワーク

・「管理オペレーティングシステムにこのネットワークアダプターの共有を許可する」にチェック

・VLAN ID を無効

この仮想スイッチ(図の例では、External という名前にしています) を、仮想マシンのネットワークアダプタ―に設定しています。

2. 2. ホストPC のIP アドレスを確認します。

ホストPC 側でコマンドプロンプトを起動し、ipconfig を実行してIP アドレスを確認します。

仮想マシン側でコマンドプロンプトを起動し、ping< ホストPC のIP アドレス> を実行して、Ping が通ることを確認します。

3. 3. 仮想マシン上に kdnet.exe と VerifiedNICList.xml をコピーします。

Kdnet.exe とVerifiedNICList.xml は、WDK 10 のインストールフォルダの下のDebuggers\<architecture> フォルダにあります。<architecture> フォルダは、x86, x64, arm のいずれかですが、仮想マシンの CPU アーキテクチャに一致するものを使用します。今回の例では、仮想マシンが x86 なので、ホストPC 上のC:\Program Files (x86)\Windows Kits\10\Debuggers\x86 のものを使用します。これらを、仮想マシン上の任意のフォルダにコピーします。今回は C:\kdnet フォルダを作成して、そこにコピーします。

4. 4. 仮想マシン上で管理者権限のコマンドプロンプトを実行し、以下のコマンドを実行します。

5. 5. ホストPC 上で管理者権限のコマンドプロンプトを実行し、以下のコマンドを実行します。

コピー＆ペーストするためには、以下の図のように、仮想マシンの[表示] の[拡張セッション] にチェックが入っていることを確認してください。

上記で windbg を実行すると、以下のようにファイアウォールのブロックを解除することを求められるので、ドメイン、プライベート、パブリックの3 つすべてにチェックを入れて、[アクセスを許可する] をクリックします。

WinDbg が接続を待機します。

6. 6. 仮想マシンを再起動します。

手順4 の仮想マシン上のコマンドプロンプトで、そのまま以下を実行します。

すると、ホストPC 側のWinDbg に以下の通りブレークインしてきます。

• • 参考文献

Setting Up Network Debugging of a Virtual Machine - KDNET

< https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-network-debugging-of-a-virtual-machine-host >

Setting Up KDNET Network Kernel Debugging Automatically

< https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-network-debugging-connection-automatically >

Kdnet.exe が、ホストPC がWindows 7 以降、ターゲットPC が Windows 8 以降であれば使えるとの記載があります。

The computer that runs the debugger is called the host computer, and the computer being debugged is called the target computer. The host computer must be running Windows 7 or later, and the target computer must be running Windows 8 or later.

Debug Drivers - Step by Step Lab (Sysvad Kernel Mode)

< https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debug-universal-drivers--kernel-mode- >

上記の内容が、ドライバを開発される方のお役に立てば幸いです。

WDK サポートチーム 津田

WDK for Windows 10, version 1803 がリリースされました。

以下のドキュメントの手順に沿って、Windows 10 x64 version 1803 にインストールしてみます。

Download the Windows Driver Kit (WDK)

< https://docs.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk >

1. 1. Visual Studio 2017 をインストール

以下の3 つのエディションのいずれかをインストールします。

·         Download Visual Studio Community 2017

·         Download Visual Studio Professional 2017

·         Download Visual Studio Enterprise 2017

インストールする際、[ワークロード] タブで[C++ によるデスクトップ開発] にチェックを入れます。これにより、WDK 1803 のインストール前に、必要なWindows 10 SDK 1803 をインストールできます。(以下の図の右側に表示されていることからもわかります。)

なお、この画面の通りにWindows 10 SDK (10.0.17134.0) (つまり1803) がインストールされるためには、Visual Studio 2017 のバージョンは、2018 年5 月7 日(米国時間。日本時間の場合は8 日) にリリースされた 15.7.0 以降である必要がある点にご注意ください。

既存のVS2017 環境にWDK 1803 をインストールしたい場合は、例えば、以下を行います。

1. 1. VS2017 を起動し、[ヘルプ]-[更新プログラムの確認] でVisual Studio 2017 を 15.7.0 以上に更新します。

以下のようにWindows 10 SDK 10.0.17134 をインストールしてくれます。

2. 2. [ツール]-[ツールと機能の取得] で確認するとインストールされていることがわかります。

2. 2. WDK のインストール

以下のリンクからインストールします。

·         Download WDK for Windows 10, version 1803

インストールの完了後の以下の画面で、[Install Windows Driver Kit Visual Studio extension] にチェックを入れたまま、[Close] をクリックします。

VSIX インストーラーのウィンドウが以下のように表示されます(Visual Studio 2017 のエディションは、1. でご自身が選んだものになります) ので、[インストール] をクリックします。

インストールが完了すると、以下のように表示されます。

3. 3. 参考資料

l  更新内容

WDK for Windows 10, version 1803 の更新内容については以下に記載されています。

What's new in Windows 10, version 1803

< https://docs.microsoft.com/ja-jp/windows-hardware/get-started/what-s-new-in-windows >

What's new in driver development

< https://docs.microsoft.com/en-us/windows-hardware/drivers/what-s-new-in-driver-development >

l  既知の問題

本バージョンのWDK の既知の問題については、以下のフォーラムのスレッドに記載されております。

Hardware development kits for Windows 10, Version 1803 (April 2018)

< https://social.msdn.microsoft.com/Forums/en-US/b205fc0e-3f9e-4852-9a2a-367106d7831c/hardware-development-kits-for-windows-10-version-1803-april-2018?forum=wdk >

l  サンプル

サンプルは、以下の GitHub のページで、画面右上の緑色のボタン [Clone or download] の [Download ZIP] でダウンロードしてください。

Driver samples for Windows 10

< https://github.com/Microsoft/Windows-driver-samples >

上記の内容が、ドライバを開発される方のお役に立てば幸いです。

WDK サポートチーム 津田

NTSTATUS や、GetLastError() で得た Win32 エラーコードの定義がすぐにわからなくて困ったことはありますか？

今回は、そのような方のために、エラーコードの定義を探すのに便利なErr.exe をご紹介します。

1. 1. 入手手順

1. 1. Err.exe は、以下のサイトからダウンロードしていただけます。

Microsoft Exchange Server Error Code Look-up

< https://www.microsoft.com/en-us/download/details.aspx?id=985 >

2. 2. ダウンロードしたErr.EXE は自己解凍プログラムのため、実行すると、解凍先フォルダを求められます。

3. 3. 解凍先を指定して解凍すると、以下のファイルが確認できます。このErr.exe が目的のツールです。

2. 2. 使い方

使い方は、コマンドプロンプトを起動し、「err.exe< エラーコード>」を実行するだけです。

今回は、例として、0xe000023c というエラーコードで実行してみます。

上記のように、setupapi.h に定義されたERROR_NOT_AN_INSTALLED_OEM_INF であるということがわかりました。

WDK/SDK のヘッダファイルのある C:\Program Files (x86)\Windows Kits\10\Include\{バージョン番号} のフォルダ内を、e000023c で検索しても見つかりませんが、上記のようにErr.exe で見つかったERROR_NOT_AN_INSTALLED_OEM_INF で検索すると、setupapi.h に以下のように定義されていることがわかります。

このような定義となっている場合でも、上記のツールを使うことで、エラーコードの定義を探していただくことができます。

より詳細な使い方や制限事項は、以下の弊社ブログをご参考にしていただければ幸いです。

• • 参考文献

重箱の隅のデバッグ(2) – エラーの意味を探る

< https://blogs.msdn.microsoft.com/japan_platform_sdkwindows_sdk_support_team_blog/2012/05/17/2/ >

上記の内容が、ドライバやアプリケーションを開発される方のお役に立てば幸いです。

WDK サポートチーム 津田

今回は、ファイルシステムミニフィルタ ドライバのサンプル Minispy File System Minifilter Driver をご紹介します。

このサンプルは、システム上の任意の I/O を監視しログに記録する方法を示すサンプルです。

Minispy は、ユーザーモード アプリケーションの minispy.exe とカーネルモード ドライバの minispy.sys で構成されています。Minispy.sys が、様々なI/O に対応するコールバックを、フィルタマネージャに登録します。このコールバックが、システム上の任意のI/O を記録します。ユーザーが、この記録された情報を要求した時に、minispy.sys がminispy.exe にその情報を渡し、minispy.exe が画面上に出力、またはファイルにログしていきます。

あるデバイス上のI/O を監視するためには、minispy.exe を使って、明示的に minispy.sys をそのデバイスにアタッチする必要があります。あるデバイス上の I/O の監視をやめる場合もminispy.exe を使います。

今回は、このサンプルをWindows 10 (1709) x86 にインストールして、C ドライブ上で監視した I/O の情報がコマンドプロンプトやファイル上に出力されるところをお見せしたいと思います。サンプルをビルドする、開発側のPC はWindows 10 (1709) x64 にVisual Studio 2017 とWDK for Windows 10 Version 1709 がインストールされています。

1. サンプルの入手

Minispy File System Minifilter Driver サンプルは、以下のサイトの右側の緑色の [Clone or Download] ボタンを押すと表示される [Download ZIP] ボタンでWindows-driver-samples-master.zipをダウンロードすると、Windows-driver-samples-master\filesys\miniFilter\minispy のフォルダにあります。

https://github.com/Microsoft/Windows-driver-samples

2. サンプルのビルド

このフォルダのminispy.sln を、Visual Studio 2017 で開きます。Filter の方がminispy.sys、User の方が minispy.exe のプロジェクトです。

[ソリューション ‘minispy’] を右クリックして [構成マネージャー] をクリックします。

今回は、[アクティブソリューション構成] を [Debug]、[アクティブ ソリューション プラットフォーム] を [Win32] とします。

また、minispy.exe 側でVisual C++ Runtime (VCRUNTIME14D.dll) のインストールを省略するために、User フォルダの下のプロジェクトminispy を右クリックして [プロパティ] を開き、[構成プロパティ]-[C/C++]-[コード生成]-[ランタイム ライブラリ] を [マルチスレッド デバッグ(/MTd)] に変更します。

[ソリューション ‘minispy’] を右クリックして[ソリューションのリビルド] をクリックします。

これで、minispy.sys とminispy.exe ができます。

次のステップに必要なファイルと場所は以下です。

3. サンプルのインストールと動作確認の準備

上記のファイルをWindows 10 (1709) x86 の環境にコピーします。例えば、C:\minispy というフォルダを作って、そこに置きます。minispy.inf を右クリックして、[インストール] をクリックすれば、インストールできます。

インストールしても、以下のようにまだこのサンプルドライバはロードされていません。(fltmc.exe の使い方の詳細は、以前の記事「fltmc.exe の使い方」<https://blogs.msdn.microsoft.com/jpwdkblog/2013/02/27/fltmc-exe/> をご参照ください。)

そこで、以下のコマンドでこのサンプルドライバをロードします。

これにより、以下のようにminispy がロードされています。ただ、まだインスタンス数が 0 であることから、ボリュームへのアタッチはされていません。

なお、上記まで行わないと、minispy.exe の実行時に以下のエラーが出ます。

上記のminispy.sys のロードを行うことで、minispy.exe を以下のように実行できるようになります。

最後の行の指示通り、Enter を押すと、コマンドが入力できるようになります。

? を入力して、どのようなコマンドがあるか見てみます。

オプションを表にすると以下の通りです。

コマンドモードについては以下の操作ができます。

・Enter を押せばコマンドモードに入ります。

・go またはg を入力すれば、コマンドモードから抜けます。

・exit を入力すれば、minispy.exe を終了します。

ここまでを理解したら、コマンドモードのまま、以下を実行して、C ドライブにアタッチしてみましょう。

実際、/l オプションを実行したら、C ドライブにアタッチできている(Status がAttached) と出力されます。

4. サンプルの動作確認

以上で準備ができたので、動作確認として、C ドライブ上で監視した I/O の情報がコマンドプロンプトやファイル上に出力されるところをお見せしたいと思います。

コマンドモードのまま、g を入力して、スクリーン上にログを出力します。

上記は、出力のヘッダの部分と、最初のログの一行を抜粋しています。実際には、全部一行で表示できるようにコマンドプロンプトの設定を調整するか、ファイルに出力して、ヘッダの行とログの行の各項目の対応関係がわかるようにした方が、わかりやすいと思います。

上記の例を表にすると、以下のようになります。

続いて、ファイルに出力してみます。/f の後にファイル名を指定して実行後、g を入力します。

ファイル出力をやめるために、Enter を実行してコマンドモードにし、/f を入力します。(ファイル出力を止めない状態でログを開こうとすると、別のプロセスが使用中というエラーになります。)

ログファイルを開いてみます。以下のように上記と同じログがありつつも、コマンドプロンプト(スクリーン) 上に表示されるよりも多く記録されていました。

上記の内容が、ファイルシステムミニフィルタドライバを開発される方のお役に立てば幸いです。

WDK サポートチーム 津田

今回は、Process Monitor で OS 起動時のログを採取する手順である、Enable Boot Logging オプションを実行する手順をご案内します。

Process Monitor については、以前「Process Monitor」の記事でもご案内しておりますので、ご参考ください。こちらの記事の手順では、OS 起動後にログオンしてからシャットダウンを開始する前までの任意のタイミングをカバーしています。(その間に、Process Monitor を実行し、現象を再現させ、ログを取得することを前提にしています。) 対しまして、今回の手順は、Process Monitor のEnable Boot Logging を設定した後、OS を再起動しますが、その起動中から、明示的にログ採取を完了させるまでログを取得し続けます。そのため、OS 起動中だけでなく、シャットダウン時のログも取得できます。

[手順]

1. 1. 以下のサイトからProcess Monitor をダウンロードします。

Process Monitor v3.50

https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

Download Process Monitor (981 KB)

2. 2. ダウンロードしたProcessMonitor.zip を問題が発生している環境の任意のフォルダーに置き、unzipします。

3. 3. Procmon.exe を実行します。

4. 4. 管理者権限が必要であるため、権限が不足している場合は、昇格ダイアログが表示されます。

5. 5. 管理者権限となるよう昇格ダイアログを操作します。(ユーザ名とパスワードの入力や昇格の[はい]・[いいえ]の選択など)

6. 6. Process Monitor の起動後、自動的にファイルシステム、レジストリ、プロセスおよびスレッドの活動の記録を開始し始めます。(起動オプションに/NoConnect を指定すると自動ログ機能は動作しません。)

7. 7. 虫眼鏡のアイコン([Capture] ボタン) をクリックし、記録を停止します。下記の画面の上部の赤い四角で囲った部分が [Capture] ボタンです。これは、まだ現象を再現させる前の段階のため、現時点では、活動を記録する必要がないためです。

8. 8. 記録を停止すると、虫眼鏡のアイコン([Capture] ボタン) に×がつきます。

9. 9. メニューの[Edit] - [Clear Display] （または下記の赤枠の[Clear] ボタン）をクリックし、記録されたログを削除します。下記の画面の左下にNo events (capture disabled) と表示されています。

10. 10. メニューの[Options] –[Enable Boot Logging] をクリックします。

11. 11. 以下のダイアログで、[Generate thread profiling events] のチェックは不要です。そのまま [OK] をクリックします。

12. 12. Procmon.exe を終了し、OS を再起動します。(再起動後に必要な再現手順があれば実施します。) OS 再起動後からログ採取が開始されます。

13. 13. OS が再起動したらログインし、Procmon.exe を実行します。

14. 14. 以下のダイアログが表示されるので、[はい] をクリックし、ログを保存します。デフォルトでは、Bootlog.PML というファイル名となりますが、任意の場所に保存できます。

[補足: シャットダウン時のログが取りたい場合]

シャットダウン時のログが取りたい場合は、上記の手順13. でログインした後、Procmon.exe を実行せず、そのままOS を再起動します。その再起動後に、Procmon.exe を実行し、手順 14. でログを保存します。

上記の内容が、お役に立てば幸いです。

WDK サポートチーム 津田