豊田孝の「IT談話館」
Windowsカーネル空間の診断・解析を依頼する 診断・解析技術オンサイトセミナーを受講する




カーネルメモリダンプ解析サービス
所属チーム内でご協議の上、ご利用いただけますと幸いです。





Windows 10 Active Memory Dumpとカーネルメモリダンプ


 Windows 7や8.1からWindows 10へアップグレードいたしますと、Active Dump Memoryという新しい種類のクラッシュダンプを作成できるようになります。本稿では、このActive Dump Memoryと、従来から作成できるカーネルビットマップダンプを比較しながら、これら2種類のダンプ間の相違をご紹介いたします。

 Windowsアプリケーションはユーザー空間で動作を開始し、後ほど触れますように、システムサービスを呼び出しながら、各種のカーネル機能を利用する仕様となっています。ユーザー空間からカーネル空間へのアプリケーションの流れを解析する場合、これまではアプリケーションの動きをリアルタイムで解析したり、巨大な完全メモリダンプを採取する必要がございました。Windows 10から導入されたActive Memory Dumpには、採取時点のカーネル空間情報に加え、アプリケーションが使用しているユーザー空間情報が追加的に記録されています。

 新種のダンプファイルの導入自体は歓迎すべきことですが、保存される情報の質と量が気になります。そこで、次のような視点からWindows 10環境で採取したカーネルビットマップダンプとActive Memory Dumpを解析してみることにいたします。  まずはWindows 10環境で採取されたカーネルビットマップの解析結果をご覧いただきます。
カーネルビットマップ


0xffffe0015246a840	ActiveThread->011	csrss.exe
No.001	Thread->0xffffe001522c9840	TrapFrame->0xffffd00158946c00
		Start->00007ff9`a45a5310	Rip->00007ff9`a7c43d7a
No.002	Thread->0xffffe00150318080	TrapFrame->0xffffd00158dcdc00
		Start->00007ff9`a45a5310	Rip->00007ff9`a7c43d7a
No.003	Thread->0xffffe0015220c840	TrapFrame->0xffffd001589f2c00
		Start->00007ff9`a4547130	Rip->00007ff9`a4547a5a
No.004	Thread->0xffffe00152e56080	TrapFrame->0xffffd00020595c00
		Start->00007ff9`a45a5310	Rip->00007ff9`a7c43d7a
No.005	Thread->0xffffe00152f65080	TrapFrame->0xffffd000208bfc00
		Start->00007ff9`a45a5310	Rip->00007ff9`a7c43d7a
No.006	Thread->0xffffe00150eff040	TrapFrame->0xffffd00021a3bc00
		Start->00007ff9`a7be9040	Rip->00007ff9`a7c4505a

0xffffe001549b65c0	ActiveThread->012	csrss.exe
No.001	Thread->0xffffe0015162f080	TrapFrame->0xffffd00021cefc00
		Start->00007ff9`a45a5310	Rip->00007ff9`a7c43d7a
No.002	Thread->0xffffe0015165c080	TrapFrame->0xffffd0002231ec00
		Start->00007ff9`a45a5310	Rip->00007ff9`a7c43d7a
No.003	Thread->0xffffe00154fdf080	TrapFrame->0xffffd000231cdc00
		Start->00007ff9`a4547130	Rip->00007ff9`a4547a5a
No.004	Thread->0xffffe001539de080	TrapFrame->0xffffd00020375c00
		Start->00007ff9`a4547130	Rip->00007ff9`a4547a5a
No.005	Thread->0xffffe00154dae080	TrapFrame->0xffffd00023157c00
		Start->00007ff9`a45a5310	Rip->00007ff9`a7c43d7a
No.006	Thread->0xffffe00154a71080	TrapFrame->0xffffd000224fdc00
		Start->00007ff9`a4547130	Rip->00007ff9`a4547a5a
No.007	Thread->0xffffe0015238c680	TrapFrame->0xffffd00021afbc00
		Start->00007ff9`a7be9040	Rip->00007ff9`a7c4505a
 これは本「IT談話館」独自の解析コードが返してくれた「csrss.exe」プロセスに関する情報です。実際には、すべてのプロセス情報が返されていますが、ここでは、「csrss.exe」プロセスに関する情報だけを紹介しております。ご覧のように、16進数値が並んでいるだけですから、これら2つのプロセスの特徴を瞬時に把握することはできません。その最大の原因は、ユーザー空間情報が記録されていないことです。次にご紹介する情報は、同一の解析コードでActive Memory Dumpダンプを解析した結果です。
