起きて，朝食にしようと思ったら，ご飯ができていなかった。「ありゃー，タイマーセットし忘れたか」と思ったが，炊飯器が生暖かい。どうやら，早朝に停電があったらしい。うちの炊飯器には，停電後に自動的に炊飯を続けてくれるなんぞというシャレた機能はついていない。
速やかに，スイッチを入れた。
朝食後，ネットにつながらないのに気付いた。 UPS はないので，当たり前のようにサーバはダウン状態だが（←すみません，これも忘れてた），ネットにつながらないのは自鯖とは関係ない。ルータが復帰できてなかった。設定しなおしたら，物理的には壊れていなかった。
今（午前 9:16），もとどおり。よかったぁ。
追記(12/13)：
本日朝も停電があった。今回は，ルータはパスワードの件も問題ないので，電気が戻ったら，復旧していた。しかし，サーバは２時間弱落ちていたと思う m(_”_)m。
電力会社のいうところでは，小さな地絡事故らしい。で，今のところ場所は確定できていないとのこと。ということは，近々またあるかもね (溜息)。
前に， WordPress3.7 から追加された ca-bundle.crt のことを記事にした。
これについては，英語ブログのほうで， Oiram が有用な情報をコメントしてくれた。もし，同じ注意 “注意: https://MySiteName の更新の際、問題が発生しました。サーバーがサイトに接続できないかもしれません。エラーメッセージ: SSL certificate problem: self signed certificate in certificate chain” が出る方がいたら， “Error upgrading WordPress (SSL) PDF版” にある彼の回避策を試してみてください。「 ca-bundle.crt に自分が使っている CA の ルート証明書情報を書き加えてやる」という方法です。
改めて考えてみると，うちの場合は， Oiram のところと少し事情が違っていたように思う。自鯖ではいまだに彼の回避策を使っていないのだが， WordPress3.7.1 にアップデートしたときは注意が出なかったし， SSL 認証もその後は問題なく動いている。
自鯖の環境が特殊だから，彼の場合とは事情が異なるのかもしれない。
というわけで，いまだに以下の２つを疑問に思っている。
追記(11/9)：
英語ブログのほうで， Oiram から，新たなコメントをもらった。彼も，７つあるサイトのうちのひとつについてのみ，「注意」が出たそうだ。彼の場合は， 3.7.1 でも同じように出たらしい。で，彼は SSL 認証が自動アップデートに関連しているのではないかと考えているようだ。彼の言う autoupdates が，新しくできたバックグラウンドのものを指しているのかどうかは，確認していない。前からある自動アップデートのことだったら，うちの場合， SSL 認証とは関係ないことがわかっている。日本語版が更新ページに現れないのは， SSL 認証を使い始める前からの話だからだ。しかし，話の流れからして，多分，新しいバックグラウンドでのアップデートの話だろうと思う。
3.7.1 のときに，新しいバックグラウンドでのアップデートを試してみるつもりだったのだが，うっかり，ボタンをポチッとやってしまったので，次回は忘れずに試すつもり。一応，更新時のサイトのメッセージでも， Background Update Tester でも，バックグラウンドでのアップデートは可能になっていた。
追記２(2014/1/30)：
１月３日以来 Oiram のサイトに接続できない。 ca-bundle.crt で検索して来られる方もおられるので， Oiram が書いてたものを PDF 版で載せておく。「Error upgrading WordPress (SSL)」
追記３(5/6)：
今日ようやく久しぶりに， Oiram のサイトに接続できた。
追記４(6/22)：
WordPressでの「SSL3_READ_BYTES:sslv3 alert handshake failure」を解決というのを書いた。
本日，知人のところに行ったら，デジカメ（Canon IXY 430F だったようだ）の SD カードが読めなくなったという。よくある話で，プリントアウトしたもの以外はバックアップを取っていないという状態。プリントするのは人にあげるためだから，本人の手元にはないわけで，ものすごくショックのようだった。そういうわけで，見かねて預かってきた。
帰ってきてから PC に差し込んでみたら，「フォーマットしてください」が出る。しかし，ある意味，これで安心した。物理的には壊れてないようだから。
単純なデータ復旧には，いつも，復元（RESTO428.zip）を使ってきたんだが，今回，ふっと色気を出して「SD カード フォーマットしてください データ復旧」でググッて見た。まぁ，いっぱいあるねえ。やっぱ，よくあってみんな困ってることなんだなぁと，妙に納得してしまったよ。
で，いろいろめっかったフリーソフトを２つ試してみた。というか，１つ目はウームという状態だったので，２つ目も試したということ。
はじめは， diskdigger.zip 。このソフト， exe 単体で使えて，インストール不要。よかったんだけど，ファイル名が復旧されずに，セクタ名で表示されちゃってネ。しかも，復元力が強力なのはいいんだけど，半端なファイルもすべてサムネイルで見せてくれるので，取捨選択が煩雑になりそうだったので， Give up 。なんせ， 1000 枚近く見つかったもんでさ。
で，２つ目には， zar92setup.exe を試してみた。これは，インストールが，必要。実のところ，このソフトも，ファイル名が， jpg 付きで表示されたのを除けば，似たような復旧状況だった。つまり，やはり 1000 枚近くファイルが表示されたってこと。しかし，人間て，デジカメ画像の復旧ファイルに jpg 拡張子がついただけで，なんとなく安心するんだよね（爆）。
まぁ，２ソフトとも似たような結果だったから，この２つでお試しはやめて，ファイルの保存に移った。たった， 8GB の SD カードだったんだけど，全作業に，２時間くらいかかった。一番手間を食ったのは，保存したファイルのうち，まともでないのを削除する作業。まともでないやつの中に，１枚 6GB を超えるとんでもないのがあったが，エクスプローラの特大アイコンとしては，ちゃんと画像が表示されたから，多分， SD カード上にあったときからこの状態だったのだろう。もしかしたら，このとんでもないののせいで，デジカメ本体もカードを読めなくなったのかもしれないな。
ところで，このソフトについては， 「SDカード復旧方法」というすごく丁寧な使い方ページを発見した。それほど，使い方の難しいソフトではないけれど，ここまで丁寧なチュートリアルはありがたいですねぇ。自分のカードじゃないから，どのくらいの割合復旧できたのかは，今のところ不明だけど，時系列で考えると，多分，90% くらいは拾えたのではないかと思う。
washo さん，お世話になりました。ありがとうございます。
ここのところ，ちょっとネットラジオづいていて，しばらく止めていた配信を復活させた。
この新しいサイトで，ダッシュボードのメニューの動きが悪い。例のNoScriptのサイトの一覧に，gravatar.comというのがあって，ソースを調べてみると，<script type=’text/javascript’ src=’http://s.gravatar.com/js/gprofiles.js?ver=2012Octaa’></script>が挿入されている。
しかし，こんなものを挿入した記憶がなかった。( gprofiles.js?ver=2012Octaa) って，こんな奴らしい。「スワッ，マルウェア!!」とは思わなかったが，気になって調べてみたら，犯人は，Jetpackの「Gravatar ホバーカード」だった。Jetpackはかなり前から利用しているが，親ブログのBBS以外はアバターは使わない設定にしてるし，何よりこやつを有効にした記憶がない。
「Gravatar ホバーカード」を停止にしたら，挿入されていたタグは消えたけど，困るなあ，こういうの。まぁ，マルウェアじゃなくてよかったけど，勝手に挿し込まれたこれが汚染されてたりすると，困ったことになる。手動で確認してから「有効」にしたからって，大丈夫って保障はどこにもないけど，それでも，知らないうちに動いてるというのは，どうもねぇ。まあ，パソコンなんてそんなんばっかりと言えば言えるが……ブツブツ。
投稿アップデート情報 追記(6/22) 追記２(6/28) 追記３(6/28) 追記４(7/2)
この間から，気になっていたPHP Warningがあった。
PHP Warning: Illegal string offset ‘total_users’ in ～¥update.php on line 67
というやつで，一番初めは３月５日，２度目は４月11日で，あとはチョクチョク起こっている。日付から考えてPHPのバージョン関係だろうなあと思っていたが，前回ググったときは，何も探し出せなかった。今回，
Illegal string offset ‘total_users’というのを発見した。読んでみるとどうやらこれ関係のようである。
で，これに余計なコメントを付け加えた後で，記事をじっくり読んだら，こんなのがあった。Inconsistent Variable Usage。おまけに，20966.diffがあって，workaroundが書いてある（汗）。余計なコメントは間違ったことを書いたわけではないが，書かなきゃよかった。時間も経過しているので，削除もできない。せめて，20966.diffを当てた結果チェックしてから書けばよかったなあ。この頃こんなんばっか。
で，このPHP Warningだけど，上記の２つのスレッドを読んでみると次のようなことらしい。
WordPressがユーザ数を調べるのに，マルチサイトとシングルサイトで違う関数を使っていることが混乱のもと。PHP5.4未満では問題が顕在化していなかったが，PHP5.4からemptyの仕様が変わったせいでWarningが出るようになった。empty関数の挙動変更の「5.4.0 文字列のオフセットに非数値を指定した場合は TRUE を返すようになりました。」というところに起因しているようだ。emptyの「例2 文字列のオフセットに対する empty()」を参照。
放っておいても大した影響はなさそうだと安心したが，一応workaroundはやってみた。この次のUpdateのときにPHP Warningを確認してみよう。
追記(6/22)：
昨日，プラグインをひとつアップデートしたが，PHP Warning: Illegal string offset ‘total_users’ in ～¥update.php on line 67 は出なかった。workaroundは役に立っているようだ。
追記２(6/28)：
６月27日，Illegal string offset ‘total_users’にEric Mannさんから，次バージョンでこの件は修正されるという連絡があった。同日，WordPressについてver.3.4.1へのマイナーバージョンアップがあったが，これにおいては，update.phpは何も変更されていない。次バージョンというのは，ver.3.4.xであるとしてもメジャーアップデートの場合，あるいは，ver.3.5を指していると思われる。
追記３(6/28)：
Illegal string offset ‘total_users’でのcogmiosさんの報告によれば，Illegal string offsetは出なくなった模様。update.phpへの対症療法ではなく，coreでの解決のようだ。うちの場合，例の言語の関係でWordPress本体の自動アップデートが出来ないので，今のところ未確認。
追記４(7/2)：
今日，利用しているプラグインのうちの一つでアップデートがあったので，update.phpを使った。確かに，Illegal string offsetはでなくなった。Good Job!! — >> WordPress3.4.1。
一昨日，２週間ぶりくらいで勝った鷹が，昨日も勝った（喜）。今日は月曜日だが，交流戦の変則日程で試合があるので，勝ってほしいな（祈）。
第４弾は切りづらくてバカ長くなってしまった。読みづらいこと甚だしいが，今のところ書き直す元気がない。だって，夕べまた，臨時サーバの調子が悪くて，おいでいただいた方のアクセスを別場所にとばして，弄っていたのだよー。このノートも本当に厳しい状態になってきた。やっぱり，ハードディスクかなあ。しかし，多少腑に落ちないところもある。何とか，サーバを帰宅させるまでは，LC550にがんばってもらいたいんだが……
ところで，転載分のFHさんの掲示板の話を読むと，自分の考えや皆さんの提案の紆余曲折が分かって面白い。あとになって振り返ってみれば，「あれは，違っていたなあ」と思うこともあるが，リアルワールドで，ゴチャゴチャ話しながらすると，ひょいと考えもしなかったようなことを思いつくことがあるのに，似たところがある。これが複数で当たることのよさ。昔から「３人寄れば文殊の知恵」というではありませんか。みなさま，ありがとうございました。
本家のお世話-#39。での，誤差確認を経て，皆さんの意見も「やはりちょっと温度が高すぎるようだ」と言うところに落ち着いた。また，xw4200の内部の構造から考えて，「ふたを開けて稼働させても，あまり冷却効果は上がらないだろうと思う」というjuneさんからのお話もあった。実際，xw4200のふたを開けて連続稼働してみたが，さして冷却効果は増さなかった。
しかし，私はここでちょっと脇道にそれた。本筋と全く関係ないわけではないのだが，Pen4のHyper-Threading Technologyの話が出てきて，サーバ機ならそっちの方が温度にもよさそうだというので，試そうとしたのだ。juneさんが，「セットアップとトラブルシューティング」の「3.7 Hyper-Threading 技術を有効にする(22ページ)」に書いてあるやり方を調べてくださったのだが，あとから考えるとこの説明書の記述が若干違っていた。「Device Options （デバイスオプション）」のところにあるという記述に引きずられて，ハマってしまったが，Hyper-Threadingの項目は，結局，「電源投入時オプション」のところにあった。いつものことながら，自分の思い込みにはあきれてしまう。ホント，困ったもんだ(爆)。
まぁ，最終的には達成できて，図１のように，デバイス・マネージャ上にCPUが２つ表示されるようになった。それから，xw4200には MAS3367NP がついていたが，このSCSI Diskの温度が，HWMonitorでもEverestでも測れていなかった。SCSI DISK対応のフリーソフトをネット上で探した。他にもあるのだろうが，HDDScan（HDD-SCANとは別のソフト）というのがあったので測ってみたが，朝一の電源投入直後，室温より４℃も低い17℃で，どうも，あんまり当てにできない。（転載Part4です。）
さて，ここに至って，チョクチョク C0000218 エラーが出るようになった。これが，xw4200の中をもう一回掃除し，使っていないIEEE1394のボード（AFW-2100）を外したりした後だったので，その辺に原因があるのかと思ったのだが，あとから考えると本家のお世話-#34。に書いたように， MAS3367NP がご臨終寸前だったらしい。しかし，この時点ではそんなことはわからないから，悪あがきもしてみたけど，
C0000218エラーのメッセージが，ハード関係でなく出ることもあるらしいということにすがって（何かソフトですむ手がありそうだと，そっちに走ってしまうのが常。リアルワールドでも，そうです。 <<--- なんちゃって。），CentOS6をインストールしてしまった。で，それでやれやれ起動するようになったワイと喜んでいたら，Disk Read Errorが出るようになった。改めて，前とは別方法で地道に MAS3367NP を調べてみたら，すごい数の不良セクタが見つかったわけだ。
SCSI DISKは MAS3367NP だけしか手持ちがないから，この際，ボード（LSI Logic LSI20320A-R Ultra320）も込みで外してしまった。
Maxtor 6Y160M0を整理して，CentOS6をインストールし直すことにしたのだが，そのためには，データの入ったままのMaxtor 6Y160M0のパーティションを，切りなおさないといけない。どういう訳か，この間利用したGparted-live0.12.0-5では起動できなかったので，たまたま手元にあった，Knoppix 5.1.0のLiveCDで起動し，該当のパーティションを切り直した。Knoppix 6.7.1でも起動できなかった。今回はその辺が目的ではないので細かく調べていないが，なんでだろう。
Knoppix LiveCDのGpartedをGUIで使用しようとするとrootのパスワードを要求されるので，Gpartedの使用前に，rootのパスワードを設定する必要がある。
コンソールを立ち上げて，
su
でrootになり，
passwd
と打つとパスワード設定画面になるので，使いやすいパスワードを設定する。このパスワードは，Knoppix LiveCDのこのセッションが終われば破棄されるので，使いやすいわかりやすいもので構わない。あとは，GUIでGpartedを起動し，普通通りパーティションを切りなおす。この作業は，CentOS6のLiveCD(i386)でも可能なのかもしれない。
ところで，xw4200はx64にも対応しているらしいが，メモリも2ギガしか積んていないし，x64関係をインストールするとどうなるかもよくわからないので，今回使ったものは，SCSI DISKに入れたのも，空けたパーティションにインストールしたのも，理研ミラーから落としたCentOS-6.2-i386-bin-DVD1.isoとCentOS-6.2-i386-bin-DVD2.isoだ。手順はWindows7 HP 64bit SP1+CentOS6のデュアルブート-#2。を参照。実は，「Minimal Desktop」のインストールだと，CentOS-6.2-i386-bin-DVD2.isoは必要ない。また，Hyper-Threading Technologyについては，「セットアップとトラブルシューティング」の「4.3 Hyper-Threading 技術を有効にする(28ページ)」に「Linux システムでは最新のシステムBIOS とSMP カーネル が必要です。」という文言があったが，インストール前にBIOSでHyper-Threading 技術を有効にしておけば，何も問題は生じなかった（インストール後 less /proc/cpuinfo をやってみたら，cpuが2つ表示された。 <<--- cpu情報を表示させるコマンド，終了は「q」キー）。BIOSについては，今回のドタバタの間に，メーカサイトからver.01.09 Rev. a (15 7 2005)を落としてアップデートしている。ずいぶん古い日付だが，xw4200の公式BIOSとしては，これが最新のようだ。 再起動する。 ようこそ画面で基本情報設定後，作ったばかりの一般ユーザでログイン。すぐに，端末を立ち上げてrootになり，yum update する。 ≪注意≫この後しばらくは端末上のrootでの話です。
hostsファイルを編集して，現サーバに接続できるようにする。
gedit /etc/hosts
と打つ。自宅サーバのIPv4を追加して保存。
wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.i686.rpm
rpm -Uvh rpmforge-release-0.5.2-2.el6.rf.i686.rpm
インストール直後のCentOS6には，fuse-ntfs-3gが入っていないので，
yum install fuse-ntfs-3g
でこれをインストール。デスクトップから，データエリア内のパーティションを開いて読み書きを試してみる。できた。
Driver `lm90′:
* Bus `nouveau-0000:01:00.0-2′
Busdriver `drm’, I2C address 0x4c
Chip `National Semiconductor LM89/LM99′ (confidence: 8)
—————————————————————————–
≪注意≫ここでrootをexitします。
端末でsensorsとやって測定。大したデータ取れず。以下のとおり。しかも，どっちがどっちか分からないorz。
smsc47b397-isa-0480
Adapter: ISA adapter
fan1: 2898 RPM
fan2: 0 RPM
fan3: 0 RPM
fan4: 1535 RPM
temp1: +60.0°C
temp2: +0.0°C
temp3: +41.0°C
temp4: +0.0°C
hddtempでも測ってみた。ほんとかいな。今室温25℃なんだが。
# hddtemp /dev/sda
/dev/sda: Maxtor 6Y160M0: 39°C
HDDTEMPを自動起動するアプリに登録する。コマンドの欄には，hddtemp -d /dev/sda を記入する。ここで，OSを再起動。先の参考ページにはログインしなおすと書いてあるのだが，それではだめだった。
パネルにGNOME Sensors Appletを追加する。パネルを右クリックして，［パネルへ追加］を選択し，［パネルへ追加］ダイアログボックスから［Hardware Sensors Monitor］を選択して［追加］ボタンをクリックする。［Preferences］や［Configure Sensor］を自環境に合わせて，設定する。この辺が，転載Part5になる。
さて，このあとFHさんの掲示板を読み直していて，扇風機で冷やしてみるということをまだやっていなかったのに気づいた。なにしろ，次から次へと問題が起こったので。<<--- 言い訳（汗）。やってみなくてはということで，冷やしてみた。結構，冷えたねぇ。
fan1: 2202 RPM
fan4: 1249 RPM
temp1: +53.0℃
temp3: +30.0℃
/dev/sda:Maxtor 6Y160M0: 30℃
それと，このときの副産物として，ほぼ同じものを測定していると思っていたtemp3と/dev/sdaは，まったく違うものを測っているらしいことが分かった。temp3が何を示しているのかは，はっきりしないままだが。
この辺で，juneさんにAMIBIOSのHealth Statusを教えていただいたので，その関連でBIOS項目を見直していた。そして，システムファンのアイドル段階を手動ではあるが，７段階も変更できるということを初めて知った（大汗）。
で，これを7段階の５番目（「低 <-- １２３４(５)６７ --> 高」）にしてみたら，
fan1: 4026 RPM
fan4: 2671 RPM
temp1: +49.0°C
temp3: +36.0°C
/dev/sda: Maxtor 6Y160M0: 36°C
すごい。なんで５番目かというと、７番目だと，単に，ものすごーくうるさかったので（爆）。
FHさんから，「夏場に設定”７”で無事通過できればイイですね。」というレスをいただいて，長かった「FHの掲示板」での相談を終えた。最終 —>> 転載Part6です。
本当に，お世話になりました m(_”_)m。
本家のお世話-#35。の最後に書いたように，運よくグリスのことを思い出したので，FHさんのところで相談して，買いに行ってきた。腕が悪ければ，何を使っても同じかとも思ったが，逆に腕が悪いからいいものの方がましかという思いもあって，その店で一番高かったArctic Silver 5というシルバーグリスを買ってきた（爆）。
グリスを塗るのに，もう一度シンクも外してよく見たら，まだ埃が見られたので，ついでにエアダスターで飛ばしておいた。エアダスターは，グリスと一緒に店で買ってきた。
|
グリスの除去は，どういうわけか家にあった消毒用のエタノールで行なった。まぁ，そこそこきれいになってるよね（図１）。で，要領もうかがったので，グリスを塗り直して再固定した。この辺，転載Part2をお読みください m(_”_)m 。 ここから，話は温度になってくるのだが，掲示板でのやり取りを見てると，ホント迷走してるねぇ。そのほとんどの原因は，私がサーバ機のハードウェア・スペックをちゃんと把握していなかったことにあるんだが（爆）。 実は，PCの温度を真剣に測ったことが，あんまりない。使ってきたPCは主としてノートタイプだったので，温度の改善としては，もともとついているチルトを使って傾けるとか，台に載せて底面に風が通るようにしてやるくらい。まぁ，ファンの掃除というのもあるだろうけど，ノートの場合，ファンまでたどり着くのも結構大変だし。 連続稼働後に測った記録画像が図２だ。これは，上段がHWMonitor，下段がEverestのものである。 ここで，温度測定ソフトの誤差がどのくらいかという話になって，一晩電源を落としてPCをしっかり冷やしたのち，朝一で電源投入直後の温度を測ってみた。これが右の図３になる。 |
図１
 図２  図３  |
