MBAM + ataport.sys でブルースクリーン(BSOD)――原因究明から解決までの完全記録

このブログを長年読んでくださっている方ならご存じのとおり、筆者はセキュリティソフトがあまり好きではない。しかし、実際の挙動を確かめるためにはテストするしかない。そうした実験のおかげで、各社のソフトを比較・評価できるし、Windowsセキュリティ界の「黄金のベンチマーク」であるEMET(最も優秀で、実用的で、無駄のないツール)との比較も可能になる。

さて、数ヶ月前、Windows 7マシン上でMalwarebytes Anti-Malware(MBAM)によるスキャンを実行したところ、スキャンの途中でブルースクリーン(BSOD)が発生した。これはまずい。復旧後、筆者は大規模な調査を開始することになった。以下、その顛末をお付き合いいただきたい。

前提となる環境と追加情報

何が起きたのかを探る前に、いくつか補足情報を整理しておこう。これがないと議論が空転してしまう。まずBSODについてだが、一般的にWindowsは家庭環境では極めて安定しており(サーバーは別の話)、Windowsカーネル内部のバグによって致命的なクラッシュに遭遇することは、まずあり得ない。

筆者自身、約15年にわたって十数台の異なるシステムでWindowsをヘビーに使ってきたが、BSODに見舞われたのはわずかに数回だけだ。グラフィックカードの過熱によるもの、バグだらけのグラフィックドライバーによるもの(これは以前詳しく取り上げた悲しいエピソードだ)、そしてスマートフォンをUSBケーブルで接続した際の一度。それくらいである。

つまり先ほどの主張に戻ると、カーネルクラッシュが起こるのは基本的にハードウェア障害か不良ドライバーが原因であり、これは筆者の使用履歴とも完全に一致する。Linuxでの長年の経験(別途、Linuxクラッシュに関する書籍にまとめている)とも符合する。要するに、ハードウェア、不正なシステムコール、あるいは純粋なカーネルバグ。それだけで、最後のものが最も起こりにくい。

ところが今回は、ataport.sysというドライバーが絡む問題に直面した。これはMicrosoft製のドライバーであり、本来バグなど持たないはずのものだ。では、ハードウェアの問題なのか? だとすれば、どんな種類の問題なのか? ただし、慌てて結論に飛びつく前に、問題解決とはゆっくり、慎重に、体系的に行うべきものであることを強調しておきたい。

分析 ―― 最初の一歩

それでは、何が起きたのかを理解していこう。BSODの分析方法については、すでに詳細なガイド記事で紹介している。そのチュートリアルで紹介したツールのひとつ、NirsoftのBlueScreenViewを使ってクラッシュダンプを解析したところ、クラッシュの原因は次の通りだった。

ataport.SYS+1ff3c

具体的なエラーはKERNEL_DATA_INPAGE_ERROR。メモリダンプ内の他の引数を確認すると、カーネル操作中のハードウェアエラーを示しており、それが不可避的にシステムクラッシュにつながったことが分かる。ここまでは単純だ。

なぜMBAMのスキャン中にクラッシュしたのか?

ここが興味深いポイントである。次のどちらなのかを突き止める必要がある。

• この問題はMBAMに固有のものなのか
• それとも、たまたまスキャン中に表面化した、より汎用的なシステムの問題なのか

どちらが正しいかを確定するには、クラッシュ時の状況を再現する必要がある。追加情報として、対象マシンはWindows 7で、EMET以外のセキュリティソフトは導入しておらず、TrueCryptコンテナをマウントしていた。これは重要な要素だ。TrueCryptもストレージ層のドライバーを使用するソフトであり、今回の事象に影響を与えている可能性があるからだ。

そこで2回目のスキャンを実行した。すると今度はシステムはクラッシュせず、TrueCryptコンテナをマウントしたままでも問題なかった。ただし、イベントログにはEvent ID 11として次のエラーが記録されていた。

ドライバーは \Device\Ide\IdePort1 上のコントローラーエラーを検出しました。

この種のエラーを見るのは初めてであり、MBAMスキャンとのタイミングの一致も興味深い。新たな情報が手に入った今、調査の次の手を考えなければならない。

コントローラーエラーの意味

このエラーを検索すると、同じ疑問を持つ人々による大量の投稿が見つかる。結局のところ、原因は大きく3つに集約される。SATAケーブルの不良、ディスクの不良、あるいはチップセットコントローラーの不良(=実質的にマザーボード交換)である。かなり不吉に聞こえる。しかし、問題がMBAMスキャン中にしか発生していない以上、孤立した事象なのか、システム全体の問題なのかを見極めねばならない。