Active Memory Dumpダンプ


0xffffe000fb83c240	ActiveThread->012	csrss.exe
No.001	Thread->0xffffe000fb80a080	TrapFrame->0xffffd001276a5c00
		Start->00007ffd`aee15310	Rip->ntdll!NtAlpcSendWaitReceivePort+0xa (00007ffd`b24b3d7a)
No.002	Thread->0xffffe000fc417080	TrapFrame->0xffffd0012d2f7c00
		Start->00007ffd`aee15310	Rip->ntdll!NtAlpcSendWaitReceivePort+0xa (00007ffd`b24b3d7a)
No.003	Thread->0xffffe000fc414480	TrapFrame->0xffffd00127aaec00
		Start->00007ffd`aedb7130	Rip->00007ffd`aedb7a5a
No.004	Thread->0xffffe000fc4f8840	TrapFrame->0xffffd0012768cc00
		Start->00007ffd`aedb7130	Rip->00007ffd`aedb7a5a
No.005	Thread->0xffffe000fca6d080	TrapFrame->0xffffd0012b3fcc00
		Start->00007ffd`aee15310	Rip->ntdll!NtAlpcSendWaitReceivePort+0xa (00007ffd`b24b3d7a)
No.006	Thread->0xffffe000fce1a080	TrapFrame->0xffffd0012c1fcc00
		Start->00007ffd`aee15310	Rip->ntdll!NtAlpcSendWaitReceivePort+0xa (00007ffd`b24b3d7a)

0xffffe000fa2a4080	ActiveThread->012	csrss.exe
No.001	Thread->0xffffe000fa2de180	TrapFrame->0xffffd0012b1bac00
		Start->00007ffd`aee15310	Rip->ntdll!NtAlpcSendWaitReceivePort+0xa (00007ffd`b24b3d7a)
No.002	Thread->0xffffe000fc53e700	TrapFrame->0xffffd001294bec00
		Start->00007ffd`aee15310	Rip->ntdll!NtAlpcSendWaitReceivePort+0xa (00007ffd`b24b3d7a)
No.003	Thread->0xffffe000fc537280	TrapFrame->0xffffd0012aa70c00
		Start->00007ffd`aedb7130	Rip->00007ffd`aedb7a5a
No.004	Thread->0xffffe000fc535800	TrapFrame->0xffffd0012aa77c00
		Start->00007ffd`aedb7130	Rip->00007ffd`aedb7a5a
No.005	Thread->0xffffe000fc5f4080	TrapFrame->0xffffd0012d139c00
		Start->00007ffd`aee15310	Rip->ntdll!NtAlpcSendWaitReceivePort+0xa (00007ffd`b24b3d7a)
 赤色のデータからは、これらのプロセスがAlpcを使用し、他のプロセスと通信していることが分かります。このため、「!alpc /lpp 0xffffe000fb83c240」といったWinDbg拡張コマンドを実行すれば、プロセス間通信の概要をある程度その場で把握できます。

 2つのクラッシュダンプを採取するために、今回は「NotMyfault.exe」を使用しましたから、そのプロセス情報を解析し、ユーザー空間とカーネル空間の関係を覗いてみます。
Active Memory Dumpダンプ

0: kd> vertarget
Windows 10 Kernel Version 10240 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 10240.16393.amd64fre.th1_st1.150717-1719
Machine Name:
Kernel base = 0xfffff803`15415000 PsLoadedModuleList = 0xfffff803`1573a030
Debug session time: Tue Aug  4 11:21:22.658 2015 (UTC + 9:00)
System Uptime: 0 days 18:04:16.257


0xffffe0007749f080	ActiveThread->003	NotMyfault.exe
No.001	Thread->0xffffe00075ea5840	TrapFrame->0xffffd00022fbde40
		Start->NotMyfault+0x2f98 (00007ff7`cf1a2f98)	Rip->ntdll!NtDeviceIoControlFile+0xa (00007ffa`3dab356a)
