Windowsの強制終了の原因を調べる | .NET Framework 2.0 と C#での開発ブログ

Windowsの強制終了の原因を調べる

今回は開発とあんまり関係ないお話です。(ドライバとか作る時には大いに関係あるけど)
私はWindowsについて深く調べようと思ったことはなく、ちょっとしたハードウェアの知識と勘でPCの不具合に対応?してきました。たとえば音がでないからサウンドカードがおかしいのかなぁ~とか、モニターになにも表示されないからモニターかビデオカードが壊れたのか?とかそんな端的な診断です。咳と鼻水がでるから風邪か?みたいな感じです。まあ、大体あってますけどね。

でもそのやり方だと原因不明の障害が沢山ありますよね。最近ではあまりみなくなった
ブルースクリーンのストップエラーとか何が書いてあるかほとんどわかりません。
何もしてないのにいきなり強制終了とかまったく予想つかないです。
ハードウェアの追加直後とかだったらなんとなく予想できるんですけどね。
ちなみに原因不明の調子悪いのはちょっとの経験により適当に全部ハードディスクの問題だと決め付けてきました。だからハードディスクの交換はちょくちょくしてたっけ、、、
消耗品だからしょうがないよ~とかいいながら、、、これっておばちゃんがテレビを叩いて直すのとあんまり変わらないっすよね、、、今度PC叩いてみよう、、、でもね、ハードディスクの交換で直ること多かったんですよ~ ( <- 言い訳W )これからも原因不明はやっぱりハードディスクの問題だと思うことは変わらない気がするし、、、

現在私の家には常時稼動しているWindows PCが3台あるのですが、困ったことにそのうち2台が原因不明の強制終了をたびたび起こしています。うち1台は一日の1回程度は何もしなくても勝手に強制終了してくれます。

ということで昨日は休日でしたので、ちょいと調べてみました。といってもソフトがですけどね。

まず、最初に強制終了の頻度が高いPCから取り掛かりました。
もう、OSの再インストールから開始です。
↑強制終了でOSの再インストールとかPCの買い替えとかしてしまうところが自分の知識が無いゆえの無駄なんでしょうね~~~。無駄無駄無駄 オラオラオラ
まあ、再インストールで解決することもよくあるので、今まで大して気にしてなかったのですがどうも今回はそうでもないみたい。とりあえずOSの再インストールは出来たのですがそこに大きなソフトをインストールすると途中でかならずブルースクリーン(Win2000)がでてきてしまいます。まあ、これで今回の再インストールが無駄だって証明されました。
(今気がついたのだけど、今までPCの調子が悪いんだけど、、って相談して来てくれた知人の方たちにとりあえず再インストールして。って言ってた自分に超反省、、、すみません。ごめんなさい。でも直ったっしょ?)

今までならここで挫折してたのですが、今回はもうちょいがんばってWindowsのデバッグ情報を解析してみます。Windowsのデバッグ情報というのはディスクトップ上にあるマイコンピュータを右クリックしてプロパティ(システムのプロパティ)の詳細設定>起動と回復の画面にあるシステムエラーのグループで設定できるやつです。ここのデバッグ情報の書き込みのところでダンプを取る設定があるのでそれをお好みに変更すればOKですが、私レベルだと最小メモリダンプで十分すぎます。っていうか情報あってもわかりません。
(尚、イベントビューアにて原因が特定できる場合もあるようですが、私の場合はわかりませんでした。そもそもイベントビューアはよくわからない)

今まで知らなかったのですが、「Debugging Tools for Windows」という便利なツール郡がMSから提供されてました。そのなかに「WinDbg」というデバッガがあります。これを使えばある程度ことはわかるそうです。少なくても私でも原因場所はわかりました。なんかとっても敷居が高そうな感じではあるのですが、、、まあ、とりあえず言われた通りやってみるくらいだったらできるかなぁ~程度で十分だと思います。
別に使いこなす必要はなく原因を知りたいだけですから。ってことにやってみて初めて気が付きました。気合の問題かな。

「WinDbg」の使い方ですが、ネットで調べればそこそこ情報があります。ただ、情報がちょっと錯乱してる感もあるので、ここでは私が成功した方法をご紹介します。

まずは、「WinDbg」のインストール。 (Windows2000/XPの場合)
------------------------------------------------------------------------
Debugging Tools for Windows 32 ビット バージョンのインストール
http://www.microsoft.com/japan/whdc/devtools/debugging/installx86.mspx

------------------------------------------------------------------------
ここから最新版をゲットしてインストールしてください。
本当はさらに
------------------------------------------------------------------------
Windows シンボル パッケージのダウンロード
http://www.microsoft.com/japan/whdc/devtools/debugging/symbolpkg.mspx

------------------------------------------------------------------------
から必要なシンボルをあらかじめ入れておけばOKなのですが、これは「WinDbg」の設定でなんとかなるみたいなので私は入れませんでした。

次に「WinDbg」を起動して、File > Symbol Search Pathを開きます。
そこに
------------------------------------------------------------------------
SRV*C:\WINDOWS\SYMBOLS*http://msdl.microsoft.com/download/symbols;
------------------------------------------------------------------------
上記のように記入して完了。
これは必要なシンボルを取得してC:\WINDOWS\SYMBOLSのフォルダに入れてくれるそうです。詳しくはわかってないのですけど、これで動きました。
私はここではまって、色々試した結果がこれでした。もしシンボルが無いってエラーがでたら検索して色々試してみることをお勧めします。

