&HFFFF。

　Opera10.10が使用中にハングアップ。強制終了してから再度起動すると、直前のセッション復元は開始されるものの途中のタブで表示が更新されず１〜２分応答しなくなってしまうようになった。
　強制終了と再起動を繰り返すが改善せず、ディスクキャッシュの削除を行ったがやはり改善しない。
　最新版のOpera10.61をアップグレードインストールしたが、起動時に自動読み込みされる既存セッションのデータが破損しているのか状況に変化がない。
　急ぎの仕事がある時にこれか…。
　かつてマーフィは「急いでいることをマシンに悟られてはいけない」と言った。
　悟られてしまった間抜けな俺は、仕事にならないのでCHKDSK /rを仕掛けて帰宅。
　今日になっても当然ながら状況は変わっていなかった。TaskmgrでプロセスのCPU占有状況を見ると、ハングアップ時に"System"が80〜90%と高負荷になっている。
　こういうのは大抵はI/O周りと相場が決まっている。ディスクか、あるいはメモリか。
　Opera以外のアプリケーションでの不具合を疑ってProcessHackerなどで詳細を調べてみるが、Systemが高負荷であることは確認できるが、どのモジュールが高負荷の原因になっているのかは判然としない。System配下で動作しているモジュールのうち、ウイルスバスターコーポレートエディションのリアルタイム検索モジュール"NTRtScan.exe"がやや高負荷になっているが、それでも20%台でSystem全体の高負荷を説明することができない。
　見えていないいずれかのプロセスの不具合なら調べるのにさらに時間がかかるものと思われたので、先に破損した疑いのある既存セッションファイルを潰すつもりでOperaのセッション保存フォルダC:\Document and Settings\ユーザ名\Application Data\Opera\Opera\sessionsを見る。
　ここに、昨日の障害発生時刻に生成されたopr????.tmpファイルが65,535個あるのを発見。65,535個だから当然ファイル名はopr0000〜oprFFFFとなっている。
　これらの.tmpファイルがOperaのタブオープン・クローズ時にどういう役割を果たすのかは不明だが、Operaがまともに動作しているなら、セッション・タブそれぞれの処理時に65,535個のファイルを同時に操作することは考えにくい。バグかセッションファイル作成時のクラッシュに伴い発生したものだろう。というかゴミファイルが8の倍数-1個という時点で明らかに不具合の痕跡にしか見えない。
　試しにexplorer.exeで普通にこれらのファイルを一括選択・削除しようと試みると、当然のごとくexplorer.exeはハングアップ。
　プロセス"System"の高負荷もこのファイルI/Oの高負荷が反映されたもので、Operaが長時間ハングアップするのもファイルI/Oの応答待ちだったわけだ。
　WinFDにて全て削除した結果、Operaが正常に起動するようになったことを確認。