WindowsXPのクラッシュダンプ

PCトラブル

STOPエラー(KERNEL_STACK_INPAGE_ERROR) - enduser’s monthly reportの関連です。

今回の日記の要点を3行でまとめるなら以下のとおりです。

  1. WindowsXPはSTOPエラーが起きると（既定の設定では）クラッシュダンプを生成する。
  2. クラッシュダンプは Debugging Tools for Windows で解析できる。
  3. 解析結果の英語をちゃんと読むと役に立つ情報が書いてあることがある。

それでは一つずつ取り上げていきましょう。

1.WindowsXPはSTOPエラーが起きると（既定の設定では）クラッシュダンプを生成する。

クラッシュダンプは %SYSTEMROOT%\minidump フォルダ内に拡張子 dmp のファイルとして生成されます。

このダンプファイルは 2.で紹介するツールで解析します。

2.クラッシュダンプは Debugging Tools for Windows で解析できる。

Debugging Tools for Windows は、Microsoftサイトで入手できるデバッグ用ツールです。
この中の Windbg を使用してクラッシュダンプの解析を行うことができます。
導入方法は他のサイトでたくさん解説されているため省きます。
シンボルファイルのですが、インターネット常時接続の環境ですので、以下のように設定してオンラインで入手するようにしています。

SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

さて、windbgを起動し、シンボルファイル指定を済ませた環境で今回のクラッシュダンプを読み込ませたところ、以下のとおり表示されました。

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINDOWS\Minidump\Mini121811-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 2600.xpsp_sp3_gdr.111025-1629
Machine Name:
Kernel base = 0x804d9000 PsLoadedModuleList = 0x8055f720
Debug session time: Sun Dec 18 01:39:31.571 2011 (UTC + 9:00)
System Uptime: 1 days 5:36:55.131
Loading Kernel Symbols
...............................................................
................................................................
..............
Loading User Symbols
Loading unloaded module list
...............................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use <span class="deco" style="color:#0000FF;">!analyze -v</span> to get detailed debugging information.

BugCheck 77, {1, 5d388900, 0, b2d05960}

Probably caused by : memory_corruption ( nt!MmInPageKernelStack+176 )

Followup: MachineOwner
---------

ここで、ウィンドウ最下部の 0: kd> の右側の領域に !analyze -v と入力して[Enter]を押すと解析が進み、下記の表示が追加されました。

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

KERNEL_STACK_INPAGE_ERROR (77)
The requested page of kernel data could not be read in.  Caused by
bad block in paging file or disk controller error.
In the case when the first arguments is 0 or 1, the stack signature
in the kernel stack was not found.  Again, bad hardware.
An I/O status of c000009c (STATUS_DEVICE_DATA_ERROR) or
C000016AL (STATUS_DISK_OPERATION_FAILED)  normally indicates
the data could not be read from the disk due to a bad
block.  Upon reboot autocheck will run and attempt to map out the bad
sector.  If the status is C0000185 (STATUS_IO_DEVICE_ERROR) and the paging
file is on a SCSI disk device, then the cabling and termination should be
checked.  See the knowledge base article on SCSI termination.
Arguments:
Arg1: 00000001, (page was retrieved from disk)
Arg2: 5d388900, value found in stack where signature should be
Arg3: 00000000, 0
Arg4: b2d05960, address of signature on kernel stack

Debugging Details:
------------------


ERROR_CODE: (NTSTATUS) 0x1 - STATUS_WAIT_1

BUGCHECK_STR:  0x77_1

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

PROCESS_NAME:  System

LAST_CONTROL_TRANSFER:  from 80514e48 to 804fbf43

STACK_TEXT:  
b851bd58 80514e48 00000077 00000001 5d388900 nt!KeBugCheckEx+0x1b
b851bd8c 80541dd6 0000ed48 00000000 8b060d08 nt!MmInPageKernelStack+0x176
b851bda4 805422a6 8900eda8 805d1fa8 00000000 nt!KiInSwapKernelStacks+0x16
b851bdac 805d1fa8 00000000 00000000 00000000 nt!KeSwapProcessOrStack+0x7c
b851bddc 8054815e 8054222a 00000000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MmInPageKernelStack+176
80514e48 8a550b          mov     dl,byte ptr [ebp+0Bh]

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt!MmInPageKernelStack+176

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4ea6b0e6

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  0x77_1_nt!MmInPageKernelStack+176

BUCKET_ID:  0x77_1_nt!MmInPageKernelStack+176

Followup: MachineOwner
---------

原因が上記メッセージに書いてあったことにお気づきでしょうか。
次はその点に触れたいと思います。

3.解析結果の英語をちゃんと読むと役に立つ情報が書いてあることがある。

今回の解析メッセージには役に立つことが書いてありました。見るのは以下の部分です。

In the case when the first arguments is 0 or 1, the stack signature
in the kernel stack was not found.  Again, bad hardware.

(中略)

Arg1: 00000001, (page was retrieved from disk)

ものすごく乱暴に読むと、Arg1 が 0 か 1 ならハードウェアが原因と書いてあり、Arg1 は 1 であることも分かります。
そのため、今回のエラーの原因がソフトかハードかについては、「ハードウェアが悪い」と切り分けることができました。

しかし、この時点ではどのハードウェアが悪いのかの情報はありません。

ここで、起動できないハードディスクからイベントログをピックアップできれば、前回の記事のとおりイベントログを解析して「SATAケーブル交換」という解にたどり着けます。

しかし、イベントログ解析前にケーブルを交換・再接続してみるというのは、個人環境なら問題解決手段として十分考えられるアプローチです。
（もう少し慎重に行くなら故障HDDのデータ保全を最優先し、テスト用のケーブルとHDDをつないでみて起動確認を取ります）

このように、クラッシュダンプとイベントログをピックアップして解析することにより、既知の問題の場合は原因の絞り込みが可能な場合があります。

起動しないOSがあるHDDを別PCにつないで内容が認識できる場合、これは有効な問題判別手段となりえるので、一応覚えておいて損はないかと思います。


（こういう問題って、対応方法を忘れたころに起きるから本当に困ります）