Beyond the Basics - Windows Debugging & Troubleshooting Blog https://docs.microsoft.com/archive/blogs/debug_and_troubleshoot/feed.xml Platform Escalation Service at Microsoft Japan Wed, 17 Apr 2019 03:25:24 GMT en-US hourly 1 シャドウコピーは実際にどれぐらいのページプールを消費していますか？ https://docs.microsoft.com/archive/blogs/debug_and_troubleshoot/3 Fri, 11 Jun 2010 02:35:00 GMT https://blogs.technet.microsoft.com/debug_and_troubleshoot/2010/06/11/3/

 

こんにちは、プラットフォームサポートの徐です。

 

今回は、シャドウコピーとページプールの枯渇について話したいと思います。

 

  

Windows Server 2003 ファイルサーバ上で共有フォルダのシャドウ コピー（Shadow Copy for Shared Folder）機能を有効にした場合、既定で各対象ボリュームに最大 64 世代のシャドウコピーが作成される可能性があります。

 

これらのシャドウコピーは、作成時に System Volume Information フォルダの下にファイルとして保存され、[以前のバージョン] タブから実際に参照される際にシャドウコピーボリュームとしてファイルシステムにマウントされますが、その時にページプールなどシステムリソースを消費することがあります。

 

多数のユーザより異なるシャドウコピーを参照した場合には、大量のシャドウコピーボリュームをマウントする必要があり、これが原因でページプールなどのシステムリソースが圧迫される可能性があります。

  

  

なお、ファイルサーバ上で共有フォルダのシャドウコピー機能をプランニングする時に、ページプール、非ページプール及び仮想メモリの消費について考えるべきポイントが、以下の技術情報で紹介されています。

 

Scalability Factors for Shadow Copies

https://technet.microsoft.com/en-us/library/cc755419(WS.10).aspx

 

 

また、関連する修正モジュールとして KB913648 が公開されており、このモジュールを適用することで、大量のシャドウコピーボリュームのマウントが原因でページプールが大量に消費される問題を抑えるために、利用可能なページプールのサイズが一定の閾値（既定で 80MB ）を下回った場合、すべてのシャドウコピーボリュームが一時的にディスマウントされ、ページプールを開放させる機能が実装されます。

 

A new Volume Shadow Copy Service update is now available that fixes various Volume Shadow Copy Service problems in Windows Server 2003

https://support.microsoft.com/kb/913648

  

 

ページプールが大量に消費された場合、マウントされているシャドウコピーボリュームは、実際にどれぐらいのページプールを消費しているかを確認することは容易なことではありません。

しかしながら、運用時のシャドウコピーボリュームによるページプールの消費状況を把握することは、シャドウコピーの負荷分散の必要性の判断及び負荷分散の方法選びに必要な情報です。

 

以下に、シャドウコピー機能が有効しているファイルサーバ環境でページプールの枯渇が発生している場合、シャドウコピーボリュームの一時的にディスマウントされる機能を利用して、シャドウコピーは実際にどれぐらいのページプールを消費しているかを確認する方法を紹介します。この方法は、修正モジュール KB913648 の適用が前提となります。

 

１．調査対象のファイルサーバで VSS トレースログ機能を有効します。詳細については KB887013 に記載があります。
 

      (1). Notepad.exe を起動し、下の "---" の内側の文字列をコピーし、メモ帳に貼り付けます。
      ------------------------
      Windows Registry Editor Version 5.00

      [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Debug\Tracing]
      "TraceFile"="c:\\trace.txt"
      "TraceLevel"=dword:ffffffff
      "TraceEnterExit"=dword:00000001
      "TraceToFile"=dword:00000001
      "TraceToDebugger"=dword:00000001
      "TraceFileLineInfo"=dword:00000001
      "TraceForceFlush"=dword:00000000
      ------------------------

  

     (2). ペーストした文字列の 4 行目の "c:\\trace.txt" の c の部分を シャドウコピー対象ボリュームではないボリュームに変更します。すなわち、トレースの格納先は共有フォルダのシャドウコピーが有効になっていないボリュームを選択して下さい。
  

     (3). 変更後の文字列を保存し、保存されたテキストファイルの拡張子を.reg に変更します。
 

     (4). 手順 (3). で拡張子を変更したファイルをダブルクリックし、システムのレジストリに設定を適用します。
  

     (5). システムを再起動します。

    

     以上の手順で、VSS トレースログが 手順 1-(2). で指定したファイルにテキストで記録されるようになります。

  

      How to enable the Volume Shadow Copy service's debug tracing features in Microsoft Windows Server 2003

       https://support.microsoft.com/kb/887013

   

   

２．定期的に VSS トレースログファイル（手順1-(2)で指定したVSSトレースログファイル）を開き、ページプール不足によるシャドウコピーボリュームのディスマウント処理が発生したかどうかを確認します。

      検索キーワード: CVsSoftwareProvider::DismountAllSnapshots  -> このキーワードが存在する場合、シャドウコピーのディスマウント処理が発生したことを示します。

 

 

３．ページプール不足によるシャドウコピーボリュームのディスマウント処理が発生したことを確認できたら、次に以下のキーワードで検索し、シャドウコピー作成時のページプール使用量の変化を確認します。

      検索キーワード１: "available page pool before dismount xxxx"  -> xxxx が、ディスマウント前に利用可能なページプール サイズを示します。

      検索キーワード2: "available page pool after deletion yyyy"       -> yyyy が、ディスマウント後に利用可能なページプール サイズを示します。

      検索キーワード3: "difference zzzz"                                  　　　 -> zzzz が、ディスマウント処理により開放されたページプールサイズを示します。

 

 

注意：

1．xxxx/yyyy/zzzz の単位は KB (キロバイト)です。

 

2．上記のキーワードは各シャドウコピーボリュームごとに記録されるため、複数のシャドウコピーボリュームがディスマウントされた場合には、上記キーワードが複数回記録される場合があります。

 

3．手順１で VSS トレースログ機能を有効にした場合、時間が経つにつれてVSS機能動作するたびにトレースログが出力されるため、VSS トレースログファイルのサイズが段々大きくなり、ディスクの空き容量を圧迫する可能性があります。そのため、手順２で現時点までの VSS トレースログファイルからディスマウント処理の発生が確認できなかった場合、その時点で VSS トレースログファイルを手動で削除することをお勧めします。同じ名前の新しい VSS トレースログファイルがまた自動で作成されますので、その後に発生するディスマウント処理の確認に特に影響ありませんが、思わず VSS トレースログファイルのサイズが極端に増えるリスクを防げます。

  

  

次の例のように、

シャドウコピーのディスマウント処理の開始と完了の間に出力されたすべての "difference zzzz" の zzzz の合計値は、シャドウコピーボリュームのマウントにより消費されていたページプールの合計サイズであり、シャドウコピーボリュームのディスマウント処理より開放されたページプールの合計サイズでもあります。

 

