Error Log

例のアイスコーヒーが出てきた建物でやっていた結合試験での話です。

「頻繁に『ページを表示できません』になる」という故障票があがってきました。しかし、開発環境ではどうやっても再現しません。「こっち(開発環境)では発生しないぞ～」って返そうとした矢先に、とある話を思い出したのでした。試験者に「画面を表示してから1分以上まってから送信して、再現するか確認してみて」と頼んでみたところ、「再現しなくなりました～」という返事。ビンゴ。

直接原因は Internet Explorer の不具合で、

• サーバ側で HTTP/1.1 の Keep-Alive を有効にしている
• Internet Explorer よりもサーバの方が Keep-Alive Timeout までの時間が短く設定されている
• 画面表示後、サーバの Keep-Alive Timeout 時間に達したが、Internet Explorer の Keep-Alive Timeout 時間(60秒)には達していないタイミング

を条件を満たした状態で画面遷移すると、https の接続もせずに「ページが表示できません。(サーバか見つからないか、または DNS エラー)」の画面になる(KB305217)というものです。

さらに、画面遷移の代わりにファイルアップロードフォームを送信すると、タイミングによって、POST データの無い POST リクエストを送る(KB831167)という、極悪な現象まで発生します。サーバ側たでは、標準入力からデータを読み込もうとしたが最後、300秒間身動きがとれなくなります。

最初見たとき、この現象にはかなり驚かされましたが、もっと凄いのはサポート技術情報に書かれている「回避策」の1つに書かれている「サーバの Keep-Alive Timeout を長くする」というもの。1分以上にすると確かに発生しなくなるんですが、これは自殺行為です。仮にサーバの最大同時接続数を100として、10秒ほどで100接続受け付けた場合、最初の Keep-Alive Timeout が発生する 50秒の間、101つ目の接続が受け付けられなくなります。


今回は Apache httpd で Web サーバを構築していたので、「Internet Explorer からの接続は Keep-Alive を無効にする」という設定で回避しました。

SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

… というのはApache のマニュアルページにしっかりのっているし、デフォルトで用意される SSL の設定ファイルにしっかり書いてありました orz

今の勤務地にきてから Windows Update ができなくなっていた・・・というのが11月の月例アップデートの時期に発覚してました。「更新を確認しています」画面で "0x80072EE2" エラーが発生するのです。再現率 100%。

エラー番号で検索すると、KB(Windows Update でエラー番号 0x80072EE2 が表示される場合の対処方法)が見つかりましたが、ここにかいてある対処方法が無茶苦茶だったりします。プロキシ相手に HTTP/1.1 をしゃべらせたり、プロキシ無視にしたり、挙げ句の果てにファイアウォールのせいにする。Windows Update のサイトが見えている時点で、いずれも対応策も的を外していませんか？？

・・・どうせ外に出られないので、3ヶ月ほど放置していました。

最近、仕事に余裕が出てきたので本腰を入れて調査したところ、「更新を確認しています」画面の裏側で、Windows Update がダイレクト接続で https をしゃべろうとしていました。

今の勤務地では、常駐先の方からは、各自プロキシサーバのアドレス・ポートを入力するように指示されています。… 大量のプロキシ無視リスト付きで。面倒なので、自前で pac ファイルを作成し、IE・Opera・Firefox のプロキシ設定に file スキーム(file://～) で指定していました。これで、3つのブラウザが同じプロキシサーバとプロキシ無視リストを共有でき・・・Windows Update は無視してくれているようですが。

一旦、エラー番号 "0x80072EE2" をみなかったことにして、pac の設定が無視される現象として検索をしたところ、KB の(自動構成スクリプトの指定方法によって Windows Update が失敗する) を見つけました。Windows Update は Internet Explorer とは別の HTTP 実装(WinHTTP)を利用していて、WinHTTP では file スキームの pac を無視するんだとか。

自端末で Apache を稼働させていたので、pac を UserDir 配下に置いて、IE・Opera・Firefox のプロキシ設定に http スキームで指定しなおしました。Windows Update は見事に成功。3ヶ月分の更新を一気にインストールしました。

一方で Opera が pac 解析中に Syntax Error を起こしてしまう問題が発覚。pac は Shift_JIS で書いていて、Apache は Content-Type をつけずに pac を返していました。Opera はこれを UTF-8 と見なして解析していたようです。試しに、pac を UTF-8 で保存し直したところ、Opera は Syntax Error を起こさなくなりましたが、今度は IE と Firefox が Syntax Error。泣きそう。。。

Opera だけ file スキームで指定するのもいやだったので、ある意味で「正しい」対応をしました。Apache 側で「Content-Type: application/x-ns-proxy-autoconfig; charset=Shift_JIS」を出力するように、AddType と AddCharset を追加。これで Opera の Syntax Error も回避できました。ちゃんと charset パラメータを見てくれてるんですね。

IE を起動し Web ページを閲覧していると、2・3回目の画面遷移でハングアップする。
… そんな現象に遭遇しました。(僕の PC じゃないです。他の人の。)

閲覧しようとしたページがブラウザクラッシャーという訳でも無く、また特定のページでもないのです。
さらに、閉じるボタンで表示される強制終了ダイアログを使って強制終了をしても、IEXPLORE.EXE のプロセスが残り続けるというおまけ付き。

IE が(控えめに言っても)出来の悪いブラウザであることは百も承知なのですが、さすがにこれは尋常ではありません。
Web ページが表示できないって、それは Web ブラウザとは言わないでしょう。

「もしかすると、IE が何か遺言を残しているかもしれない」とイベントビューワを見ると、「…(省略)… \Local Settings\Temp\History\index.dat への書き込みができなかった」といった内容の遺言を発見。なんとなく、画面遷移履歴の保存に失敗しているようです。
脊髄反射的にスキャンディスク(の不良セクタスキャン)を開始すると、index.dat が使用してた箇所に不良セクタが見つかりました。ビンゴ。スキャンディスクが自動的に index.dat の待避を行い、それ以降、IE のハングアップ現象は回復しました。

しかし、よりよって、IE が利用しているファイルに不良セクタができるとは。。。
もし、脊髄反射が IE の再インストールだったら、index.dat の物理位置が変わったりして、直ったように見えるんでしょう。「再インストールで復活」伝説再び、これはこれで面白いのですが。


ちなみに、その PC は噂の Burning Dell ノートです。
バッテリの製造番号は対象ではなかったので、実際には Burning ではないですが、Burning 騒ぎ以降はバッテリを外して使っています。
それでも表面温度は群を抜いて熱いのです。夕方には使っている人がゆであがってる…。

イベントログに最初に不良セクタが報告された日は、試験用の重ためのツールを初めて利用し、業務時間のほとんどは %CPU 100 の状態、という日でした。
ということは、不良セクタができた原因は、、、やはり熱でしょうねぇ。。。