No.002	Thread->0xffffe000772b9840	TrapFrame->0xffffd00022a2ec00
		Start->ntdll!TppWorkerThread (00007ffa`3da59040)	Rip->ntdll!NtWaitForWorkViaWorkerFactory+0xa (00007ffa`3dab505a)
No.003	Thread->0xffffe00076aff5c0	TrapFrame->0xffffd000210eac00
		Start->ntdll!TppWorkerThread (00007ffa`3da59040)	Rip->ntdll!NtWaitForWorkViaWorkerFactory+0xa (00007ffa`3dab505a)
 赤色のデータの背景は、次のようなコマンド操作で調査できます。
1: kd> u ntdll!NtDeviceIoControlFile ntdll!NtDeviceIoControlFile+a
ntdll!NtDeviceIoControlFile:
00007ffc`b04d3560 4c8bd1          mov     r10,rcx
00007ffc`b04d3563 b807000000      mov     eax,7
00007ffc`b04d3568 0f05            syscall
00007ffc`b04d356a c3              ret
 「syscall」は、ユーザー空間からカーネル空間に存在するシステムサービステーブルへアクセスするコードです。一方、「7」という数値は、次のように、テーブル内のインデックスを示しています。「r10,rcx」部分は、システムサービスに渡す引数ですが、後ほど調査してみます。
0: kd> ub ntdll!NtDeviceIoControlFile+a l0n20
ntdll!NtMapUserPhysicalPagesScatter+0xa:
00007ffa`3dab352a c3              ret
00007ffa`3dab352b 0f1f440000      nop     dword ptr [rax+rax]
ntdll!NtWaitForSingleObject:
00007ffa`3dab3530 4c8bd1          mov     r10,rcx
00007ffa`3dab3533 b804000000      mov     eax,4
00007ffa`3dab3538 0f05            syscall
00007ffa`3dab353a c3              ret
00007ffa`3dab353b 0f1f440000      nop     dword ptr [rax+rax]
ntdll!NtCallbackReturn:
00007ffa`3dab3540 4c8bd1          mov     r10,rcx
00007ffa`3dab3543 b805000000      mov     eax,5
00007ffa`3dab3548 0f05            syscall
00007ffa`3dab354a c3              ret
00007ffa`3dab354b 0f1f440000      nop     dword ptr [rax+rax]
ntdll!NtReadFile:
00007ffa`3dab3550 4c8bd1          mov     r10,rcx
00007ffa`3dab3553 b806000000      mov     eax,6
00007ffa`3dab3558 0f05            syscall
00007ffa`3dab355a c3              ret
00007ffa`3dab355b 0f1f440000      nop     dword ptr [rax+rax]
ntdll!NtDeviceIoControlFile:
00007ffa`3dab3560 4c8bd1          mov     r10,rcx
00007ffa`3dab3563 b807000000      mov     eax,7
00007ffa`3dab3568 0f05            syscall
 「7」をはじめとするインデックス値とシステムサービステーブル、および、システムサービスの関係は、次のようになっています。
  0	nt!NtAccessCheck (fffff803`15505324)
  1	nt!NtWorkerFactoryWorkerReady (fffff803`15508810)
  2	nt!NtAcceptConnectPort (fffff803`1594366c)
  3	nt!NtMapUserPhysicalPagesScatter (fffff803`15ab6c78)
  4	nt!NtWaitForSingleObject (fffff803`15837420)
  5	nt!NtCallbackReturn (fffff803`15564dd0)
  6	nt!NtReadFile (fffff803`15834d10)
  7	nt!NtDeviceIoControlFile (fffff803`15842a00)
  8	nt!NtWriteFile (fffff803`15834100)
  9	nt!NtRemoveIoCompletion (fffff803`1591d5b0)
 10	nt!NtReleaseSemaphore (fffff803`159053a0)
 11	nt!NtReplyWaitReceivePort (fffff803`15829b6c)
 12	nt!NtReplyPort (fffff803`15927e04)
 13	nt!NtSetInformationThread (fffff803`1582a400)
 14	nt!NtSetEvent (fffff803`15840410)
 15	nt!NtClose (fffff803`15835f90)
 [---]
 ご覧のように、システムサービスが順序よく並んでいます。「7 nt!NtDeviceIoControlFile (fffff803`15842a00)」サービスは、「r10,rcx」経由で次のような引数を受け取っています。
NotMyfault.exe(0xffffe0007749f080) has 3 active threads
	 1: Thread: 0xffffe00075ea5840
		Wait Reason: 27
		State: 2
		Trapframe: ffffd00022fbde40
		Arg(448)
		System Call Number:    7 ===>	nt!NtDeviceIoControlFile (fffff803`15842a00)
	 2: Thread: 0xffffe000772b9840
		Wait Reason: 15
		State: 5
		Trapframe: ffffd00022a2ec00
		Arg(92)
		System Call Number:  438 ===>	nt!NtWaitForWorkViaWorkerFactory (fffff803`15457810)
	 3: Thread: 0xffffe00076aff5c0
		Wait Reason: 15
		State: 5
		Trapframe: ffffd000210eac00
		Arg(92)
		System Call Number:  438 ===>	nt!NtWaitForWorkViaWorkerFactory (fffff803`15457810)