また、初回目の "available page pool before dismount xxxx" の中の xxxx 値は、シャドウコピーのディスマウント処理が作動した時点での利用可能なページプールのサイズを示します。

 

また、最後回目の "available page pool after deletion yyyy" の中の yyyy 値は、シャドウコピーのディスマウント処理が完了した時点での利用可能なページプールのサイズを示します。

 

 

例：

// シャドウコピーのディスマウント処理の開始

[0134695156,0x0001fc:0x0c40:0x4845352e] ENTER {CVsSoftwareProvider::DismountAllSnapshots}:

              :

// 初回目の以下のログの中の xxxx 値は、シャドウコピーのディスマウント処理が作動した時点での利用可能なページプールのサイズ

[0134695156,0x0001fc:0x0c40:0x4845352e] softprv\src\dismount.cxx(0401): CVsSoftwareProvider::DismountAllSnapshots: available page pool before dismount 81936   ß-- ここは、初回目の xxxx 値, 利用可能なページプールは81,936KBでした。

              :

[0134695171,0x0001fc:0x0c40:0x4845352e] softprv\src\dismount.cxx(0420): CVsSoftwareProvider::DismountAllSnapshots: available page pool after deletion 85436

[0134695171,0x0001fc:0x0c40:0x4845352e] softprv\src\dismount.cxx(0421): CVsSoftwareProvider::DismountAllSnapshots: difference 3500

              :

              :

[0134699046,0x0001fc:0x0c40:0x4845352e] softprv\src\dismount.cxx(0401): CVsSoftwareProvider::DismountAllSnapshots: available page pool before dismount 394868

              :

[0134699046,0x0001fc:0x0c40:0x4845352e] softprv\src\dismount.cxx(0420): CVsSoftwareProvider::DismountAllSnapshots: available page pool after deletion 396472

[0134699046,0x0001fc:0x0c40:0x4845352e] softprv\src\dismount.cxx(0421): CVsSoftwareProvider::DismountAllSnapshots: difference 1604

              :

              :

 [0134699062,0x0001fc:0x0c40:0x4845352e] softprv\src\dismount.cxx(0401): CVsSoftwareProvider::DismountAllSnapshots: available page pool before dismount 396372

              :

// 最後回目の以下ののログの中の yyyy 値は、シャドウコピーのディスマウント処理が完了した時点での利用可能なページプールのサイズ

[0134699062,0x0001fc:0x0c40:0x4845352e] softprv\src\dismount.cxx(0420): CVsSoftwareProvider::DismountAllSnapshots: available page pool after deletion 398024 ß-- ここは、最後回目の yyyy 値, 利用可能なページプールは 398,024KB でした。

[0134699062,0x0001fc:0x0c40:0x4845352e] softprv\src\dismount.cxx(0421): CVsSoftwareProvider::DismountAllSnapshots: difference 1652

:

// シャドウコピーのディスマウント処理の完了

[0134699062,0x0001fc:0x0c40:0x4845352e] EXIT  {CVsSoftwareProvider::DismountAllSnapshots}: hr: 0x00000000

 

 

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」

 

]]> X64 の TrapFrame は信用できない？ https://docs.microsoft.com/archive/blogs/debug_and_troubleshoot/x64-trapframe Fri, 04 Jun 2010 04:30:00 GMT https://blogs.technet.microsoft.com/debug_and_troubleshoot/2010/06/04/x64-trapframe/ こんにちは、八木です。

今日はデバッガに表示されるちょっと気になるメッセージについて書きたいと思います。

 X64のメモリダンプをデバッガで開き、トラップフレームを表示させると、こんな注意書きが表示されます。

 9: kd> .trap 0xfffff880023ae150
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff880023ae418 rbx=0000000000000000 rcx=fffffa807c446788
rdx=00000000c0000240 rsi=0000000000000000 rdi=0000000000000000
rip=0000000000000000 rsp=fffff880023ae2e8 rbp=0000000000000000
r8=0000000000000000  r9=0000000000000000 r10=fffffa80323d5b00
r11=0000000000000002 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
00000000'00000000 ??              ???

 トラップフレームは、STOP エラーが発生したり割り込みが発生した場合など、その時点の CPU のレジスタの値をスタックメモリに保存したもので、メモリダンプの解析を行う際にはとても重要な情報ですが、メッセージが示すようにトラップフレームに保存されたレジスタ値の幾つかは現象発生時の値では無いのです（x64の場合）。

 

でも、いったいどのレジスタの値が正しくて、どの値が正しく無いのかについては、どこにも示されていません。デバッガのヘルプファイルにも書かれていなかったと思います。

 

そこで、実際にやってみることにしました。

 

ライブのカーネルデバッグで x64 ターゲットに接続し、レジスタの値をデバッガで無理やり書き換えていきます。

 

現在のレジスタの内容。

1: kd> r
rax=0000000000003001 rbx=fffff880009bf180 rcx=0000000000000001
rdx=0000000000000010 rsi=0000000000026160 rdi=0000000000001032
rip=fffff80001679f60 rsp=fffff880009d2ac8 rbp=0000000000000000
r8=fffffa80024db000  r9=000000000000000f r10=000000000168e325
r11=fffff880009d29b0 r12=fffff880009d2b00 r13=fffffa8002b92d00
r14=fffffa8002b32200 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
nt!DbgBreakPointWithStatus:
fffff800'01679f60 cc              int     3

 

各レジスタに値を入れていきます。（後で判別しやすい値を選んで設定しておきます。）

1: kd> r rax=1111111111111111
1: kd> r rbx=2222222222222222
1: kd> r rcx=3333333333333333
1: kd> r rdx=4444444444444444
1: kd> r rsi=5555555555555555
1: kd> r rdi=6666666666666666
1: kd> r rip=7777777777777777
1: kd> r rsp=8888888888888888
1: kd> r rbp=9999999999999999
1: kd> r r8 =aaaaaaaaaaaaaaaa
1: kd> r r9 =bbbbbbbbbbbbbbbb
1: kd> r r10=cccccccccccccccc
1: kd> r r11=dddddddddddddddd
1: kd> r r12=eeeeeeeeeeeeeeee
1: kd> r r13=f0f0f0f0f0f0f0f0
1: kd> r r14=f1f1f1f1f1f1f1f1
1: kd> r r15=f2f2f2f2f2f2f2f2

 

書き換えた後のレジスタの内容：

1: kd> r
rax=1111111111111111 rbx=2222222222222222 rcx=3333333333333333
rdx=4444444444444444 rsi=5555555555555555 rdi=6666666666666666
rip=7777777777777777 rsp=8888888888888888 rbp=9999999999999999
r8=aaaaaaaaaaaaaaaa  r9=bbbbbbbbbbbbbbbb r10=cccccccccccccccc
r11=dddddddddddddddd r12=eeeeeeeeeeeeeeee r13=f0f0f0f0f0f0f0f0
r14=f1f1f1f1f1f1f1f1 r15=f2f2f2f2f2f2f2f2
iopl=0         nv up ei pl nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
77777777'77777777 ??              ???

 

