ブルースクリーンのエラーが毎回違うときは？原因をメモリまで絞り込む手順

パソコンが突然落ちる。青い画面が出て再起動する。しばらく使えていたのにまた落ちる。

こうなったとき困るのは、何を調べればいいのか分からないことだと思います。青い画面には英語のエラー名が出ますが、それを検索しても「ドライバを更新しましょう」「メモリ不足かもしれません」といった一般論ばかりで、自分のPCの話なのか判断できません。

この記事は、原因がまだ分かっていない状態から始めて、メモリの不良を1枚単位で特定するまでを書きます。特別な道具も費用も要らず、作業はほとんどコマンドを打つだけです。メモリが原因だと分かっている必要はありません。そこを判断するところから始めます。

まず、自分のエラーの種類を数える

最初にやるのはこれだけです。今までに何回落ちて、その内訳がどうなっているかを見ます。再起動は不要で、管理者権限も要りません。

Windows の検索から「PowerShell」を開いて、次を貼り付けます。

Get-WinEvent -FilterHashtable @{
    LogName='System'
    ProviderName='Microsoft-Windows-WER-SystemErrorReporting'
    Id=1001
} -MaxEvents 50 -ErrorAction SilentlyContinue |
  ForEach-Object {
    if ($_.Message -match 'bugcheck was:\s*(0x[0-9a-f]+)') { $matches[1] }
  } | Group-Object | Sort-Object Count -Descending |
  Select-Object @{n='停止コード';e={$_.Name}}, @{n='件数';e={$_.Count}} |
  Format-Table -AutoSize

筆者の環境ではこう出ました。

停止コード      件数
----------      ----
0x00000133        10
0x000001ca         3
0x0000007e         3
0x0000003b         2
0x0000001a         1

ここの読み方が、この記事のいちばん大事なところです。

同じ理由で、青い画面に出るモジュール名が毎回違うことも、ドライバ説を弱める材料になります。壊れている番地が毎回違えば、そのとき使っていたものが名指しされるだけだからです。

散らばり方の実例

筆者の環境では、累計50件が次のように散らばっていました。上のコマンドは直近50件を数えますが、より長い期間の記録を見るとこうなります。

11種類が、互いに関係のない領域に散っています。ここまで散ると、ひとつひとつのコードを検索して回っても答えにはたどり着きません。共通して使われている場所を疑う方が早い、という判断になります。

メモリを検査する機能は最初から入っている

追加のソフトは要りません。Windows にはメモリ診断という機能が標準で入っていて、検索欄に「メモリ」と打つと候補に出てきます。存在を知らないことが多いのですが、これが一番手軽な確認手段です。

診断は動くが、結果の数値は画面に出ない

実行すると再起動し、テストが走り、終わるとまた起動します。テストの項目数は起動後の画面で選べます（初期値は標準）。

起動すると通知が出ますが、そこには数値がありません。イベントビューアーで見ても本文は同じで、エラーを検出したかどうかしか分かりません。

必要な数値は、イベントの構造化データの側に入っています。管理者権限は不要です。

Get-WinEvent -FilterHashtable @{
    LogName='System'
    ProviderName='Microsoft-Windows-MemoryDiagnostics-Results'
    Id=1101,1102
} -MaxEvents 10 | ForEach-Object {
    $r = ([xml]$_.ToXml()).Event.UserData.Results
    [pscustomobject]@{
        実行時刻   = $_.TimeCreated.ToString('MM-dd HH:mm')
        判定       = $r.CompletionType
        容量MB     = $r.MemorySize
        テスト数   = $r.TestCount
        所要秒     = $r.TestDuration
        不良ページ = $r.NumBadPages
    }
} | Sort-Object 実行時刻 | Format-Table -AutoSize

ID を 1101 と 1102 に絞っているのは、同じ内容が別の ID でも記録されるもののそちらには数値が入っていないためです。絞らないと空の行が混ざります。

なお、テストごとの内訳も同じ場所にあります。どの項目が不良を見つけたかまで分かるので、モードによる差を確かめたいときに役立ちます。

8回分の実測

上のコマンドで実際に出力された記録です。テストのたびに構成を変えて、どのモジュールが原因かを絞り込んでいます。

実行2で挿し直しても結果が変わらなかったので、接触不良の可能性はここで消えました。実行3で4枚から2枚に減らしても同じ不良数だったので、4枚挿しという構成そのものが原因という説も消えました。

単体テストの合格は弱い証拠

ここが今回いちばん意外だった点です。実行3から5を並べます。

• 2枚同時（AとB）: 不良 7 ページ
• A 1枚だけ: 不良 4 ページ
• B 1枚だけ: 不良 1 ページ
• 1枚ずつの合計: 5 ページ

2枚で7、1枚ずつだと合計5。2つ足りません。

考えられる理由は、複数枚を挿したときのアドレスの割り当てが変わることです。2枚構成では書き込み先が2枚に交互に振り分けられるため、同じ記憶素子が1枚構成とは別の番地に現れます。境界ぎりぎりで成立している素子は、2枚構成のときだけ落ちることがあります。メモリ制御側の負荷が構成によって違うことも効いている可能性があります。

