本家のお世話-#37。(Operating System Not Found)

 朝起きて(臨時)サーバを見たら,ブラックアウトしているはずのモニタ画面に,何やら白い字が浮かんでいる。「Operating System Not Found」。えーーーーーーっ。ということで,本日,さっきまで自鯖が落ちていました。朝の5時ごろ(多分)から,夕方の6時半くらいまで。m(_”_)m。
 なんかこの頃こんなんばっか。要するに,こないだのことが根本的に解決していないということなんだろう。しかし,なんかで異常が起きて,その後,再起動し,この事態ということだよね。

 しかし,すぐに電源を落として,手動で再起動したら,普通に起きるんだよ。どうしてっ。起動後に「システムは深刻なエラーから回復しました。」の窓が出現し,それのおっしゃることには,C:\DOCUME~1\lc550\LOCALS~1\Temp\WER031f.dir00\Mini060312-01.dmp を作ったよということなので,イベントビューアからシステムのイベントを見に行ったら,なるほど,Save Dumpという項目があった。Tempのファイルは,エラーメッセージを閉じてしまうと削除されるが,ダンプファイルは C:\WINDOWS\Minidump\Mini060312-01.dmp という形で保存されていた。しかし,こっから長い1日だったねー。
 今日は珍しくなにも予定のない日で,FHさんところでお世話になった件の続きを書こうと思っていたのに。(もともとの)「サーバ機テンヤワンヤ」の記事がちっとも捗らない。

 「まぁ,これも勉強だから」ということで,ダンプファイルの解析をしてみることにした。以下の4ファイルをダウンロードした。しかし,このダウンロード,かなりブロークンリンクが多くて,正しいところに行きつくまで手間取った。「MS,ヘルプページの保守が悪いんじゃないの!?」他のメーカとは比べ物にならないくらい巨大なアーカイブだということはわかるけど,もうちょっとどうにかしてほしいヨ。

  1. Windows XP Service Pack 3 x86 製品版シンボル、全言語
    WindowsXP-KB936929-SP3-x86-symbols-full-ENU.exe のこと
  2. .NET Framework 4
  3. .NET Framework 4 Full 日本語 Language Pack(x86)
  4. Microsoft Windows SDK for Windows 7 and .NET Framework 4(winsdk_web.exe)

 この順でインストール。2.と3.はクライアント用ではなくフルバージョンということになる。当然ながら,このインストールはサーバ機ではなく,別PCに行った。

 本当は,WinDbgをスタンドアローンで使いたかったのだが,Debugging Tools for Windows をスタンドアロン コンポーネントとしてインストールするを見ると,インストール要件を満たしていないようで,よくわからないので,もういいやということでwinsdk_web.exe をインスールした(投げやりー)。
 winsdk_web.exeでは,ツールと一緒にVC10をインストールするようになっているが,同梱のVC10より新しいものがすでにインストールされていると,ライブラリの関係でインストールが失敗するので,前もって既インストールのVC10をアンインストールしておいた方が無難。
 同梱のVC10をインストールしないで,既インストール版をそのまま使うということも考えたが,既に入っているものすらしっかり認識されずにバージョンでエラーが出るくらいだから,WinDbgとVC10の連携がうまくいかないと困ると思ったので,既インストール版VC10をアンインストールして,winsdk_web.exeをインストールし,その後,MicroSoft Updateを行うという手間をかけた。

 WinDbgを起動し,メニューの「File」>>「Symbol File Path」に1.でインストールした,C:\WINDOWS\Symbols を設定する。シンボルパッケージは,ローカルにインストールしなくても,常時インターネット接続なら,ここに,SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols とやってもおくと,いつも最新のシンボルが参照できるらしい。

 起動したWinDbgに,サーバからコピーしてきたMini060312-01.dmpをD&Dすると,


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


Loading Dump File [A:\Mini060312-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: C:\WINDOWS\Symbols
Executable search path is: 
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Windows XP Kernel Version 2600 (Service Pack 3) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Machine Name:
Kernel base = 0x804d9000 PsLoadedModuleList = 0x8055d2c0
Debug session time: Sun Jun  3 05:18:17.788 2012 (UTC + 9:00)
System Uptime: 2 days 7:02:04.384
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Loading Kernel Symbols
...............................................................
..............................................................
Loading User Symbols
Loading unloaded module list
.............................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7A, {c03ddee4, c000000e, f77b950c, 22013860}

Unable to load image atapi.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for atapi.sys
Probably caused by : atapi.sys ( atapi!ChannelQueryBusRelation+2f )

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

 下線のついた!analyze -vというのをクリックすると,さらに,

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KERNEL_DATA_INPAGE_ERROR (7a)
The requested page of kernel data could not be read in.  Typically caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed because
a filesystem failed to make forward progress.
Arguments:
Arg1: c03ddee4, lock type that was held (value 1,2,3, or PTE address)
Arg2: c000000e, error status (normally i/o status code)
Arg3: f77b950c, current process (virtual address for lock type 3, or PTE)
Arg4: 22013860, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)

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