この温度の話は，転載Part3あたりになるので，よろしく。
朝起きて（臨時）サーバを見たら，ブラックアウトしているはずのモニタ画面に，何やら白い字が浮かんでいる。「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，ヘルプページの保守が悪いんじゃないの!?」他のメーカとは比べ物にならないくらい巨大なアーカイブだということはわかるけど，もうちょっとどうにかしてほしいヨ。
この順でインストール。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がロードできなかった件だけなのだ。
あー，参った。
青画面が出まして（臨時サーバのほうです），その手当てのために，昨日(5/31)の17:00くらいから22:30頃まで，自鯖を落としていました。なんかこのところ，エラーづいてるなぁ（泣）。
出たエラーメッセージは，以下のもの。29日に続き２度目だったので，少し地道にお手当てを。
|
A problem has been detected and Windows has been shut down to prevent damage to your computer. KERNEL_STACK_INPAGE_ERROR If this is the first time you’ve seen this stop error screen, Check to make sure any new hardware or software is properly installed. If problems continue, disable or remove any newly installed hardware Technical information: *** STOP: 0x00000077 (0xC000000E, 0xC000000E, 0x00000000, 0x********) Beginning dump of physical memory |
KERNEL_STACK_INPAGE_ERRORでググってみると，「Windows XP ベースのコンピューターでエラー メッセージ “Stop 0x00000077” または “KERNEL_STACK_INPAGE_ERROR” が表示される」というのがあった。
一応の手順としては，方法1から方法3があるが，まず，方法1（最新の Service Pack をインストールする）は関係なし。方法3（ウイルスチェック プログラムを実行する）も多分関係ないと思ったが，MBRも含めて一応やってみた。特に何も見つからなかった。ここまで書いてきたことで分かると思うが，青画面後の起動はなんの問題もなかった。ということで，方法2をやることになるわけだが，これは要注意。もし，HDDにでも異常がある場合は，Chkdskが致命的な事態を引き起こしかねない。で，これをやる前に，システム全部のバックアップを先にやった。手持ちの古めのTrueImageでバックアップできたので，不良セクタはないかもしれないと思った。
それと，上記リンクページの詳細に，
というのがあった。しかし，ひどい訳だね。英文のままの方がマシなんじゃないの。もうちょっとどうにかならんのか —> MS。
さて，chkdsk /f /r。これ，結構な時間がかかった。多分，異常があるからだろうと思っていたのだが，無事終了した後のログを見たら，
|
Checking file system on C: The type of the file system is NTFS. Volume label is Volume_Label. A disk check has been scheduled. 32812730 KB total disk space. 4096 bytes in each allocation unit. |
ということで，bad sectorsは0だけど，Cleaning up minor inconsistencies on the drive.が出ている。chkdsk /fをかけてみた。２度目のログは以下のとおり。
|
Checking file system on C: The type of the file system is NTFS. Volume label is Volume_Label. A disk check has been scheduled. 32812730 KB total disk space. 4096 bytes in each allocation unit. |
うーん，原因は何だろう。やっぱりそろそろ，HDDを疑ったほうがいいのかなぁ。HDD-SCANでは，正常。CrystalDiskInfoでは，注意と出た。微妙なところかな。注意を怠らないようにしないと。日々，バックアップに努める（爆）。
|
4/14（日）に臨時サーバにしてから，ずっとうっちゃらかしだったもともとのサーバ機の手当てに，5/6（日）から漸く取り掛かった。話の順序としては，本家のお世話-#34。の前のことになる。
FHさんのところで，「（この際，ついでですから）ぜひ，CPUクーラーのお掃除を」という提案をいただき，重い腰を上げてサーバ機（DU936AV）のカバーを開け，掃除を始めた。 プロセッサ・ファンの埃はかなりのものだった。当たり前かもしれないが，ファンとヒートシンクの間にものすごくたまっていたので，シンクごと取り外して掃除機で吸い取った（図１）。このときは，グリスのことは念頭になく再固定した。 何はともあれ，症状から電源のことが気になっていたので，電源ファンもきれいに掃除した。その後，電源を入れてみたら，なんと，電源ファンが全く回っていない。FHさんに伺ったら，シール（図２）をはがしてミシン油を注したらいいということだったので，ミシン油を買ってきて注してみた。教えてくださったとおり，中にゴムキャップがあった。油を注してから一晩おいて再度電源を入れてみたら，電源ファンは元気に回りだした（図３）。 |
図１
 図２  図３ |
ここに至って，ふと，グリスのことが思い当った。我ながらよく思い出したもんだ（爆）。