この状態から、デバッガをリリースすると、（命令ポインタ rip = 7777777777777777 が不正なアドレスなので） STOP エラーが発生します。

 

その後保存された memory.dmp をデバッガで開くと、下記の通りエラー発生前に設定したはずの値が幾つか無くなっています。（本来の値が残っているものを赤で示しています。）

 

0: kd> .trap 0xfffff880009d2900

NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=1111111111111111 rbx=0000000000000000 rcx=3333333333333333
rdx=4444444444444444 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800016816ac rsp=fffff880009d2a98 rbp=9999999999999999
 r8=aaaaaaaaaaaaaaaa  r9=bbbbbbbbbbbbbbbb r10=cccccccccccccccc
r11=dddddddddddddddd r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up di ng nz na pe nc
nt!KiExceptionDispatch+0x22c:
fffff800'016816ac 48cf            iretq

 

この結果から、

トラップフレームに保存されるのは、

rax, rcx, rdx, rbp, r8, r9, r10, r11

保存されないのは、

rbx, rsi, rdi, rip, r12, r13, r14, r15

ということのようです。

 

ここでお気づきの方もいらっしゃると思いますが、どうやらトラップフレームに保存されているレジスタの値は、関数呼び出し上の規約（Calling Conventions）の中で揮発的（Volatile）なレジスタとして定義されているもののようです。（rbp は nonvolatile ですが、ここでは特別のようです。）

 

実際にトラップフレームを作成するコードも見てみることにします。

 

デバッガから !idt と入力すると割り込みディスパッチテーブルが表示されます。

0: kd> !idt

Dumping IDT:

00:     fffff800016b8c40 nt!KiDivideErrorFault
01:     fffff800016b8d40 nt!KiDebugTrapOrFault
02:     fffff800016b8f00 nt!KiNmiInterrupt      Stack = 0xFFFFF80001465000

03:     fffff800016b9280 nt!KiBreakpointTrap
04:     fffff800016b9380 nt!KiOverflowTrap
05:     fffff800016b9480 nt!KiBoundFault
06:     fffff800016b9580 nt!KiInvalidOpcodeFault
07:     fffff800016b97c0 nt!KiNpxNotAvailableFault
08:     fffff800016b9880 nt!KiDoubleFaultAbort  Stack = 0xFFFFF80001463000

09:     fffff800016b9940 nt!KiNpxSegmentOverrunAbort
0a:     fffff800016b9a00 nt!KiInvalidTssFault
0b:     fffff800016b9ac0 nt!KiSegmentNotPresentFault
0c:     fffff800016b9c00 nt!KiStackFault
0d:     fffff800016b9d40 nt!KiGeneralProtectionFault
0e:     fffff800016b9e80 nt!KiPageFault
10:     fffff800016ba240 nt!KiFloatingErrorFault
11:     fffff800016ba3c0 nt!KiAlignmentFault
12:     fffff800016ba4c0 nt!KiMcheckAbort       Stack = 0xFFFFF80001467000

 

ここで、ページフォールトをハンドルするルーチン nt!KiPageFault を見てみます。

0: kd> u nt!KiPageFault
nt!KiPageFault:
fffff800'016b9e80 55              push    rbp
fffff800'016b9e81 4881ec58010000  sub     rsp,158h
fffff800'016b9e88 488dac2480000000 lea     rbp,[rsp+80h]
fffff800'016b9e90 c645ab01        mov     byte ptr [rbp-55h],1
fffff800'016b9e94 488945b0        mov     qword ptr [rbp-50h],rax
fffff800'016b9e98 48894db8        mov     qword ptr [rbp-48h],rcx
fffff800'016b9e9c 488955c0        mov     qword ptr [rbp-40h],rdx
fffff800'016b9ea0 4c8945c8        mov     qword ptr [rbp-38h],r8
0: kd> u
nt!KiPageFault+0x24:
fffff800'016b9ea4 4c894dd0        mov     qword ptr [rbp-30h],r9
fffff800'016b9ea8 4c8955d8        mov     qword ptr [rbp-28h],r10
fffff800'016b9eac 4c895de0        mov     qword ptr [rbp-20h],r11
fffff800'016b9eb0 f685f000000001  test    byte ptr [rbp+0F0h],1
fffff800'016b9eb7 7474            je      nt!KiPageFault+0xad (fffff800'016b9f2d)
fffff800'016b9eb9 0f01f8          swapgs
fffff800'016b9ebc 654c8b142588010000 mov   r10,qword ptr gs:[188h]
fffff800'016b9ec5 6683bdf000000033 cmp     word ptr [rbp+0F0h],33h

 

まさしく、揮発的（Volatile）なレジスタと rbp がスタックに保存されている様子が確認できました。

 

結論

x64 のトラップフレームで信用できるレジスタは

rax, rcx, rdx, rbp, r8, r9, r10, r11

です。

]]> Pool が枯渇した場合の調査方法 https://docs.microsoft.com/archive/blogs/debug_and_troubleshoot/pool Thu, 22 Apr 2010 03:52:00 GMT https://blogs.technet.microsoft.com/debug_and_troubleshoot/2010/04/22/pool/  

こんにちは。プラットフォーム サポートの大貫です。

 

今回は、Pool が枯渇する現象のトラブル シューティングについてお話したいと思います。

Pool の説明やトラブル シューティングなどについては、以下のブログでも紹介されています。

 

- リソース不足について - 第 1 回

- リソース不足について - 第 2 回

- リソース不足について - 第 3 回

 

この内容を踏まえて、Pool が枯渇している環境をデバックしてみます。調査する環境は、2 つあります。環境は Windows 7 です。

まずは、ひとつ目の環境から。

 

- 環境 1 – Paged Pool 枯渇

 

 まずは、!vm コマンドを実行します。この結果から Paged Pool の枯渇が確認でき、かなりの回数の Pool の確保が失敗しています。

 

1: kd> !vm 5

*** Virtual Memory Usage ***

Physical Memory: 524174 ( 2096696 Kb)

Page File: \??\C:\pagefile.sys

Current: 2096696 Kb Free Space: 2096692 Kb

Minimum: 2096696 Kb Maximum: 6290088 Kb

Available Pages: 425421 ( 1701684 Kb)

ResAvail Pages: 484901 ( 1939604 Kb)

Locked IO Pages: 0 ( 0 Kb)

Free System PTEs: 2680 ( 10720 Kb)

Modified Pages: 4455 ( 17820 Kb)

Modified PF Pages: 4401 ( 17604 Kb)

NonPagedPool Usage: 11089 ( 44356 Kb)

NonPagedPool Max: 385022 ( 1540088 Kb)

PagedPool 0 Usage: 425939 ( 1703756 Kb)

PagedPool 1 Usage: 2408 ( 9632 Kb)

PagedPool 2 Usage: 59 ( 236 Kb)

PagedPool 3 Usage: 45 ( 180 Kb)

PagedPool 4 Usage: 93 ( 372 Kb)