ERROR_CODE: (NTSTATUS) 0xc000000e - <Unable to get error code text>

DISK_HARDWARE_ERROR: There was error with disk hardware

BUGCHECK_STR:  0x7a_c000000e

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

PROCESS_NAME:  System

TRAP_FRAME:  f7cbccdc -- (.trap 0xfffffffff7cbccdc)
ErrCode = 00000000
eax=8678e068 ebx=867bb020 ecx=00007b2a edx=867c62d4 esi=86150bc8 edi=867c60e8
eip=f77b950c esp=f7cbcd50 ebp=f7cbcd60 iopl=0         nv up ei pl zr na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00210246
atapi!IdePortScanBus:
f77b950c ??              ???
Resetting default scope

LAST_CONTROL_TRANSFER:  from 80523e01 to 80535876

STACK_TEXT:  
f7cbcbd4 80523e01 0000007a c03ddee4 c000000e nt!KeCheckForTimer+0x5a
f7cbcbfc 804fb2c8 813831c8 c03ddee4 f77b950c nt!MiWaitForInPageComplete+0x215
f7cbcc74 804eda7a 22013860 f77b950c c03ddee4 nt!MiDispatchFault+0x2fb
f7cbccc4 804e372b 00000000 f77b950c 00000000 nt!MmAccessFault+0x609
f7cbccc4 f77b950c 00000000 f77b950c 00000000 nt!KiTrap0E+0xdf
f7cbcd4c f77bbe29 867c60e8 867c2098 867c6030 atapi!IdePortScanBus
f7cbcd60 80566710 867c6030 867e7130 805643fc atapi!ChannelQueryBusRelation+0x2f
f7cbcd74 804e627b 867c2098 00000000 867bb020 nt!ObpRemoveObjectRoutine+0x4
f7cbcdac 8057b4dd 867c2098 00000000 00000000 nt!ExpWorkerThread+0x123
f7cbcddc 804fa90f 804e61a6 00000001 00000000 nt!HvMarkDirty+0x174
f7cbce04 00000000 0000ffff fffcfffc fffcfffc nt!KeStartThread+0xd


STACK_COMMAND:  kb

FOLLOWUP_IP: 
atapi!ChannelQueryBusRelation+2f
f77bbe29 ??              ???

SYMBOL_STACK_INDEX:  6

SYMBOL_NAME:  atapi!ChannelQueryBusRelation+2f

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: atapi

IMAGE_NAME:  atapi.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4802539d

FAILURE_BUCKET_ID:  0x7a_c000000e_atapi!ChannelQueryBusRelation+2f

BUCKET_ID:  0x7a_c000000e_atapi!ChannelQueryBusRelation+2f

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

が追加表示された。読んでみると,ntoskrnl.exeがロードできないと言ってるのは当たり前だろうが,
   Arg2: c000000e, error status (normally i/o status code)
なんていうところがあって,atapi関係がうまくいっていないことが書いてある。そうすると,やっぱり,HDDかなと思って調べたんだけど,この間と同じような状態で,bad sectorsは0なんだよね。

 臨時サーバは,NECのノートだから剥ぐってHDDを調べるのも面倒くさくて,この間やらなかったメモリーテストをMemTest86+でやってみた。そしたら,2枚のモジュールのうち1枚で,何度やっても1カ所だけだけどエラーが出る。しかし,このHDDとmemoryの健康診断に,時間のかかることかかること。終わったころには,疲れ果てて,もう逆さに振ってもやる気が出ない。

 結局この1枚を外して,サーバを再起動したのがさっきなんだけど,これで様子見ということにしよう。もし,今度同じようなことが起きたら,LC550をちょっと脱がしてHDD調べてみないといけないかなぁ。NECのノートって,HDDがホント見にくいよね。そう思いません?

追記:
 でも,結局なんで再起動が発生したのかはつかめなかった。上のでわかったのはあくまでも,再起動後,ntoskrnl.exeがロードできなかった件だけなのだ。