次にFile > Image File Pathを開き
------------------------------------------------------------------------
C:\WINDOWS\system32;C:\WINDOWS
------------------------------------------------------------------------
こんな感じで追加します。これはWindowsXPの設定なのでWindows2000だと上記の[WINDOWS]のところが[WINNT]になればOKだと思います。(場合によってはC:も変わるかも)
これはOSのシステムフォルダをとりあえず設定しているのですが、デバッグの内容によってパスを追加してあげる必要があります。[Unable to load image]というエラーがたら大抵ここの設定が必要と思えば良いと思います。また、これはOS側のデバッグ情報の最大ダンプですと色々情報が含まれているそうですので、この辺が楽らしいです。(試してません)この辺は環境や無いようによって変わるとおもいますので、色々お試しください。

以上が完成したら、次はやっとダンプファイルを読込みます。
File > Open Crash Dumpを選択し、MiniDumpファイルを読み込みます。
これの保存場所は最初にデバッグ情報を設定したところでわかります。
私の場合(Windows XP)の場合ですと[%SystemRoot%\Minidump]となっており、
[C:\WINDOWS\Minidump]にファイルがあります。これで最新のファイルを読込みます。

あとはCommandウィンドウに色々情報が出てくるのでエラーが出ないように祈りながら、待ちます。エラーがでたらその内容にしたがって直してください。私は大抵シンボルの問題かイメージの問題でしたので、上記のパスの設定でなんとかなりました。
成功すると最後のほうに
------------------------------------------------------------------------
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D0, {0, 2, 1, 8046be74}

Probably caused by : ?????????????? <- "ここに原因が表示されます"

Followup: ??????????????
---------
------------------------------------------------------------------------
こんな感じで結果が表示されます。このときに[!analyze -v]を実行すればさらに詳細な情報が表示されます。あとはこの情報を使ってWeb検索で色々調べます。
ちなみに私はメモリ関係の可能性が大きかったのでメモリから調査を始めました。

すると今度はさらに便利なツールを発見。その名を「Memtest86」。知ってる人は知っている一品っすね。初めて知りました。なんで今まで知らなかったんだろう。
「Memtest86」はメモリを詳細にチェック(診断,テスト)するための無料のツールです。
Windows上で動かすのではなく、このソフトをフロッピーとかに入れて起動するタイプです。使い方は簡単で
------------------------------------------------------------------------
Memtest86 - A Stand-alone Memory Diagnostic
http://www.memtest86.com/

------------------------------------------------------------------------
上記からダウンロードしたものを解凍します。次にフォーマット済みのフロッピーディスク(CD ROMでもOK)を用意し、先ほど解凍したファイルの「install.bat」を実行します。
するとどこに入れるか聞いてくるのでフロッピーディスクでしたら大抵が[a]を入力してエンターで完成。あとはこのフロッピーディスクを入れたまま再起動すればメモリチェックが始まります。(ブートドライブにフロッピーディスクドライブが入って無いと駄目ですね)
このソフトの使い方はよくわかってないのですが、あんまりわかる必要もない気がします。
というのも画面上半分はハードウェアの情報と現在のテストの進行状況が表示されます。
そして残りの画面下半分はエラーが発生したら赤いラインでどんどんエラーが追加されています。すなわちエラーが表示されなければOKって感じで私にとっては十分でしょう。

私は3枚 256Mのメモリを使っていたのですが、まずは3枚とも挿した上体でテスト。
おおおおおう、画面半分がまっかっかだ。エラーの嵐だ。
ということで原因はメモリで決定です。(もちろんほかの原因も重複してる可能性はありますけどね)
次は一枚ずつ挿してテストです。1枚2枚と順調に進んで問題なかったので、あれ?と思っていたのですが、3枚目をやったとたん狂ったように真っ赤。血の海です。ってか全てがエラーなんじゃないか?って感じですね。(尚テストは#4までしかやってません)
とってもわかりやすく不良メモリを発見できたので、あとはそれ以外の2枚を挿して再度テスト。望みどおりエラー無し。よしよし、いい感じ。ってなことで見事正常になりました。今までだめだった大きなファイルのコピーとかインストールとかが問題なく出来るようになり、強制終了も今のことろ起きてません。オールオッケー!

この時に知ったのですが、原因不明の不安定な症状はまずメモリを疑えとのことです。
へぇ~~、しらなかった。私はメモリが壊れたら起動しないもんだと思ってました。
そして、3枚のメモリのうち一枚が壊れててもWindowsがインストールできて、それなりに動いてしまうってことにちょっと感動。すげーなぁー。
ということで皆さんもPCが不安定になったら一度Memtest86を使ってみるのがいいかもしれません。
ちなみにこのソフトはハードウェアを販売してるところでも結構使われているらしく、例えば初期不良とかでMemtest86でテストして駄目でしたと伝えると、大急ぎで丁寧に交換してくれるそうです。なので新しくメモリを買った時もMemtest86でチェックすることは原因究明の為にも返品の為にも大切ですね。今後は私もそうします。

最後に、残ったもう一台のPCもデバッグ情報から調べたらサウンドドライバが原因でしたのでとりあえずアップデートして様子見です。

以上、こんな感じでデバッグするとたまにはいいことあるかもね。