PagedPool Usage: 428544 ( 1714176 Kb) <<< 大きな値を示しています。

PagedPool Maximum: 523264 ( 2093056 Kb)

********** 34553 pool allocations have failed ********** <<< 34553 回 Pool の確保に失敗しています。

Shared Commit: 6605 ( 26420 Kb)

Special Pool: 0 ( 0 Kb)

Shared Process: 1692 ( 6768 Kb)

PagedPool Commit: 428544 ( 1714176 Kb)

Driver Commit: 1857 ( 7428 Kb)

Committed pages: 516797 ( 2067188 Kb)

Commit limit: 1048348 ( 4193392 Kb)

Terminal Server Memory Usage By Session:

Session ID 0 @ 8fe87000:

Paged Pool Usage: 2740K

Commit Usage: 5296K

Session ID 1 @ 8fe9a000:

Paged Pool Usage: 13908K

Commit Usage: 16492K

 

では、なぜ Pool が枯渇しているのでしょうか？

どの Tag で大量に Paged Pool が確保されているかを確認すると、Tag "MSKK" で Paged Pool が確保されていることが確認できます。

 

1: kd> !poolused 4

Sorting by Paged Pool Consumed

Pool Used:

NonPaged Paged

Tag Allocs Used Allocs Used

MSKK 0 0 415447 1701670912 UNKNOWN pooltag 'MSKK', please update pooltag.txt

CM31 0 0 5555 24899584 Internal Configuration manager allocations , Binary: nt!cm

CM25 0 0 2026 8814592 Internal Configuration manager allocations , Binary: nt!cm

CIcr 0 0 1295 2990224 Code Integrity allocations for image integrity checking , Binary: ci.dll

MmRe 0 0 401 2765280 ASLR relocation blocks , Binary: nt!mm

ClfI 0 0 19 1782880 CLFS Log marshal buffer lookaside list , Binary: clfs.sys

MmSt 0 0 664 1268752 Mm section object prototype ptes , Binary: nt!mm

VmbK 51 403064 8 876544 Volume Manager Extension , Binary: volmgrx.sys

 

次に、この Tag がどのドライバで確保されているのかを確認します。

確認するには、”!for_each_module” コマンドを使い、各モジュールのアドレス領域から "MSKK" タグを検索します。

 

1: kd> !for_each_module s -a @#Base @#End "MSKK"

83184218 4d 53 4b 4b 67 00 46 00-69 00 6c 00 65 00 49 00 MSKKg.F.i.l.e.I.

9196b324 4d 53 4b 4b 68 00 10 00-00 6a 01 ff 15 10 90 96 MSKKh....j......

 

2 箇所で MSKK という文字列が確認できました。

では、本当に上記箇所で Tag "MSKK" を使用して、Pool を確保しているのかを確認しましょう。

最初のアドレスを見ると、以下のような結果になり Pool を確保している形跡は見当たりません。

 

1: kd> u 83184218-1

nt!KdpBreakpointTable+0x1ff:

83184217 004d53 add byte ptr [ebp+53h],cl

8318421a 4b dec ebx

8318421b 4b dec ebx

8318421c 67004600 add byte ptr [bp+0],al

83184220 69006c006500 imul eax,dword ptr [eax],65006Ch

83184226 49 dec ecx

83184227 006e00 add byte ptr [esi],ch

8318422a 66006f00 add byte ptr [edi],ch

 

では、次のアドレスを見てみます。すると、引数を 3 つスタックに積み、関数を呼び出していることが確認できます。

 

1: kd> u 9196b324-1

SIoctl+0x4323:

9196b323 684d534b4b push 4B4B534Dh

9196b328 6800100000 push 1000h

9196b32d 6a01 push 1

9196b32f ff1510909691 call dword ptr [SIoctl+0x2010 (91969010)]

9196b335 4e dec esi

9196b336 75eb jne SIoctl+0x4323 (9196b323)

9196b338 cc int 3

9196b339 eb07 jmp SIoctl+0x4342 (9196b342)

 

呼び出している関数を確認してみます。すると、呼び出しているのは、ExAllocatePoolWithTag 関数であることが確認できます。

 

1: kd> ln poi(91969010)

(82f37bab) nt!ExAllocatePoolWithTag | (82f38660) nt!ExDeferredFreePool

Exact matches:

nt!ExAllocatePoolWithTag (_POOL_TYPE, unsigned long, unsigned long)

ExAllocatePoolWithTag 関数は、以下のように定義されています。

PVOID   ExAllocatePoolWithTag(

IN POOL_TYPE  PoolType,

IN SIZE_T  NumberOfBytes,

IN ULONG  Tag               

);

 

そうすると、引数は以下のように渡されていることがわかります。

第一引数 1

第二引数 0x1000

第三引数 4B4B534Dh

 

DDK のドキュメントを確認すると、POOL_TYPE は以下のように定義されていますので、第一引数では、Paged Pool が指定されていることが確認できます。

 

typedef enum _POOL_TYPE {

NonPagedPool,

PagedPool,

NonPagedPoolMustSucceed,

DontUseThisType,

NonPagedPoolCacheAligned,

PagedPoolCacheAligned,

NonPagedPoolCacheAlignedMustS

} POOL_TYPE;

 

第二引数では、サイズとして 0x1000 バイト確保するように引数が渡されています。

第三引数は Tag です。では、Tag を確認します。すると、"MSKK" という文字列であることが確認できます。

 

1: kd> .formats 4B4B534Dh

Evaluate expression:

Hex: 4b4b534d

Decimal: 1263227725

Octal: 11322651515

Binary: 01001011 01001011 01010011 01001101

Chars: KKSM

Time: Tue Jan 12 01:35:25 2010

Float: low 1.33251e+007 high 0

Double: 6.24117e-315

 

では、この処理をしているモジュールを確認します。アドレス 9196b324 が含まれることが分かっているので、この領域を含むドライバを出力します。

 

1: kd> lmva 9196b324

start end module name

91967000 9196f000 SIoctl (no symbols)

Loaded symbol image file: SIoctl.sys

Image path: SIoctl.sys

Image name: SIoctl.sys

Timestamp: Mon Apr 12 18:37:08 2010 (4BC2E9C4)

CheckSum: 000106CF

ImageSize: 00008000

Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

 

この結果から、SIoctl.sys が Paged Pool を確保していることが確認できます。この場合は、このモジュールの製造元に確認していただく必要があり、なぜ、こんなに確保するのかなどを確認するのか、問題があれば修正することで問題は解決です。

  

次に、2 つめの環境を Debug してみます。

 

- 環境 2 – NonPaged Pool 枯渇

 

まずは、何はともあれ、!vm コマンドを実行します。この結果からみると、NonPaged Pool が大きく消費されているように見えます。

 

1: kd> !vm 5

*** Virtual Memory Usage ***

Physical Memory: 524174 ( 2096696 Kb)

Page File: \??\C:\pagefile.sys

Current: 2096696 Kb Free Space: 1996300 Kb

