続: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 がトリガーになっているようだ。
問題になっているモジュールが特定できたので、次はワークアラウンドの検索かな....。
| 固定リンク
コメント