本家のお世話-#37。（Operating System Not Found）

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

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

　「まぁ，これも勉強だから」ということで，ダンプファイルの解析をしてみることにした。以下の４ファイルをダウンロードした。しかし，このダウンロード，かなりブロークンリンクが多くて，正しいところに行きつくまで手間取った。「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+でやってみた。そしたら，２枚のモジュールのうち１枚で，何度やっても１カ所だけだけどエラーが出る。しかし，このHDDとmemoryの健康診断に，時間のかかることかかること。終わったころには，疲れ果てて，もう逆さに振ってもやる気が出ない。

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

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