Minimum: 2096696 Kb Maximum: 6290088 Kb

Available Pages: 71341 ( 285364 Kb)

ResAvail Pages: 124674 ( 498696 Kb)

Locked IO Pages: 0 ( 0 Kb)

Free System PTEs: 23357 ( 93428 Kb)

Modified Pages: 1919 ( 7676 Kb)

Modified PF Pages: 1831 ( 7324 Kb)

NonPagedPool Usage: 384704 ( 1538816 Kb) <<<< 非常に大きくなっている

NonPagedPool Max: 385022 ( 1540088 Kb)

********** Excessive NonPaged Pool Usage *****

PagedPool 0 Usage: 37001 ( 148004 Kb)

PagedPool 1 Usage: 2297 ( 9188 Kb)

PagedPool 2 Usage: 291 ( 1164 Kb)

PagedPool 3 Usage: 231 ( 924 Kb)

PagedPool 4 Usage: 264 ( 1056 Kb)

PagedPool Usage: 40084 ( 160336 Kb)

PagedPool Maximum: 523264 ( 2093056 Kb)

********** 196 pool allocations have failed ********** <<<< Pool の確保も失敗している

Shared Commit: 6286 ( 25144 Kb)

Special Pool: 0 ( 0 Kb)

Shared Process: 1536 ( 6144 Kb)

PagedPool Commit: 40100 ( 160400 Kb)

Driver Commit: 1813 ( 7252 Kb)

Committed pages: 740898 ( 2963592 Kb)

Commit limit: 1048348 ( 4193392 Kb)

Terminal Server Memory Usage By Session:

Session ID 0 @ 9008b000:

Paged Pool Usage: 3620K

Commit Usage: 6176K

Session ID 1 @ 90092000:

Paged Pool Usage: 15680K

Commit Usage: 18272K

 

では、どの Tag で消費しているのか確認します。NonPaged Pool が枯渇しているので、NonPaged Pool でソートします。この結果から、Tag "Thre" で NonPaged Pool が大量に確保されていることが確認できます。

 

1: kd> !poolused 2

Sorting by NonPaged Pool Consumed

Pool Used:

NonPaged Paged

Tag Allocs Used Allocs Used

Thre 1908328 1419794592 0 0 Thread objects , Binary: nt!ps

nVsC 519 1474176 0 0 UNKNOWN pooltag 'nVsC', please update pooltag.txt

Pool 5 1156680 0 0 Pool tables, etc.

Mm 9 595712 3 88 general Mm Allocations , Binary: nt!mm

EtwB 71 577960 6 135200 Etw Buffer , Binary: nt!etw

netv 2065 323664 1 128 UNKNOWN pooltag 'netv', please update pooltag.txt

:

:

 

では、なぜ、こんなに大量に Tag "Thre" で NonPaged Pool が確保されるのでしょうか？

まず、Tag "Thre" は何をしめすものなのでしょうか？ !Poolused コマンドの結果にありますように、Tag "Thre" は Thread Object を示します。ということは、大量に Thread が作られているということになります。

 

次に、Tag "Thre" で確保された Pool のサンプルを取得してみます。

 

1: kd> !poolfind Thre 0

Scanning large pool allocation table for Tag: Thre

Scanning large pool allocation table for Tag: Thre (8a957000 : 8aa57000)

*89bc1b48 size: 2d8 previous size: 68 (Allocated) Thre (Protected)

*8a140a60 size: 2e8 previous size: 180 (Allocated) Thre (Protected)

*8a625180 size: 2e8 previous size: 60 (Allocated) Thre (Protected)

*9dd7c178 size: 2e8 previous size: a8 (Allocated) Thre (Protected)

*9dd7c460 size: 2e8 previous size: 2e8 (Allocated) Thre (Protected)

:

:

*82945000 size: 2e8 previous size: 0 (Allocated) Thre (Protected)

*82945460 size: 2e8 previous size: 178 (Allocated) Thre (Protected)

*82945748 size: 2e8 previous size: 2e8 (Allocated) Thre (Protected)

*82945a30 size: 2e8 previous size: 2e8 (Allocated) Thre (Protected)

*82945d18 size: 2e8 previous size: 2e8 (Allocated) Thre (Protected)

*82946000 size: 2e8 previous size: 0 (Allocated) Thre (Protected)

:

:

 

KTHREAD 構造体は、"Thre" タグで確保された Pool 内に存在します。なので、適当な Thread の KTHREAD 構造体がどのプールにあるかを確認することで、プールの先頭からのオフセットを計算することができます。例として、以下の Thread を確認します。

 

1: kd> !THREAD 8ab94030

THREAD 8ab94030 Cid 0564.0568 Teb: 7ffde000 Win32Thread: fe9ab4e8 WAIT: (WrUserRequest) UserMode Non-Alertable

8ab8a458 SynchronizationEvent

Not impersonating

DeviceMap 8f072fc8

Owning Process 8ab897f0 Image: explorer.exe

Attached Process N/A Image: N/A

Wait Start TickCount 90686 Ticks: 354 (0:00:00:05.531)

Context Switch Count 12622

UserTime 00:00:00.484

KernelTime 00:00:01.093

Win32 Start Address 0x00c2a8df

Stack Init 94393fd0 Current 94393ba0 Base 94394000 Limit 94391000 Call 0

Priority 10 BasePriority 8 UnusualBoost 0 ForegroundBoost 2 IoPriority 2 PagePriority 5

ChildEBP RetAddr Args to Child

94393bb8 82ebfb15 8ab94030 82f7df08 82f7ad20 nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])

94393bf0 82ebe403 8ab940f0 8ab94030 8ab8a458 nt!KiSwapThread+0x266 (CONV: fastcall)

94393c18 82eb82cf 8ab94030 8ab940f0 00000000 nt!KiCommitThreadWait+0x1df (CONV: stdcall)

94393c90 97870d75 8ab8a458 0000000d 00000001 nt!KeWaitForSingleObject+0x393 (CONV: stdcall)

94393cec 97870e10 000024ff 00000000 00000001 win32k!xxxRealSleepThread+0x1d7 (FPO: [Non-Fpo]) (CONV: stdcall)

94393d08 9782bd56 000024ff 00000000 00000001 win32k!xxxSleepThread+0x2d (FPO: [Non-Fpo]) (CONV: stdcall)

94393d1c 97861eba 000024ff 00000000 0006fd30 win32k!xxxRealWaitMessageEx+0x12 (FPO: [Non-Fpo]) (CONV: stdcall)

94393d2c 82e9442a 0006fd44 772d64f4 badb0d00 win32k!NtUserWaitMessage+0x14 (FPO: [0,0,4]) (CONV: stdcall)

94393d2c 772d64f4 0006fd44 772d64f4 badb0d00 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 94393d34)

0006fd44 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])

 

!Pool コマンドで、プールのアドレスを計算します。

 

1: kd> !pool 8ab94030 2

Pool page 8ab94030 region is Nonpaged pool