0: kd> !handle 0n448 3 0xffffe0007749f080

PROCESS ffffe0007749f080
    SessionId: 2  Cid: 141c    Peb: 7ff7cee8d000  ParentCid: 1204
    DirBase: 69225000  ObjectTable: ffffc001e0e2b2c0  HandleCount: 
    Image: NotMyfault.exe

Handle Error reading handle count.

01c0: Object: ffffe00076049f20  GrantedAccess: 0012019f (Protected) (Inherit) (Audit) Entry: ffffc001d3300700
Object: ffffe00076049f20  Type: (ffffe0007301fdc0) File
    ObjectHeader: ffffe00076049ef0 (new version)
        HandleCount: 1  PointerCount: 32770
 ご覧のように、「7 nt!NtDeviceIoControlFile (fffff803`15842a00)」システムサービスは、Fileオブジェクトを受け取っています。本稿では、Fileオブジェクトの解析工程の説明は割愛させていただきます。Active Memory Dumpにはユーザー空間で動作していた「NotMyfault.exe」プロセスに関する情報が記録されており、たいへん便利です。このレベルの基本的な解析技術を身に着けておきますと、Windows 10の最新のカーネル内部変更にも対応できるようになります。次の情報は、ビルド番号更新後のWindows 10の「ntdll!NtDeviceIoControlFile」の実装ロジックであり、セキュリティー向上の視点から、システム呼び出し工程が変更されたことを示しています。

0: kd> vertarget
Windows 10 Kernel Version 14393 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 14393.447.amd64fre.rs1_release_inmarket.161102-0100
Machine Name:
Kernel base = 0xfffff803`9a41b000 PsLoadedModuleList = 0xfffff803`9a720060
Debug session time: Fri Dec  9 14:38:31.095 2016 (UTC + 9:00)
System Uptime: 2 days 22:31:57.668


ntdll!NtDeviceIoControlFile:
00007ff9`c5394f30 4c8bd1          mov     r10,rcx
00007ff9`c5394f33 b807000000      mov     eax,7
00007ff9`c5394f38 f604250803fe7f01 test    byte ptr [SharedUserData+0x308 (00000000`7ffe0308)],1
00007ff9`c5394f40 7503            jne     ntdll!NtDeviceIoControlFile+0x15 (00007ff9`c5394f45)
00007ff9`c5394f42 0f05            syscall
 このレベルの内部変更は、「Windows As A Service」ビジネスモデルがすでに採用されている現在、カーネル内部のいたるところに見られます。内部変更の多くは、突然、あるいは、こっそり、行われる性格が強く、公には語られないと予想されます。これまで何の問題もなく動作していたアプリケーションが突然動作しなくなる。このような事態をもろ手を挙げて歓迎するわけにはまいりませんが、基本的には、避けられないと覚悟したほうがよろしいと思います。

 実務的な解析コードの開発技術の導入をご予定の場合には、所属チーム内でご協議の上、本「IT談話館」の「オンサイトセミナー」の受講をご検討いただけますと幸いでございます。

 今回使用いたしました解析コードは、「Windows内部解析者のツールボックス」に収録してございます。


豊田孝の「IT談話館」サービスメニュー
Windowsカーネル空間の診断・解析サービス 診断・解析技術移転サービス 技術資料

Copyright©豊田孝 2004- 2017
本日は2017-06-25です。