分析 ―― システムの健康状態

そこで筆者は、ハードウェアチェックを含む複数のレベルでマシンの状態を確認することにした。注意してほしいのは、100%の確信は永遠に得られないということだ。ある検査で問題なしと出ても、技術的には翌日にハードウェアが死ぬ可能性もある。したがって、これらの検査に安心や保証を求めることはできない。確認できるのは、「現時点では、少なくともベストケースとして、より広範な問題を示唆する症状はない」ということだけだ。

• ディスクのSMARTチェック:異常なし
• WD Data Lifeguard Diagnosticsのチェック:異常なし
• 上記の問題以外、システムは極めて安定している
• その他の問題は一切発生せず、 incident後1週間経っても同様

何か手を打ちたい衝動を抑え、筆者はあえて何もせず、丸1週間コンピューターを稼働させ続けることにした。重いIOを伴うゲームを大量にプレイしたり、データバックアップ、システムイメージの作成、Windows Updateなど、負荷の高い作業も含めてだ。これらすべての「暗黙のテスト」において、システムは数ヶ月前、数年前と変わらぬ予測可能な挙動を示した。

この時点で、少なくとも統計的・直感的な判断としては、ハードウェアに差し迫った健康上の問題はないと結論づけた。こうなると、問題の原因はMBAMにあると考えるのが自然だ。そしてそれは、「クラッシュするのは決してWindowsではなく、常に何か別のものが引き金になる」という筆者の経験ともよく一致している。

MBAMへの追加調査

次に、このセキュリティソフトに焦点を絞る。ネットで検索すると無数の投稿が見つかり、主なテーマは次の3つに繰り返し現れる。a) マルウェア感染(当然ながら、セキュリティソフトの動作を妨害し、この種のクラッシュを引き起こすトロイの木馬など) b) MBAM 3ではクラッシュするがMBAM 2ではしなかったというユーザーの報告 c) TrueCryptとの非互換性がBSODにつながる可能性。

筆者はこれらの仮説を実際に検証してみることにした。まずc)についてだが、かつては問題だったかもしれないが、現在では確実に起きていない。筆者の経験では、常時TrueCryptボリュームをマウントしてきたが、それが原因でクラッシュしたことは一度もない。

a)についてはナンセンスだが、いくつかの推奨対策を試して確認することにした。もちろん、当てはまらなかった。さらに重要なことに、MBAMはその後のスキャンをBSODなしで完走したものの、該当するコントローラーエラーは記録されていた。これにより、問題の範囲はソフトウェア側に絞り込まれた。

MBAM + Event ID 11

これでようやく、的を絞った情報検索ができるようになった。公式フォーラムにはわずかな数の投稿しかなく、その内容は筆者のケースと非常によく似ていた。何人かのユーザーがクラッシュを経験し、その原因がMBAMとIntel Rapid Storage Technology(RST)ドライバーの衝突だと突き止めたのだ。なるほど。筆者は最新の対応ドライバーをインストールして再起動した。その過程でいくつかの発見があった。

• ドライブレターが乱れていたため、正しく割り当て直す必要があった
• ケース前面のディスクアクセスランプの点滅頻度が以前より減った(SATA Link電源管理を有効化していないにもかかわらず)。視覚的な錯覚かもしれないし、実際にディスクポーリング活動が減ったのかもしれない。システム指標には大きな違いは見られない
• 新しいドライバーにより、ごくわずかな性能向上が得られた

そして、改めてMBAMの新規スキャンを実行したところ、一切の問題なく完了した。イベントログにエラーも記録されていない。つまり、これはサードパーティ製ソフトウェア同士の衝突が引き起こした問題であり、Microsoftの責任でもハードウェアの故障でもなかったのだ。追記：他のMBAMユーザーの中には、MBAMのバージョンアップ後に問題が解消したという報告もある。

念のため断っておくと、判断できる限り、これらのエラーはWindowsや基盤プラットフォームが原因ではない。ユーザーが合理的な範囲でこれを突き止めるのは容易ではない。なぜなら、筆者の古いデスクトップPCでは、SMARTデータが完璧にクリーンだったディスクが何の予兆もなく突然死んだ一方で、「重大な問題がありディスク死亡間近のはず」とされた別のディスクは、エラーが出現してから何ヶ月も元気に生き延び続けたからだ(この件については別記事で詳述している)。統計は、裏切られるまで上手く機能するのである。