*8ab94000 size: 2e8 previous size: 0 (Allocated) *Thre (Protected)

Pooltag Thre : Thread objects, Binary : nt!ps

 

上記の結果を用いることで、KTHREAD 構造体のオフセットが確認できます。Pool の先頭のアドレスが 8ab94000、KTHREAD 構造体のアドレスが 8ab94030 です。なので、以下の計算でオフセットが計算できます。

 

1: kd> ? 8ab94030 - 8ab94000

Evaluate expression: 48 = 00000030

 

KTHREAD 構造体は、プールの先頭から +0x30 バイトに始まります。

これを踏まえ、Pool のサンプルからいくつかの KTHREAD 構造体を確認すると以下のような結果がでます。

 

1: kd> !thread 82943d18+30

THREAD 82943d48 Cid 12ce80.60ae30 Teb: 00000000 Win32Thread: 00000000 TERMINATED

Not impersonating

DeviceMap 9805fec8

Owning Process 8947ea58 Image: TestApp.exe

Attached Process N/A Image: N/A

Wait Start TickCount 61686 Ticks: 29354 (0:00:07:38.656)

Context Switch Count 5

UserTime 00:00:00.000

KernelTime 00:00:00.000

Win32 Start Address 0x00401000

Stack Init 0 Current 9b6cbbf8 Base 9b6cc000 Limit 9b6c9000 Call 0

Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5

1: kd> !thread 82945460+30

THREAD 82945490 Cid 12ce80.60ae64 Teb: 00000000 Win32Thread: 00000000 TERMINATED

Not impersonating

DeviceMap 9805fec8

Owning Process 8947ea58 Image: TestApp.exe

Attached Process N/A Image: N/A

Wait Start TickCount 61686 Ticks: 29354 (0:00:07:38.656)

Context Switch Count 4

UserTime 00:00:00.000

KernelTime 00:00:00.000

Win32 Start Address 0x00401000

Stack Init 0 Current 9baebbf8 Base 9baec000 Limit 9bae9000 Call 0

Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5

 

Thread は終了していることを考えると、TestApp.exe が Thread Handle を Close していないということが考えられます。

TestApp.exe を確認します。Handle Count が非常に大きいです。

 

1: kd> !process 8947ea58 0

PROCESS 8947ea58 SessionId: 1 Cid: 12ce80 Peb: 7ffdf000 ParentCid: 09dc

DirBase: 7ee534c0 ObjectTable: 9be74bb8 HandleCount: 1907884.

Image: TestApp.exe

 

このプロセスで開いている Handle を確認すると、大量の Thread Handle があることが確認できます。

 

1: kd> !handle 0 2 8947ea58

PROCESS 8947ea58 SessionId: 1 Cid: 12ce80 Peb: 7ffdf000 ParentCid: 09dc

DirBase: 7ee534c0 ObjectTable: 9be74bb8 HandleCount: 1907884.

Image: TestApp.exe

Handle table at 9bfaf490 with 1907884 entries in use

0004: Object: 93a7b0c0 GrantedAccess: 00000003 Entry: 8ea37008

Object: 93a7b0c0 Type: (8928c7c8) Directory

ObjectHeader: 93a7b0a8 (new version)

0008: Object: 8a7cc038 GrantedAccess: 00100020 Entry: 8ea37010

Object: 8a7cc038 Type: (89324f78) File

ObjectHeader: 8a7cc020 (new version)

000c: Object: 8a8f26a0 GrantedAccess: 001f0003 Entry: 8ea37018

Object: 8a8f26a0 Type: (8931e330) Event

ObjectHeader: 8a8f2688 (new version)

:

:

74acdc: Object: f850bd48 GrantedAccess: 001fffff Entry: f649b9b8

Object: f850bd48 Type: (8928c1e8) Thread

ObjectHeader: f850bd30 (new version)

74ace0: Object: f850ba60 GrantedAccess: 001fffff Entry: f649b9c0

Object: f850ba60 Type: (8928c1e8) Thread

ObjectHeader: f850ba48 (new version)

74ace4: Object: f850b778 GrantedAccess: 001fffff Entry: f649b9c8

Object: f850b778 Type: (8928c1e8) Thread

ObjectHeader: f850b760 (new version)

 

この環境で確認すると、1907864 個の Thread Object がわかりました。これらの Handle を Thread Object としてデコードすると、ほとんどが終了している Thread です。

よって、TestApp.exe が Thread Handle を Close してないことが原因になるので、アプリケーションの開発元に確認することで問題は解決です。

 

 

このように、Pool の問題はドライバが単独で大きく Pool を使用している場合、ほかの処理によって OS が使用している Pool が大量に確保される場合などがあり、状況によって調査の方針などを考える必要があります。

この確認を行うことによって、Pool の問題の切り分けも可能になるかと思います。

今後の、問題解決にぜひお役立てください。

 

]]> x64 のデバッグについて https://docs.microsoft.com/archive/blogs/debug_and_troubleshoot/x64 Wed, 07 Apr 2010 05:43:00 GMT https://blogs.technet.microsoft.com/debug_and_troubleshoot/2010/04/07/x64/  

こんにちは、プラットフォーム サポートの近藤です。

 

今回は、最近良く見る x64 コードのデバッグについてお話します。

 

 

- x64 呼出規約について

 

x64 上では、全ての呼び出しが従来の FASTCALL に似た呼出規約が用いられています。ここでは呼出規約の詳細は説明しませんが (興味ある方は記事末尾の参考資料をご覧ください)、x64 アーキテクチャで増えたレジスタを多く使用するようになっています。引数に関しましては、基本的に 4 つ目の引数までが順に rcx、rdx、r8、r9 レジスタで渡され、残りはスタックに保存されます。このように、多くの場合引数がレジスタで渡されているため、デバッグ時には注意が必要です。

 

 

では、実際の動きを見てみましょう。

今回は下記テスト プログラムをデバッグしながら進めていきます。

 

=================================

__declspec(noinline)

void func6(DWORD64 a, DWORD64 b, DWORD64 c, DWORD64 d, DWORD64 e, DWORD64 f)

{

        printf("Func6: 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x\n", a, b, c, d, e, f);

        return;

}

 

__declspec(noinline)

void func3(DWORD64 a, DWORD64 b, DWORD64 c)

{

        DWORD64 d = 0x40;

        DWORD64 e = 0x50;

        DWORD64 f = rand();

 

        printf("Func3: 0x%x 0x%x 0x%x\n", a, b, c);

 

        func6(0x10,0x20,0x30,d,e,f);

 

        return;

}

 

int _tmain(int argc, _TCHAR* argv[])

{

        DWORD64 a = 1;

        DWORD64 b = 2;

        DWORD64 c = rand();

       

        printf("Calling Func3\n");

        func3(a, b, c);

 

        return 0;

}

==================================

 

コンパイラによる最適化を抑えるため、__declspec(noinline) を使用し、引数にもランダムな数字を渡しています。

 

 

まずは func3 が呼ばれた瞬間です。

 

