レイ・ブラッドベリ（Ray Bradbury）が亡くなりましたねぇ。91歳だった。
華氏451度 (Fahrenheit 451)，火星年代記 (The Martian Chronicles)なんかが有名だか，ウは宇宙船のウ (R Is for Rocket)や10月はたそがれの国 (The October Country)などの短編や何かが道をやってくる (Something Wicked This Way Comes)がなつかしいネ。
カテゴリー
投稿者: o6asan
本家のお世話-#35。の最後に書いたように，運よくグリスのことを思い出したので，FHさんのところで相談して，買いに行ってきた。腕が悪ければ，何を使っても同じかとも思ったが，逆に腕が悪いからいいものの方がましかという思いもあって，その店で一番高かったArctic Silver 5というシルバーグリスを買ってきた（爆）。
グリスを塗るのに，もう一度シンクも外してよく見たら，まだ埃が見られたので，ついでにエアダスターで飛ばしておいた。エアダスターは，グリスと一緒に店で買ってきた。
|
グリスの除去は，どういうわけか家にあった消毒用のエタノールで行なった。まぁ，そこそこきれいになってるよね（図１）。で，要領もうかがったので，グリスを塗り直して再固定した。この辺，転載Part2をお読みください m(_”_)m 。 ここから，話は温度になってくるのだが，掲示板でのやり取りを見てると，ホント迷走してるねぇ。そのほとんどの原因は，私がサーバ機のハードウェア・スペックをちゃんと把握していなかったことにあるんだが（爆）。 実は，PCの温度を真剣に測ったことが，あんまりない。使ってきたPCは主としてノートタイプだったので，温度の改善としては，もともとついているチルトを使って傾けるとか，台に載せて底面に風が通るようにしてやるくらい。まぁ，ファンの掃除というのもあるだろうけど，ノートの場合，ファンまでたどり着くのも結構大変だし。 連続稼働後に測った記録画像が図２だ。これは，上段がHWMonitor，下段がEverestのものである。 ここで，温度測定ソフトの誤差がどのくらいかという話になって，一晩電源を落としてPCをしっかり冷やしたのち，朝一で電源投入直後の温度を測ってみた。これが右の図３になる。 |
図１
 図２  図３  |