実務上の意味ははっきりしています。1枚ずつ試して全部合格でも、2枚挿すと落ちる個体があり得ます。だから最終的に使う構成でのまとめ確認は省略できません。上の表で実行8を長いモードで回しているのはそのためです。

合格と不合格は対称ではない

もう1つ、モードの選び方に関わる発見です。同じ4枚に対して、

• 12項目のテスト: 不良 8 ページ（3,602秒）
• 2項目のテスト: 不良 7 ページ（248秒）

短いモードは1つ見逃しています。ここから次のように使い分けられます。

切り分けの型

手順そのものは単純です。変える条件を1つに絞ることだけを守ります。

1. 電源ケーブルを抜き、電源ボタンを数秒押して放電する
2. 1つのスロットだけを使い、そこに挿すモジュールを入れ替える
3. 起動してメモリ診断を短いモードで実行する
4. 結果を上のコマンドで読む
5. 全モジュールについて繰り返す
6. 最後に、実際に使う構成で項目数の多いモードを1回実行する

2番目が要点です。スロットを固定すれば、スロット側の不良とモジュール側の不良が混ざりません。モジュールを挿す位置を毎回変えると、結果がどちらに由来するのか分からなくなります。

不良が1枚とは限らない

上の記録では、AとBの2枚とも不良でした。この2枚は連番で、同じ時期に同じ製造ロットから入ったものです。

1枚見つけた時点で「原因はこれだ」と考えて止めると、もう1枚が残ります。症状は軽くなるので直ったように見え、しばらくしてまた出ます。

同じロットのモジュールは、同じ時期に同じように劣化します。1枚不良が出たら、残りも同じロットかどうかを確認してください。型番の末尾や製造時期で見分けられることがあります。

やってしまいがちな、意味のない確認

切り分けの途中で、大きなファイルのハッシュ値を何度も計算して一致するかを見る、という確認を試しました。結論から言うと、これは証拠になりません。

518MB のファイルを6回計算して全部一致しましたが、

• 1回あたり約1.8秒で、合計でも11秒ほど
• 単一のスレッドで動く
• 2回目以降はディスクではなくファイルキャッシュから読んでいる

つまり実際に触れたメモリはごく一部で、しかも毎回同じ領域です。これで合格しても、別の領域に不良があることは否定できません。実際、この後の診断で不良が確定しました。

確認は「どれだけの範囲に、どれだけの時間触れたか」で価値が決まります。速く終わる確認ほど、触れている範囲は狭いと考えてください。

よくある質問

メモリ診断で合格したら、メモリは無実ですか

短いモードの合格だけなら、まだ断定できません。項目数の多いモードで、かつ実際に使う構成で合格していることを確認してください。それでも合格するなら、疑う対象を電源や保存領域、発熱へ移していくのが順当です。

停止コードが1種類に集中している場合はどう考えますか

その場合はドライバや特定の機能を疑う方が筋が良いです。この記事の判断材料は散らばっているかどうかです。集中しているなら、名指しされているモジュールと、その機能を使う操作から追ってください。

診断中に電源が切れたらどうなりますか

次回起動時に結果が記録されないだけで、システムは壊れません。もう一度実行すれば済みます。ただし診断中は保存されていない作業が失われた状態なので、実行前に保存を済ませておくことだけは守ってください。

交換するとき、同じ製品を買い足すのと全部入れ替えるのはどちらがよいですか

全部入れ替える方が確実です。残す側も同じロットなら、近い時期に同じ症状が出る可能性があります。また、異なる時期の製品を混ぜると、動作条件が合わずに別の不安定さを招くことがあります。予算が許すなら、使う枚数を一度にそろえる方が切り分けも楽になります。

1つの結果で、すべての症状を説明できますか

できるとは限りません。原因が見つかったときほど、その原因では説明できない記録が残っていないかを確かめてください。説明できない記録があるなら、別の要因が並行して存在している可能性があります。1つ直したあとも、しばらくは同じ記録を見続けるのが安全です。

まとめ

停止コードが散らばり、名指しされるモジュールが毎回違うなら、ドライバではなく土台を疑います。

• Windows メモリ診断の数値は通知にも本文にも出ない。イベントの構造化データを読む
• 1枚ずつの合格は弱い証拠。2枚で7ページ、1枚ずつだと合計5ページだった
• 不合格は決定的、合格は決定的ではない。短いモードは見逃す項目がある
• 切り分けはスロットを固定して、モジュールだけ入れ替える
• 不良は1枚とは限らない。同じロットの2枚が同時に壊れていた
• 速く終わる確認は、触れている範囲も狭い。合格の重みは所要時間に比例する

最後に使う構成で、項目数の多いモードを1回。ここを省かないことが、やり直しを防ぐいちばん確実な方法です。

参考リンク

• PCが重いとき、買い替え前に見るべきポイントは？
• Antimalware Service Executableが重いまま下がらない原因を特定する方法
• SE・プログラマー向けPCの選び方は？
• メモリは何番のスロットに挿す？2枚・4枚の位置と向き、容量違いを混ぜるときの条件
• Kernel-Power 41はクラッシュとは限らない｜停止コードと電源ボタンの値で原因を読み分ける