0:000> kb

RetAddr           : Args to Child                                                           : Call Site

00000001`3f7c10cc : 00000001`3f7c21f0 00000000`00000000 000007ff`fffde000 00000000`000000fe : testProgram!func3

00000001`3f7c1292 : 00000000`00000000 000000dc`b1cca995 00000000`00000000 00000000`00000000 : testProgram!wmain+0x2c

00000000`7789f56d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : testProgram!__tmainCRTStartup+0x11a

00000000`779d3281 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd

00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d

 

func3 には、"0x1" "0x2" "0x29"、の 3 つの引数が渡されていますが、ご覧の通り、'kb' コマンドを実行しても、引数は正常に表示されません。これは引数がスタックではなく、レジスタに保存されているためです。

 

0:000> r

rax=000000000000000e rbx=0000000000000029 rcx=0000000000000001

rdx=0000000000000002 rsi=0000000000000000 rdi=0000000000000001

rip=000000013f7c1040 rsp=000000000031f898 rbp=0000000000000000

r8=0000000000000029  r9=00000000001771ae r10=0000000000000000

r11=0000000000000246 r12=0000000000000000 r13=0000000000000000

r14=0000000000000000 r15=0000000000000000

iopl=0         nv up ei pl nz na po nc

cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206

testProgram!func3:

00000001`3f7c1040 48895c2408      mov     qword ptr [rsp+8],rbx ss:00000000`0031f8a0={testProgram!`string' (00000001`3f7c21f0)}

 

 

次に、func6 を呼んだ瞬間です。

 

0:000> kb

RetAddr           : Args to Child                                                           : Call Site

00000001`3f7c1092 : 00000001`3f7c21d8 00000000`00000001 00000000`00000002 00000000`00000029 : testProgram!func6

00000001`3f7c10cc : 00000000`00000029 00000000`00000000 000007ff`fffde000 00000000`000000fe : testProgram!func3+0x52

00000001`3f7c1292 : 00000000`00000000 000000dc`b1cca995 00000000`00000000 00000000`00000000 : testProgram!wmain+0x2c

00000000`7789f56d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : testProgram!__tmainCRTStartup+0x11a

00000000`779d3281 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd

00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d

 

 

引数として、"0x10" "0x20" "0x30" "0x40" "0x50" "0x4823" を渡しています。レジスタとスタックを見ますと、第 5 と 第 6 引数のみスタックに保存されていることが確認できます。

 

0:000> r

rax=0000000000000014 rbx=0000000000004823 rcx=0000000000000010

rdx=0000000000000020 rsi=0000000000000000 rdi=0000000000000029

rip=000000013f7c1000 rsp=000000000031f858 rbp=0000000000000000

r8=0000000000000030  r9=0000000000000040 r10=0000000000000000

r11=0000000000000246 r12=0000000000000000 r13=0000000000000000

r14=0000000000000000 r15=0000000000000000

iopl=0         nv up ei pl nz na po nc

cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206

testProgram!func6:

00000001`3f7c1000 4883ec48        sub     rsp,48h

 

0:000> dps @rsp La

00000000`0031f858  00000001`3f7c1092 testProgram!func3+0x52

00000000`0031f860  00000001`3f7c21d8 testProgram!`string'

00000000`0031f868  00000000`00000001

00000000`0031f870  00000000`00000002

00000000`0031f878  00000000`00000029

00000000`0031f880  00000000`00000050 << 第 5 引数

00000000`0031f888  00000000`00004823 << 第 6 引数

00000000`0031f890  00000000`00000001

00000000`0031f898  00000001`3f7c10cc testProgram!wmain+0x2c

00000000`0031f8a0  00000000`00000029

 

 

さて、ここでスタック上の第 5 引数の前に、0x20 バイトの領域があることに気づくと思います。00000000`0031f860 ～ 00000000`0031f880 の領域です。

 

00000000`0031f858  00000001`3f7c1092 << func3 への戻り値

00000000`0031f860  00000001`3f7c21d8

00000000`0031f868  00000000`00000001

00000000`0031f870  00000000`00000002

00000000`0031f878  00000000`00000029

00000000`0031f880  00000000`00000050 << 第 5 引数

 

ここは "home space" と呼ばれる空間であり、第 1 から第 4 引数を入れることのできる領域です。この領域は、呼び出した関数が引数を取らなくても用意されます。尚、x64 の場合、'kb' コマンドで表示されるのは関数への引数ではなく、このホームスペースの値となります。

 

ホーム スペースは呼び出し側が必ず用意しますが、残念ながら、ここの使用は呼び出し先次第であり、必ずしも引数が保存されるわけではありません。デバッグビルドなどの場合は、プロローグコードの最初に渡された引数をこのホーム スペースにコピーしますが、今回の例ではリリース ビルドのため、func3 内にあった printf 関数の引数が残っています。注意していただきたいのは、このコピーを呼び出し先が行うことです。呼び出し元は、必ずレジスタを使用して引数を渡します。

 

// リリース ビルドの場合

0:000> u testprogram!func6

testProgram!func6:

00000001`3f7c1000 4883ec48        sub     rsp,48h

00000001`3f7c1004 488b442478      mov     rax,qword ptr [rsp+78h]

00000001`3f7c1009 ba10000000      mov     edx,10h

00000001`3f7c100e 488d0d9b110000  lea     rcx,[testProgram!`string' (00000001`3f0f21b0)]

00000001`3f7c1015 4889442430      mov     qword ptr [rsp+30h],rax

00000001`3f7c101a 448d4a20        lea     r9d,[rdx+20h]

00000001`3f7c101e 448d4210        lea     r8d,[rdx+10h]

00000001`3f7c1022 48c744242850000000 mov   qword ptr [rsp+28h],50h

 

// デバッグ ビルドの場合

0:000> u testProgram!func6

testProgram!func6:

00000001`3fd31030 4c894c2420      mov     qword ptr [rsp+20h],r9

00000001`3fd31035 4c89442418      mov     qword ptr [rsp+18h],r8

00000001`3fd3103a 4889542410      mov     qword ptr [rsp+10h],rdx

00000001`3fd3103f 48894c2408      mov     qword ptr [rsp+8],rcx

00000001`3fd31044 57              push    rdi

00000001`3fd31045 4883ec40        sub     rsp,40h

00000001`3fd31049 488bfc          mov     rdi,rsp

00000001`3fd3104c 48b91000000000000000 mov rcx,10h

 

 

- 引数の探し方

 

さて、この時点で、例えば func3 への引数を調べたかったとしましょう。今回はホーム スペースに残っていますが、これはたまたまですので、なかったこととしてデバッグしてみます。

 

0:000> k

Child-SP          RetAddr           Call Site

00000000`0031f810 00000001`3f7c1092 testProgram!func6+0x34

00000000`0031f860 00000001`3f7c10cc testProgram!func3+0x52

00000000`0031f8a0 00000001`3f7c1292 testProgram!wmain+0x2c