この温度の話は，転載Part3あたりになるので，よろしく。
投稿アップデート情報 追記(2013/2/14)
php5ts.dllのクラッシュによる再起動は完全になくなったわけではないので，Win版ApacheとPHPのおニューが出たときにはアップデートするように心がけているのだが，PHPはあまりに早く対処すると怖いという経験がある。それに，ハードの不具合でバタバタしていたせいで後回しになっていたが，本日遅ればせながら，PHP5.4.3(May-08 18:26:37UTC)にアップデートしてみた。Apache Loungeを見たら，httpd-2.4.2-win32-VC9.zip(May-14)もタイムスタンプが変わっているようなので，これも一緒に入れ替えることにした。
php5apache2_4.dll-php-5.4-win32.zipも実体は変わっているようなので落として展開してみたら，PHP5.4.3用のphp5apache2_4.dllが入っていた。危ない危ない。気づかなかったら，またハマるところだった。これを忘れずにPHPディレクトリに入れること。
Apacheのhttpd.confとphp.iniは前版と変更点がなかったので，そのまま利用した。もし，参考にされる方がいたら両方の設定については，本家のお世話-#28。を参照してください。
ついでに，MySQLもmysql-5.5.25-win32.msiにアップデートした。
追記(2013/2/14)：
php5apache2_4.dll でググって来られる方がおられるようなので，追記。 PHP5.4.10 から php5apache2_4.dll も PHP のオフィシャルバイナリに同梱されるようになりました。
投稿アップデート情報 追記(6/9)
まぁ，参っちゃいますねぇ。Microsoft 自身が発行した証明書が悪用されたらしく，その対応としてマイクロソフト セキュリティ アドバイザリ (2718704)が出ました。世も末じゃ。
自動更新にしていればもうパッチが当たっているはずですが，更新プログラムとして，KB2718704があるかどうか，一応確認してみましょうね。あったら，O.K. ない場合は，Microsoft Updateを利用しましょう。それでもうまくいかない場合は，Unauthorized digital certificates could allow spoofingに行って，自分のOSに対応するものをダウンロードしてインストールしましょう。英語のページですが，ダウンロードファイルそのものは，言語別になっているので，落とす前に，日本語にしてから落としましょう。
関係あるのは，
Microsoft Enforced Licensing Intermediate PCA (証明書 2 つ)
Microsoft Enforced Licensing Registration Authority CA (SHA1)
ということらしいので，結構あちこち影響あるのじゃないでしょうか。マイッタマイッタ（爆）。
追記(6/9)：
こういう悪夢の元だってことだよねえ。今回は，対象がちょっと別次元だったので，一般人はなんとか最悪のシナリオをまぬかれたってことらしい。
朝起きて（臨時）サーバを見たら，ブラックアウトしているはずのモニタ画面に，何やら白い字が浮かんでいる。「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，ヘルプページの保守が悪いんじゃないの!?」他のメーカとは比べ物にならないくらい巨大なアーカイブだということはわかるけど，もうちょっとどうにかしてほしいヨ。
- Windows XP Service Pack 3 x86 製品版シンボル、全言語
WindowsXP-KB936929-SP3-x86-symbols-full-ENU.exe のこと - .NET Framework 4
- .NET Framework 4 Full 日本語 Language Pack(x86)
- 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がロードできなかった件だけなのだ。
あー，参った。
青画面が出まして（臨時サーバのほうです），その手当てのために，昨日(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でバックアップできたので，不良セクタはないかもしれないと思った。
それと，上記リンクページの詳細に，
- 第 1 または第 3 のパラメーターのいずれかがゼロでない場合、以下の定義が適用されます。
- 状態コード
- I/O 状態コード
- ページ ファイル番号
- ページ ファイルへのオフセット <— ということで，ここだけが前回と違っていたのも納得。
- この場合、この問題の原因は、”第 2 のパラメーターの値” インジケーターの後に “一般的な原因” 形式がある以下の情報を使用することにより、第 2 のパラメーター (I/O 状態コード) から判別される場合があります。
- 0xC000000E または STATUS_NO_SUCH_DEVICE: 通常は不良なハード ディスク ドライブ、不良なディスク アレイ、または不良なコントローラー カードによりドライブが使用不可能。
というのがあった。しかし，ひどい訳だね。英文のままの方がマシなんじゃないの。もうちょっとどうにかならんのか —> 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さんに伺ったら，シール（図２）をはがしてミシン油を注したらいいということだったので，ミシン油を買ってきて注してみた。教えてくださったとおり，中にゴムキャップがあった。油を注してから一晩おいて再度電源を入れてみたら，電源ファンは元気に回りだした（図３）。 |
図１
 図２  図３ |
ここに至って，ふと，グリスのことが思い当った。我ながらよく思い出したもんだ（爆）。
カテゴリー
久しぶりにセキュリティネタ。
久しぶりに，セキュリティネタ。気になるネタはたくさんあるけど，何しろ我が身がテンヤワンヤなもので（汗）。
「DNS Changer」って知ってる？ リンク元の記事のように，昨年，一般のニュースでも逮捕の話がチラッとは上がっていたから，覚えている人もいるかもしれない。
で，FBIの運営しているネームサーバが7月9日に運用を終了する。前にも，終わるよ終わるよという話はあったが，今度は本当らしい。Googleさんも，対応を打ち出したようだし。自分のPCが感染していなければ関係ないけど，感染している場合は，「DNS Changer マルウエア感染確認サイト公開のお知らせ」の対策を参考に対処しよう。感染のチェックも一応，リンク先のJPCERT/CCのページで出来る。
ところで今日は今日で，すごいマルウェアの話を読んだ。「Flame」というらしい。あまり凄すぎて実感がないけど，まぁ，一般人の知らないところで，その種のものはどんどん開発されているということだろう。開発と実際に使われるまでにはタイムラグがあるからなぁ。
なんの技術でも，悪用しようと思えばできるから，人間の本性が変わらない限り根本的な解決にはならない。しかし，だからと言って知らん顔してればいいってものでもないから，難しい。
こっちは，情報が入ってきてから対処するくらいしかできないから，分析をしている方たちには頑張ってほしいです。よろしくお願いします。
サーバ機の清掃後，あまりに温度が高いように思えたので，デバイスの整理に入った。中古で購入したままだったので，使わないIEEE1394のボードとかも挿さったままだった。AirFlowを考えてケーブルなども整理した。このあたり，FHさんの掲示板でいろいろご指導いただいた。転載許可もいただいているので，お楽しみに!!
で，再起動したわけだが，OSが見つかりません状態になって焦った。このときは，SCSIコントローラのIRQが変わったりしていて，SCSIのことがよくわかっていないので，この辺が原因なのかなと思っていたのだが，BIOSを保存していたバックアップで前の設定に戻したりして，何とか再起動できた。おかげさまでこの辺でSCSIのことも大分勉強した（汗）。
しかし，何とも不安定で起きたり起きなかったりしているうちに，C0000218エラーが出るようになった。あちこちいじった後でもあり，その出方が不安定で本当にハマったのだが，みなさんのご教示には従わずOSの再インストールに走ってしまった。ハードをいじるのは苦手なもので，ソフトの不具合かなと思える節があればそちらに飛びついてしまう。
しかも，再インストしたのは，WindowsXPではなく，CentOS6の。どうせなら，LINUX Serverへの移行を早めてしまえと思ったのだ（爆）。そしたら，無事走らせられたのでやったねと思ったんだが，ちょくちょくREAD ERRORが出る。これ，DISKがつくこともあれば，つかない場合もあった。
それにそばにいると，HDDを読むのに一苦労も二苦労もしている感じの動きなのだ。DISK READ ERRORって，必ずしもおっしゃる通りというわけではないが，今回は素直にそれを疑った。OSが起動してくれないのに，どうやってそれを調べるかと思ったのだが，ふと，昔使ったHDD Regeneratorを思い出したので使ってみた。ちょっと古いしかもフリー版で，SCSI DISKを読んでくれるか心配だったんだが，ちゃんと調べられた。まー，すごい数の不良セクタ数だったね，ビックリ。しかも，直しても直しても再発するという感じ。修復やりかかったけど，あきらめちまったもん。それくらいすごい。
結局つまるところ，SCSI DISKのご老衰が原因だったということか。いろんな清掃や拡張ボードの変更に入る前に，chkdskとかをやるべきだったね。しかし，4/14のサーバダウンの前にも，その手のエラーメッセージは出たことがなかったので，疑いもしなかった。WindowsのC0000218エラーってなんだよ。素直に，DISK READ ERRORを出してくれよ!!まったく。壊れても仕方のない年数の経ったDISKであることは認めるよ，製造2004-12だもんね。
ここの至るまでのテンヤワンヤを，何回か続けて書いていきまーす（火暴）。
カテゴリー
本家のカレンダー-#2。
気づいたかたもおられると思うが，PHP 5.4.x 系にアップグレードしてから，ブログ（英語・日本語）の１行カレンダーの投稿日が表示されなくなっていた。気にはなっていたが，例の crash + restart のほうが問題で，そのままにしていた。
ブログのカレンダーについては，本家のカレンダー。にも書いたとおり，ずっと同じものを使ってきた。最初は，Movable Type，次は，WordPressで。今回の件に関して，プラグインの作者のページにお問い合わせも書いてみたが，長らくお返事がないので無理なのかもしれない。自分でスクリプトも見たが，お手上げ。
crash + restart が落ち着いてきたので，何か他に使えるプラグインがないかと探してみた。1行表示のカレンダー(「さかなのぺんぎん的日記」というサイトだったが，どうやらなくなったようで，2012/7/26からリンク切れが出るようになった。)というのがあった。対応バージョンは古くバージョンアップもされていないようだが，作者の方が「標準でついてくる get_calendar() というカレンダーを表示する関数の、HTML を書き出す部分をごにょごにょしただけのものです」と書いておられるので，かえって大丈夫かなと入れてみたら，無事動いた。よかった。
さかなさん，ありがとうございます。