続：BSoDとの戦いに挑む

ネイティブモジュールのデバッグに挑む

先日のポストでToDoにしていた、デバッガのセットアップとかをやってみた。

いまどきのデバッガ

Debugging Tools for Windows というやつを使うんだが、こいつにはMicrosoft Store版があって、最新のWindows 10の場合そちらのほうがより近代的なんだそうな。

ストアアプリなので、導入自体はいたって簡単。ストアからアプリを入れたら、アクセスしやすくするためスタートメニューにピン止めしておく。

一方、ダンプサイズの拡張については、最近のWindowsはやらなくてもそれなりのサイズを確保してくれるらしい。設定自体は以前と同じシステムのプロパティの中の「起動と回復」の中にある。

デフォルト値が「自動メモリダンプ」になっていて、メモリを16GB搭載しているこのPCでは、だいたい1GB～1.5GB程度のダンプを確保してくれるようになっている。
昔のデフォルト値は「最小メモリダンプ(256KB)」だったので、ダンプから自力でどうにかしようと考えているような人にはいい時代になった、と言える(？)

実際にデバッガにかけてみる

実のところ、よく発生しているBSoD 2種が先日の記事を書いた後で運よく(？)発生したので、ダンプを確保して分析にかけてみることにした。
WinDbgを起動して、確保したダンプを読み込ませると、自動的に簡易分析が始まる。デバッグシンボルの取得は勝手にやってくれるようだ。

画面中の !analyze -v のリンクを押すと分析が始まる。
以下は DRIVER_IRQL_NOT_LESS_OR_EQUAL で BSoD になったやつを分析したときの出力だけど、長いので途中省略。 vmswitch というモジュールがトリガーになったようだ。

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000548, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff808c961972b, address which referenced memory

Debugging Details:
------------------
  :
(中略)
  :
FOLLOWUP_IP: 
vmswitch!VmsQueueGroupIsRestrictedQueue+7
fffff808`c961972b 8b9048050000    mov     edx,dword ptr [rax+548h]

FAULT_INSTR_CODE:  548908b
SYMBOL_STACK_INDEX:  3
SYMBOL_NAME:  vmswitch!VmsQueueGroupIsRestrictedQueue+7
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: vmswitch
IMAGE_NAME:  vmswitch.sys
DEBUG_FLR_IMAGE_TIMESTAMP:  62acf328
STACK_COMMAND:  .thread ; .cxr ; kb
BUCKET_ID_FUNC_OFFSET:  7
FAILURE_BUCKET_ID:  AV_vmswitch!VmsQueueGroupIsRestrictedQueue
BUCKET_ID:  AV_vmswitch!VmsQueueGroupIsRestrictedQueue
PRIMARY_PROBLEM_CLASS:  AV_vmswitch!VmsQueueGroupIsRestrictedQueue
  :

そして、もう一つ。 KERNEL_SECURITY_CHECK_FAILURE で BSoD になったやつを分析してみる。

Loading Dump File [C:\work\memdumps\0x139_vmswitch-sys_20190622-03.DMP]
Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available.

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*
Symbol search path is: srv*
Executable search path is: 
Windows 10 Kernel Version 17134 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 17134.1.amd64fre.rs4_release.180410-1804
Machine Name:
Kernel base = 0xfffff803`254b0000 PsLoadedModuleList = 0xfffff803`2585d170
Debug session time: Sat Jun 22 22:09:48.984 2019 (UTC + 9:00)
System Uptime: 0 days 5:39:39.842
Loading Kernel Symbols
.........................................Page 20008bef5 too large to be in the dump file.
Page 2000aadf4 too large to be in the dump file.
......................
................................................................
................................................................
...............................
Loading User Symbols

Loading unloaded module list
..............
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff803`2565aab0 48894c2408      mov     qword ptr [rsp+8],rcx ss:0018:ffffda05`86612940=0000000000000139
2: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure.  The corruption
could potentially allow a malicious user to gain control of this machine.
Arguments:
Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
Arg2: ffffda0586612c60, Address of the trap frame for the exception that caused the bugcheck
Arg3: ffffda0586612bb8, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved

Debugging Details:
------------------
  :
(中略)
  :
FOLLOWUP_IP: 
vmswitch!VmsQsUpdatePerProcessorPacketStats+2c3
fffff80b`e4a67be3 cd29            int     29h

FAULT_INSTR_CODE:  8d4829cd
SYMBOL_STACK_INDEX:  4
SYMBOL_NAME:  vmswitch!VmsQsUpdatePerProcessorPacketStats+2c3
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: vmswitch
IMAGE_NAME:  vmswitch.sys
DEBUG_FLR_IMAGE_TIMESTAMP:  62acf328
STACK_COMMAND:  .thread ; .cxr ; kb
BUCKET_ID_FUNC_OFFSET:  2c3
FAILURE_BUCKET_ID:  0x139_3_CORRUPT_LIST_ENTRY_vmswitch!VmsQsUpdatePerProcessorPacketStats
BUCKET_ID:  0x139_3_CORRUPT_LIST_ENTRY_vmswitch!VmsQsUpdatePerProcessorPacketStats
PRIMARY_PROBLEM_CLASS:  0x139_3_CORRUPT_LIST_ENTRY_vmswitch!VmsQsUpdatePerProcessorPacketStats

おや？　こちらも vmswitch がトリガーになっているようだ。

問題になっているモジュールが特定できたので、次はワークアラウンドの検索かな....。