しかし実用上の観点では、この時点で、この場所で、これは100%MBAMの問題であり、ハードウェアとは無関係だった。低レベルのシステム権限を持つセキュリティスキャナーとストレージドライバーの衝突。問題は、なぜそんなことが起きるのか、だ。

果たして、なぜ?

MBAMのソースコードにアクセスできない以上、確定的なことは言えないが、筆者には一つの理論がある。マルウェアは、さまざまな巧妙な手法を使ってディスク上に自身を隠そうとすることがある。その一つの方法が、システムに偽のI/Oドライバーを使わせ、ディスクがクリーンであると報告させることだ。つまり、マルウェアスキャナーは、システムの標準関数が返す値を必ずしも信用できない状況に置かれる。

筆者は、MBAMが独自のディスクアクセス関数(コントローラーコマンドを含む)や、シーク、読み取り、リンク解除などのシステムコール・関数を独自に実装しているのではないかと考えている。何らかの理由で、これらのコマンドの一つがIntel RSTと衝突し、I/Oエラーが発生、システムがそれをコントローラーエラーとして解釈した。結果としてBSODやイベントログへの記録につながった、というわけだ。これはあくまで筆者の推論であり、間違っているかもしれないが、筋は通っている。

さらなる学び

システムが決して故障しないと保証することはできないのだから、むしろ故障を前提に計画すべきである。言い換えれば、痛みを伴う瞬間を受け入れ、それが訪れたときに最小限の損失で素早く復旧できるよう備えておくのだ。例えば筆者は、常に予備のハードウェアを手元に置いており、新品のハードディスクも2〜3台はストックしている。

また、データのバックアップとシステムイメージの作成も怠らない。こうすれば、ハードウェアを交換する必要が生じても、すぐに生産性のある状態へ復帰できる。実際、数ヶ月前、別のデスクトップPCで突然のディスク故障に直面したこともあったが、問題ない。約1時間以内に作業を再開でき、データもシステム設定も一切失わなかった。

最後に、問題解決は体系的に行うべきだという話をしたが、これこそがトラブルシューティング、特にハードウェア・ソフトウェア問題の本質である。正しく行えばミスを犯す可能性が下がり、時間とお金を節約できる。闇雲にいろいろ変更を加えるのは決して良いアイデアではない。このテーマについては、筆者は一冊の本も執筆している。

結論

これは、多くの要因が絡み合った難しく複雑な問題だった。ある時点では、ハードウェア障害の可能性が複数の方面から浮上し、TrueCrypt、マルウェア、ソフトウェアのバグがすべて容疑者として名を連ねていた。これを解決するのは容易ではない。それでも、粘り強く慎重な作業によって、問題を完全に理解し、根本原因を切り分け、各仮説を検証し、潜在的な解決策をテストすることができた。しかも、劇的なシステム変更は一切なしで、だ。

これは貴重な教訓だと思う。筆者自身の体験ではあるが、ぜひ読者の皆さんにも持ち帰ってほしい知見である。何か悪いことが起きると、インターネットはゴミのような情報を浴びせてくる。ハードウェア故障だ、マルウェアだ、好きな方を選べ、という具合に。誰もがあなたと同じ問題を抱えているかのように語りながら、実際には微妙に状況が異なり、そのまま当てはまらなかったりする。このやり方では頭がおかしくなりかねない。他人の対処法を片っ端から試したくなる誘惑は強い。しかし、最善の道は、症状を非常に注意深く観察し、徹底的に分析した上で、修正を適用することだ。しかも、可逆的で、完全に定量化可能な修正を、最も単純で侵襲性の低いものから順に。

今回の問題も、まさにそのアプローチで進めた。何が起きたのか分かっているか? 再現できるか? 新たに得られた情報は筋が通っているか? 考えられる原因を検証できるか? 一部を排除できるか? 残った候補に対して、新たな検索ラウンドへ。新しい主張、新しい仮説、新しいチェック。明確で再現可能な結果。解決。知識。そして楽しさ。この記事が楽しんでもらえたなら幸いだ。忘れないでほしい。Windowsを安易に責めず、自分のハードウェアについてインターネットが語る内容には懐疑的であれ。世の中はすべて破滅と絶望のように見えるが、必ずしもそうである必要はない。それでは、快適なコンピューティングを。

それではまた。