中古GPUの増設やメモリ増設を行った直後から、Windowsの起動時にだけ「CRITICAL_PROCESS_DIED」「ATTEMPTED_WRITE_TO_READONLY_MEMORY」といったブルースクリーンが連発し、再起動を繰り返す――。そんな状況に陥ると、「GPUがハズレだったのか？メモリの相性か？セキュアブートか？」と原因が分からず途方に暮れがちです。本記事では、実際の事例をベースに、メモリ混在・GPU交換・セキュアブート有効化後に発生するブルースクリーンの原因を、具体的な切り分け手順とミニダンプ解析の方法まで含めて詳しく解説します。
症状の整理：起動／再起動時にだけ発生するブルースクリーン
まずは、ありがちな状況を整理しておきます。
- 中古のGPUを装着した
- UEFIでセキュアブートを有効化した
- 別キットのメモリ（例：8GB×2枚・定格3000MHzなど）を追加し、全てのメモリを3200MHzで動作させるようBIOSで設定
- 翌朝以降、Windowsが起動できず、修復モードへ移行したり、起動中に以下のブルースクリーンが出る
- CRITICAL_PROCESS_DIED（バグチェックコード 0xEF）
- ATTEMPTED_WRITE_TO_READONLY_MEMORY（バグチェックコード 0xBE）
さらに次のような特徴があることが多いです。
| 現象 | 観察された挙動 | この情報から言えること |
|---|---|---|
| CMOSクリア直後は起動 | CMOSクリア、もしくは新規メモリを抜くと一度は起動する | BIOS設定（メモリ周波数・タイミング・セキュアブートなど）の影響が濃厚 |
| 再起動時にだけ落ちる | 負荷テスト中は安定だが、「再起動」や「翌朝のコールドブート」でブルスク | 温度やGPU負荷よりも、起動時の初期化処理やドライバ・メモリ初期化が怪しい |
| メモリを2133MHzに戻すと安定 | オリジナルのメモリだけにし、2133MHz（JEDEC）に下げるとエラーが消える | メモリ混在＋オーバークロック設定が最有力 |
このように、高クロック設定＋メモリ混在時のみ不安定になる場合、GPU単体の不良である可能性は比較的低く、メモリ周り（相性・タイミング・電圧）や、そこに絡むUEFI設定・ドライバの組み合わせを優先して疑うべきです。
結論：最優先で疑うのは「メモリ混在＋設定（オーバークロック）」
CRITICAL_PROCESS_DIED は「Windowsの重要プロセスが異常終了した」ときの汎用的なブルースクリーンです。一方、ATTEMPTED_WRITE_TO_READONLY_MEMORY は「読み取り専用領域に書き込みを行おうとしたドライバ／コードがあった」ことを示します。どちらもメモリ内容が壊れていたり、不正なアドレスにアクセスしたりした結果として発生しやすいエラーで、次のようなシナリオと相性が良くありません。
- 異なるメーカーや定格のメモリキットを混在させている
- 定格3000MHzのメモリを含む構成で、全てを3200MHzに固定している
- XMP/DOCPプロファイルに従わない手動でのオーバークロックを行っている
このような環境では、同じ3200MHzでも各モジュールのタイミング（CL・tRCD・tRP・tRAS）や、内部構成（片面/両面、チップベンダー、ランク構成）がバラバラになるため、メモリコントローラにとっては厳しい条件になります。
実際に、周波数を2133MHz（JEDEC標準）に下げた途端に安定したのであれば、まずは「メモリ混在＋設定起因」と考えて切り分けを進めるのが合理的です。
原因候補と優先度：どこから潰していくべきか
典型的な原因候補と、それぞれを疑うべき状況は次の通りです。
| 優先度 | 原因候補 | こんなときに特に怪しい |
|---|---|---|
| 高 | メモリ混在・メモリOC設定の不安定 | メモリ追加後から不安定、周波数を下げると安定、メモリ構成を変えるたび挙動が変わる |
| 中 | GPUドライバやセキュアブート設定 | 中古GPU交換＋セキュアブート有効化のタイミングから不具合が始まった |
| 中 | UEFI/CSMとブート方式（GPT/MBR）の不整合 | CSMのON/OFFを頻繁に切り替えた、別PCからクローンしたSSDで起動している |
| 中〜低 | ブートファイルやシステムファイル破損 | SFCで大量に修復が走る、DISMでエラーが出る、突然電源が落ちた履歴が多い |
| 低（補助要因） | Ryzen Masterなどチューニング系ドライバの残骸 | 過去にOCツールを入れていた・アンインストールに失敗した形跡がある |
メモリ混在・メモリOCの切り分け手順（最優先）
まずは「メモリだけ」に絞って徹底的に疑いましょう。ここを曖昧にしたままGPUやストレージを疑い始めると、無限に沼ります。
同一キットだけに戻して動作確認する
最初に行うべきは、PC購入時から刺さっていたオリジナルのメモリキットだけに戻すことです。
- PCの電源ケーブルを抜き、電源ボタンを数秒長押しして放電する
- ケースを開け、追加したメモリ（別キット）をすべて抜く
- マザーボードのマニュアルに従い、オリジナルのメモリを推奨スロット（多くは2番・4番スロット）にセットし直す
- UEFI（BIOS）を開き、メモリ関連設定をすべて「Auto」または「JEDEC標準」に戻す
- XMP/DOCPは一旦無効にし、2133MHzまたは2400MHzで起動してみる
これで数回の再起動・シャットダウン／起動を行い、ブルースクリーンがまったく出ないのであれば、ほぼ間違いなく「メモリ混在＋OC設定」が主犯です。
メモリ周波数を少しずつ上げて「限界点」を探る
安定を確認したら、オリジナルキットだけを使って、周波数を段階的に上げていきます。
- 2133MHz → 2666MHz → 2933MHz → 3000MHz → 3200MHz…のように1ステップずつ
- 電圧は、メモリの定格（例：1.35V）からむやみに盛らない
- 上げるたびに、再起動を数回・軽いゲームやベンチマークなど簡単な負荷テストを行う
途中でブルースクリーンが出る／POSTに失敗するということは、その周波数がそのCPU＋マザーボード＋メモリの組み合わせでの限界に近いことを意味します。日常用途での安定性を重視するなら、限界一歩手前の設定に留めるのが無難です。
各メモリモジュールとスロットを個別に検証する
それでも不安定な場合は、モジュール単体またはスロット単位での不良も疑います。
- 1本だけ挿して起動テスト
- スロットを変えて起動テスト（A2→B2 など）
- 挙動が変わるモジュール・スロットがあればそこを重点的に疑う
特定のメモリだけエラーが出る、特定のスロットに挿したときだけ不安定になる、といった場合は、そのモジュールやスロットの不良の可能性があります。
メモリ検査ツールでのチェック
OSを起動した状態と、OSの外からの検査の両方を行うのが理想です。
| ツール | 起動方法 | 特徴 | おすすめの使い分け |
|---|---|---|---|
| Windows メモリ診断 (mdsched.exe) | 「Win + R」→mdsched.exe→再起動 | OS標準。簡単だがテストパターンは少なめ | 手軽な一次チェックに向く。これでエラーが出るならほぼアウト |
| MemTest86 | 公式サイトからUSB作成→USBブート | OSとは独立した環境で長時間テスト可能 | 新規メモリ購入直後や大幅なOC時に、数周〜一晩実施すると安心 |
MemTest86 で数周回してもエラーが出ないのに、Windows起動時だけブルースクリーンが出る場合は、メモリそのものよりも「起動時に読み込まれるドライバや設定」の問題を疑います。つまりここから先は、GPUドライバやUEFI設定、セキュアブートなどの切り分けに進みます。
GPU・セキュアブート・ドライバ周りの切り分け
GPUドライバのクリーンインストール
中古GPUを装着した場合、以前のGPUのドライバが残ったままだったり、署名の古いドライバがインストールされていたりすると、セキュアブート有効化をきっかけにトラブル化することがあります。
- Windowsをセーフモードで起動する
- Display Driver Uninstaller（DDU）などを使い、古いGPUドライバを完全に削除する
- GPUメーカー公式サイトから最新の安定版ドライバ（ベータ版ではなくWHQL版）をダウンロードし、再インストールする
再インストール後、何度か再起動やスリープ復帰を試し、起動直後の安定性を確認します。
セキュアブートの一時無効化と再有効化
セキュアブートはセキュリティ上非常に重要ですが、ドライバやブートローダーの署名が中途半端な状態で有効化すると、起動のたびに検証に失敗し、ブルースクリーンや自動修復ループに陥ることがあります。
切り分けのために、一度セキュアブートを無効化して動作確認するのも有効です。
- UEFI設定画面を開く
- 「Boot」や「Security」タブなどにある「Secure Boot」を「Disabled」にする
- 保存して再起動し、ブルースクリーンの発生有無を確認する
セキュアブートを無効化して明らかに安定するなら、ドライバやブート構成に署名周りの問題がある可能性が高くなります。GPUやストレージ、チップセットドライバなどを整理してから、改めてセキュアブートを有効化しましょう。
チップセットドライバとBIOS（UEFI）のアップデート
特にRyzenプラットフォームでは、チップセットドライバとマザーボードBIOSのバージョンが安定性に大きく影響します。古いBIOSと新しいCPU・メモリの組み合わせや、古いチップセットドライバがセキュアブートや電源管理と衝突するケースもあります。
- マザーボードメーカーの公式サイトから、安定版の最新BIOSとチップセットドライバを確認
- BIOSアップデートは、停電や誤操作のリスクを理解したうえで、マニュアルどおりに慎重に実施
BIOS更新後に一度「ロード最適化デフォルト」を実行することで、過去の怪しいOC設定がリセットされ、トラブルが収まるケースも多くあります。
UEFI/CSMとブート方式（GPT/MBR）の整合性を確認する
CSM（Compatibility Support Module）のON/OFFを何度も切り替えたり、別PCからクローンしたSSDで起動している場合、OSのインストール方式（UEFI/GPT・レガシー/MBR）と、UEFI設定が噛み合っていないことがあります。
現在のBIOSモードとパーティションスタイルを確認する
- 「Win + R」→
msinfo32と入力 - システム情報ウィンドウで「BIOS モード」を確認する（UEFI／レガシ）
- 「ディスクの管理」を開き、システムディスクを右クリック →「プロパティ」→「ボリューム」タブで「パーティションのスタイル」を確認（GPT／MBR）
一般的には次のような対応になります。
| パーティションスタイル | 推奨設定 | ポイント |
|---|---|---|
| GPT | UEFIモード・CSM無効 | セキュアブートを使うならこの組み合わせが前提 |
| MBR | レガシーモード・CSM有効 | 古いOSからアップグレードした環境に多い。セキュアブートとの相性は悪い |
GPTディスクなのにCSMを有効にしている、MBRなのにUEFIオンリーにしている、といった中途半端な状態では、起動処理の途中で不整合が起き、ブルースクリーンや自動修復ループが発生しやすくなります。
ブートファイル／システムファイル破損を整える
ブルースクリーンが何度も発生しているPCでは、Cドライブ自体やシステムファイルが傷んでいる可能性もあります。特に、突然の電源断やハングアップ後の強制電源オフを何度も行っていると、ファイルシステムの矛盾が蓄積します。
DISM・SFC・CHKDSKでOSを整備する
管理者権限のPowerShellまたはコマンドプロンプトを開き、次の順番で実行します。
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
chkdsk C: /f
- DISM：Windowsコンポーネントストアの破損を修復
- SFC：システムファイルを検査し、破損したものを置き換え
- CHKDSK：ディスクのファイルシステムを検査・修復（次回再起動時に実行）
特にSFCで大量の修復が記録されたり、DISMやCHKDSKでエラーが出た場合、ブルースクリーンの「二次被害」としてOSが傷んでいる可能性があります。ここを整えるだけで、同じメモリ構成でも安定度が増すケースがあります。
Ryzen Master ドライバの残存エラーに注意
イベントビューアで「AMDRyzenMasterDriverV20」などのエラーが大量に記録されている場合、過去にインストールした Ryzen Master やOC系ツールのドライバが中途半端に残っている可能性があります。
安全な対処手順
- Ryzen Masterの最新インストーラを入手し、一度インストール
- そのままアンインストーラで正しい手順でアンインストール
- 再起動してイベントログを確認し、同じエラーが出ていないかチェック
それでもエラーが続く場合のみ、復元ポイントを作成したうえで、レジストリエディタから該当サービスキーをバックアップしつつ確認します。
- 例：
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\AMDRyzenMasterDriver - ImagePath のパスが存在しないフォルダを指している場合は要注意
ただし、レジストリ操作は誤ると起動不能に直結するため、基本的には「再インストール→正しくアンインストール」で解決を目指すことをおすすめします。
ミニダンプ（.dmp）の読み方：WinDbg Previewでの基本解析
ブルースクリーンの原因にあたりを付けたら、ミニダンプの解析で「どのドライバ・どのモジュール」が怪しいのかを確認していきます。
ミニダンプの出力設定を確認する
- 「Win + X」→「システム」→「システムの詳細設定」を開く
- 「起動と回復」欄の「設定」をクリック
- 「デバッグ情報の書き込み」を「小メモリ ダンプ (256KB)」または「カーネルメモリ ダンプ」に設定
- ダンプファイルのパス（通常は
C:\Windows\Minidump）を確認
ここが無効になっていると、ブルースクリーンが出ても解析材料が残りません。まずは設定を有効にしておきましょう。
WinDbg Previewでの基本操作
Microsoft StoreからWinDbg Previewをインストールし、以下の手順でミニダンプを開きます。
- WinDbg Preview を起動
- File → Open dump file から
C:\Windows\Minidump内の最新の .dmp を選択 - 開いたら、下部のコマンド欄に
!analyze -vと入力して Enter
しばらく解析が走った後、次のような情報が得られます。
- BugCheck コード（例：
CRITICAL_PROCESS_DIED (ef)） - Probably caused by: に表示されるモジュール名（例：
ntoskrnl.exe以外が出ていれば特に要注意） - スタックトレース（どのドライバがどの関数から呼ばれて落ちたか）
続けて、読み込まれているドライバ一覧を確認します。
lm t n
ここで、古い日付のストレージドライバや、署名の怪しいサードパーティ製ドライバ、GPU関連のドライバが目立つようであれば、それらのアップデート・削除を検討します。
「複数のダンプで同じモジュールが出るか」を重視する
ミニダンプ解析で大事なのは、「1回のクラッシュログで全てを判断しない」ことです。例えば、次のようなパターンは要警戒です。
- 3回のミニダンプ解析のうち、2回で同じストレージドライバがスタック上にいる
- 再起動直後に落ちるクラッシュログでは、起動時に読み込まれるアンチウイルスやバックアップソフトのドライバが毎回登場する
- ATTEMPTED_WRITE_TO_READONLY_MEMORY のクラッシュで、特定のフィルタドライバが常にスタックに含まれている
このような場合、そのドライバを最新版に更新するか、一時的にアンインストールすることで、クラッシュが再現しなくなるかどうかを確認します。
実践的な復旧ランブック：順番にやれば沼らない
ここまでの内容を、実際のトラブルシュートの手順として整理すると次のようになります。
- BIOSを既定値に戻す
XMP/DOCPを無効にし、メモリをJEDEC標準（2133/2400MHzなど）で動かす。セキュアブートも一時的に無効化し、CSMはインストール方式に合わせる。 - オリジナルのメモリキットのみで起動確認
元のメモリだけ＋JEDEC設定で、複数回の再起動・シャットダウンをテスト。ここで安定するかどうかが大きな分かれ目です。 - Windowsメモリ診断／MemTest86を実施
少なくとも1〜2周は走らせ、エラーの有無を確認。エラーが出る場合、メモリかスロットの不良を強く疑う。 - GPUドライバとチップセットドライバのクリーンインストール
可能であればセーフモード＋DDUでGPUドライバを削除し、公式の安定版ドライバを入れ直す。同時にチップセットドライバも更新。 - DISM → SFC → CHKDSKでOSを整え、再起動
- 安定が確認できたら、メモリ周波数を段階的に引き上げる
2666MHz → 2933MHz → 3000MHz…と少しずつ上げ、ブルースクリーンが出ない上限を探る。 - 必要ならセキュアブートを再有効化
ドライバやブート構成を整えてから有効化し、数日様子を見る。 - それでも起動時のみBSODが続く場合はミニダンプ解析へ
WinDbg Preview で複数のミニダンプを解析し、繰り返し登場するドライバを特定。不要なドライバを無効化またはアンインストールして検証。
この順番で対処すると、「メモリ混在・設定の問題なのか」「GPUやその他ドライバなのか」「ストレージ・ブート構成なのか」が段階的に絞り込めます。
典型的なブルースクリーンコードと原因の対応表
今回のようなケースでよく登場するブルースクリーンと、その背景にあることが多い要因をざっくりまとめると次のようになります。
| 停止コード | 概要 | このケースで特に疑うべきもの |
|---|---|---|
| CRITICAL_PROCESS_DIED (0xEF) | 重要なシステムプロセスが予期せず終了 | メモリ破損、システムファイル破損、ストレージエラー、アンチウイルスなどのフィルタドライバ |
| ATTEMPTED_WRITE_TO_READONLY_MEMORY (0xBE) | 読み取り専用領域に対する不正な書き込み | 不良・古いドライバ、メモリのタイミング不整合、OC設定による微妙な不安定さ |
どちらも「メモリがらみの問題」で起きやすいため、まずはメモリ構成と設定の健全性を疑うのが王道です。
今後の予防策：メモリ・GPU増設時に気をつけるポイント
最後に、同じようなトラブルを避けるための注意点をまとめます。
メモリは「同一型番・同一キット」で揃える
- 「同じ容量・同じクロック」のバラ売りを足しても、内部構造が違えば相性問題の原因になる
- 2枚セット・4枚セットなど、最初からペアで検証されているキットを選ぶのが理想
- どうしても混在させる場合は、JEDEC標準周波数（2133MHzなど）で運用し、無理に高クロックを狙わない
ハードウェア変更のたびに「一晩メモリテスト」を習慣にする
GPUやメモリ、ストレージなど大きな構成変更を行った際は、少なくとも1回は MemTest86 などで数周〜一晩メモリテストを走らせておくと安心です。問題が出るなら、早期に検出できます。
BIOS設定とブート方式をメモしておく
- 現在のメモリ周波数・電圧・タイミング
- セキュアブートの有効／無効、CSMの有効／無効
- OSのインストール方式（UEFI/GPTかレガシー/MBRか）
これらをスクリーンショットや写真で保存しておくと、トラブル発生時に「どこまで戻せばよいか」が分かりやすくなります。
システムイメージバックアップを定期的に作成する
ハードウェア変更の前に、Windowsのシステムイメージや重要データのバックアップを取っておくと、最悪の場合は「丸ごと復元」で時間を節約できます。特に、UEFI設定やパーティションスタイルをいじる前には、バックアップを強く推奨します。
まとめ：GPUよりもまず「メモリ混在と設定」を疑う
起動時や再起動時にだけ発生する CRITICAL_PROCESS_DIED や ATTEMPTED_WRITE_TO_READONLY_MEMORY のようなブルースクリーンは、GPUそのものの物理的な故障よりも、メモリ混在・OC設定・ドライバ・UEFI設定の組み合わせであることが多く、特に
- 別キットのメモリを混在させている
- 全てのメモリを3200MHzなど高クロックで動かしている
- クロックを2133MHzに下げると安定する
という条件が揃っている場合、最優先でメモリ構成と設定の見直しを行うべきです。そのうえで、GPUドライバやセキュアブート、UEFI/CSM設定、システムファイルの破損、Ryzen Masterなどの残存ドライバといった二次的要因を一つずつ潰していくことで、再現性の高い安定した環境に近づけていくことができます。
ミニダンプ解析を併用すれば、「どのドライバ・どのモジュール」が繰り返しクラッシュに関わっているのかも見えてきます。この記事の手順を参考に、原因を一つずつ切り分け、快適なWindows環境を取り戻してください。
コメント