00000000`0031f8d0 00000000`7789f56d testProgram!__tmainCRTStartup+0x11a

00000000`0031f900 00000000`779d3281 kernel32!BaseThreadInitThunk+0xd

00000000`0031f930 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

 

 

まずは func3 が呼ばれる直前のアセンブリを確認します。

 

0:000> ub 00000001`3f7c10cc

testProgram!wmain+0x6:

00000001`3f7c10a6 ff157c100000    call    qword ptr [testProgram!_imp_rand (00000001`3f7c2128)]

00000001`3f7c10ac 488d0d3d110000  lea     rcx,[testProgram!`string' (00000001`3f7c21f0)]

00000001`3f7c10b3 4863d8          movsxd  rbx,eax

00000001`3f7c10b6 ff157c100000    call    qword ptr [testProgram!_imp_printf (00000001`3f7c2138)]

00000001`3f7c10bc ba02000000      mov     edx,2

00000001`3f7c10c1 8d4aff          lea     ecx,[rdx-1]

00000001`3f7c10c4 4c8bc3          mov     r8,rbx

00000001`3f7c10c7 e874ffffff      call    testProgram!func3 (00000001`3f7c1040)

 

第 1、第 2 引数は "1" と "2" を指定しただけですので、値を直接 ecx と edx に入れていますね。しかし、第 3 引数は rand() の結果を一度 rbx に入れ、それを r8 に入れていることが分かります。

 

では、func3 の頭をアセンブリを確認します。

 

0:000> u 00000001`3f7c1040

testProgram!func3:

00000001`3f7c1040 48895c2408      mov     qword ptr [rsp+8],rbx

00000001`3f7c1045 57              push    rdi

00000001`3f7c1046 4883ec30        sub     rsp,30h

00000001`3f7c104a 498bf8          mov     rdi,r8

00000001`3f7c104d ff15d5100000    call    qword ptr [testProgram!_imp_rand (00000001`3f7c2128)]

00000001`3f7c1053 ba01000000      mov     edx,1

00000001`3f7c1058 488d0d79110000  lea     rcx,[testProgram!`string' (00000001`3f7c21d8)]

00000001`3f7c105f 448d4201        lea     r8d,[rdx+1]

 

最初に rbx の値を rsp+8 に保存しています。ということは、この時点でのスタックポインタの値が分かれば、rbx に保存されていた第 3 引数の値も分かります。

 

では、スタック ポインタの値を計算しましょう。まず、x64 呼出では、一つの関数のプロローグ コードとエピローグ コードの間、rsp の値は変わりません。関数開始時に実行されるプロローグコードで、ローカル変数や、関数内から呼ぶ関数の引数用のスタックスペースなど、必要なスタック領域を全て事前に確保するようになっています。アセンブリを見ると、rbx レジスタをスタックに保存した後、push コマンドを実行し、sub コマンドで rsp をずらしていますね。この sub コマンドが、確保処理です。つまり、これ以降、スタックポインタは func3 内では変わりません。

 

では、func3 実行時のスタック ポインタを確認しましょう。この値は 'k' コマンドで確認することができます。

 

0:000> k

Child-SP          RetAddr           Call Site

00000000`0031f810 00000001`3f7c1092 testProgram!func6+0x34

00000000`0031f860 00000001`3f7c10cc testProgram!func3+0x52

00000000`0031f8a0 00000001`3f7c1292 testProgram!wmain+0x2c

00000000`0031f8d0 00000000`7789f56d testProgram!__tmainCRTStartup+0x11a

00000000`0031f900 00000000`779d3281 kernel32!BaseThreadInitThunk+0xd

00000000`0031f930 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

 

0x00000000`0031f860 ですね。後は、ここからプロローグコードで行われた処理を逆計算すれば、引数の値を確認できます。

 

プロローグ コードでは 0x30 を引き、さらに push もあったので、rsp の値は +0x38 のはずです。

 

0:000> ? 00000000`0031f860+30+8

Evaluate expression: 3274904 = 00000000`0031f898

 

ここから、rsp+8 に保存していたので…

 

0:000> dps 00000000`0031f898+8 L1

00000000`0031f8a0  00000000`00000029

 

一致しますね。無事、引数の値を確認することができました。

 

 

- 裏技紹介

このように、x64 では引数一つ調べるだけでかなりの工数がかかってしまいます。場合によって、引数を調べるためだけに関数を二つ、三つと追っていく必要があることもあり、大変です。そこで、この作業時間を減らすコマンドを紹介します！

 

.frame /r <フレーム番号>

 

このコマンドでは、指定したスタックフレーム時のレジスタの中身を表示します。尚、全てのレジスタ値が表示されますが、信用できる値は非揮発的なレジスタのみです。x64 では rbx、rbp、rdi、rsi、そして r12 ～ r15 ですね。

 

さて、上記例では、func3 に渡された第 3 引数は、wmain 関数の rbx に保存されていました。そこで、このコマンドの出番です。

まずは wmain のフレーム番号を確認します。

 

0:000> kn

# Child-SP          RetAddr           Call Site

00 00000000`0031f810 00000001`3f7c1092 testProgram!func6+0x34

01 00000000`0031f860 00000001`3f7c10cc testProgram!func3+0x52

02 00000000`0031f8a0 00000001`3f7c1292 testProgram!wmain+0x2c

03 00000000`0031f8d0 00000000`7789f56d testProgram!__tmainCRTStartup+0x11a

04 00000000`0031f900 00000000`779d3281 kernel32!BaseThreadInitThunk+0xd

05 00000000`0031f930 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

 

フレーム 2 ですね。では、フレーム 2 のレジスタの内容を確認しましょう。

 

0:000> .frame /r 2

02 00000000`0031f8a0 00000001`3f7c1292 testProgram!wmain+0x2c

rax=0000000000004823 rbx=0000000000000029 rcx=000000013f7c21b0

rdx=0000000000000010 rsi=0000000000000000 rdi=0000000000000001

rip=000000013f7c10cc rsp=000000000031f8a0 rbp=0000000000000000

r8=0000000000000020  r9=0000000000000030 r10=0000000000000000

r11=0000000000000246 r12=0000000000000000 r13=0000000000000000

r14=0000000000000000 r15=0000000000000000

iopl=0         nv up ei pl nz na pe nc

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

testProgram!wmain+0x2c:

00000001`3f7c10cc 33c0            xor     eax,eax

 

rbx には引数である 0x29 が表示されていますね。簡単に引数を調べることができました。

x64 環境のデバッグを行う際には役立つコマンドですので、是非活用してください。

 

 

- 参考資料

 

Overview of x64 Calling Conventions

https://msdn.microsoft.com/en-us/library/ms235286.aspx

 

x64 Software Conventions

https://msdn.microsoft.com/en-us/library/7kcdt6fy.aspx

 

Challenges of Debugging Optimized x64 Code

https://blogs.msdn.com/ntdebugging/archive/2009/01/09/challenges-of-debugging-optimized-x64-code.aspx

 

 

 

 

]]>