自作PCでWindows 11を使っていると、起動からぴったり3時間後にブルースクリーンが出てしまい、ミニダンプを確認すると毎回「ntoskrnl.exe+4b8550」と表示される──そんな謎めいたトラブルに悩んでいませんか。この記事では、Ryzen 5 7500F＋DDR5‑6400環境の実例をもとに、原因の考え方と具体的な対処手順を、再現テストのやり方まで含めて詳しく整理します。
ケース概要：Ryzen 5 7500F環境で起動3時間後に必ずブルースクリーン
まずは、今回の典型例となる構成と症状を整理します。
| 項目 | 内容 |
|---|---|
| CPU | Ryzen 5 7500F |
| マザーボード | MSI B-850 Gaming Plus WiFi（※原文表記のまま） |
| メモリ | Adata XPG DDR5‑6400 16GB × 2（EXPO想定） |
| 電源 | Corsair HX850i |
| ストレージ | Samsung 970 EVO Plus 2TB |
| OS | Windows 11 |
| 症状 | 起動からちょうど3時間経過したタイミングでブルースクリーン。停止コードは毎回違うが、ミニダンプでは毎回 ntoskrnl.exe + 4b8550 が指される。 |
| 試したこと | ストレージ、グラフィックボードを交換 → 改善せず。マザーボード・メモリ・CPUは交換不可。 |
さらにイベントログには、DCOMのCLSID/APPID警告や OneCore-DeviceAssociationService の警告が出ているものの、これらは本件とは無関係と考えられるケースが多い、という指摘がスレッドでされています。
「ntoskrnl.exe+4b8550」は原因ではなく“結果”に過ぎない
Windows 11のブルースクリーン解析でよく出てくる ntoskrnl.exe は、Windowsカーネル本体の実行ファイルです。ミニダンプに表示される「ntoskrnl.exe+4b8550」のような表記は、
- カーネル内のどのアドレスで異常が検出されたか を示す「オフセット位置」
- カーネル自身が壊したという意味ではなく、そのアドレスに到達したときには既にカーネル領域が破壊されていた 可能性が高い
という点を理解しておくことが重要です。
実際には、次のような要因でカーネルメモリがじわじわ壊されていき、最終的にntoskrnl.exe内の整合性チェックで検出される、という流れが典型です。
- オーバークロック気味のEXPO/XMPメモリ設定の不安定化
- 不適合なドライバー（古い/バグ持ち/他バージョン用）
- BIOSやチップセットドライバーの不整合、AGESAの相性
特に BugCheck 0x139（KERNEL_SECURITY_CHECK_FAILURE） が出ている場合、カーネル領域のメモリ破損（メモリ二重解放・バッファオーバーラン・不正ポインタ） が強く疑われます。メモリそのもののエラーだけでなく、ドライバーのバグでも頻出する代表的なバグチェックコードです。
「3時間きっかり」で落ちる規則性が意味するもの
ブルースクリーンがランダムではなく、起動からほぼ3時間きっかりで発生する場合、次の2つのシナリオが考えられます。
| パターン | 概要 | 代表的な原因候補 |
|---|---|---|
| メモリ境界が一定時間後に崩れる | 起動直後は安定しているが、一定時間後に高負荷処理・スリープ復帰・キャッシュ蓄積などをきっかけにエラーが顕在化 | EXPO/XMP設定の攻めすぎ、SoC電圧やメモリ電圧不足、メモリ個体差、BIOSのメモリトレーニング不具合 |
| 定期処理で不安定なドライバーが踏まれる | 「起動後○分ごと」「毎○時間」などで動くタスクがあり、そのタイミングでバギーなドライバーコードが実行される | 常駐アプリのアップデートチェック、バックアップソフト、RGBユーティリティ、デバイス監視ツール、メーカー製ユーティリティ |
したがって、
- メモリ設定の安定化
- タスクスケジューラ／自動起動アプリの切り分け
の2方向からアプローチすることが近道です。
まずやるべき最短5ステップ
時間がない場合でも、最低限次の5ステップを順番に実施すれば、多くの「ntoskrnl.exe+オフセット」系ブルースクリーンは収束します。
| 優先度 | 手順 | ポイント |
|---|---|---|
| 1 | EXPO無効 → JEDEC（4800）で運用 → 3時間テスト | まずはCPUとメモリに一番優しい設定に戻し、「3時間きっかりで落ちるか」を確認する。 |
| 2 | BIOS・AMDチップセット・SSD FW・GPUドライバーを最新化 | AGESA更新やNVMeファームウェア更新で突然安定するケース多数。GPUはクリーンインストール推奨。 |
| 3 | クリーンブートで3時間テスト | 常駐アプリとサードパーティサービスを一括で停止し、3時間タイマーの「犯人」がOS標準外にいるか確認する。 |
| 4 | MemTest86を最低4パス以上 | 1ビットでもエラーが出たらメモリ設定の見直し、またはメモリモジュールの個体不良を疑う。 |
| 5 | Driver Verifierでサードパーティドライバーをチェック | あえてクラッシュさせることで「どのドライバーがカーネルを壊しているか」を特定する。 |
ここから先は、それぞれのステップをより具体的に解説していきます。
メモリ（EXPO/XMP）設定をまず安定化させる
EXPO/XMPを一旦完全に無効化する
Ryzen 7000シリーズ＋DDR5構成では、メモリのオーバークロック設定（EXPO/XMP）が「普通に起動はするが長時間動かすと不安定」というパターンを生みがちです。
- BIOSセットアップ（UEFI）に入り、EXPO/XMP関連設定をすべて「Disabled」にする。
- メモリ周波数を自動（Auto）またはJEDEC標準値（例：DDR5‑4800）に戻す。
- CPU／メモリ電圧をいじっている場合は一度すべてAutoに戻す。
- CMOSクリアを行ったうえで「最適化された既定値（Load Optimized Defaults）」を読み込むと確実。
この状態でWindows 11を起動し、何もせず放置、または軽い作業をしながら3時間以上放置してもブルースクリーンが出ないかを確認します。
- 3時間経っても落ちない → メモリ設定（EXPO/周波数）がほぼ原因確定
- EXPO無効でも3時間で落ちる → メモリ以外（ドライバー／タスク／ハード）の可能性が高い
安定な周波数まで少しずつ引き上げる
EXPO無効（JEDEC 4800）で安定を確認できたら、次のように少しずつ周波数を上げつつ再テストしていきます。
- 4800 → 5200 → 5600 → 6000 → 6200 → 6400…
一般に、Ryzen 7000シリーズではDDR5‑6000前後が「安定の目安」とされることが多く、6400常用は個体差・マザーボード・BIOSによって不安定になりがちです。6400でだけ3時間タイマー発動、6000以下では安定、というケースはかなり現実的にありえます。
MemTest86／HCI／Karhuで長時間メモリテスト
メモリの安定性を確認するには、単に「起動して使えるか」だけではなく、専用ツールによる検証が重要です。
- MemTest86：USBメモリから起動して実施。最低でも4パス以上を推奨。
- HCI MemTestやKarhu RAM Test：Windows上から実行。複数インスタンスを起動し、物理メモリの80〜90%程度を割り当ててテスト。
1エラーでも出たらNGです。「たまにしか出ない」「1つだけだから大丈夫」は通用しません。エラーが出る設定で使っている限り、どこかのタイミングでカーネルメモリが破壊され、ntoskrnl.exe+オフセット系のクラッシュにつながります。
BIOS／チップセット／ファームウェア／GPUドライバーを最新化
BIOS（UEFI）の更新
Ryzen 7000世代では、BIOSに含まれるAGESA（AMD Generic Encapsulated Software Architecture）のバージョンによって、
- メモリの安定性
- 電圧の挙動
- スリープ・復帰処理
などが大きく変わります。マザーボードメーカーの公式サイトから、型番に対応した最新BIOSを確認し、リリースノートに「メモリ互換性改善」「システム安定性向上」などがあれば積極的に更新しましょう。
AMDチップセットドライバー
AMD公式サイトから最新のAMDチップセットドライバーをダウンロードし、インストールします。これにより、
- 電源管理
- PCIeリンク
- USBコントローラ
などの挙動が改善されることがあり、不意のカーネルクラッシュが減るケースもあります。
NVMe SSD（Samsung 970 EVO Plus）のファームウェア更新
Samsungの「Magician」ユーティリティなどを使い、970 EVO Plusのファームウェアが最新か確認します。NVMe側のファーム不具合が原因で、
- 特定の負荷パターン時にI/Oエラー → カーネルクラッシュ
を引き起こすこともあるため、異常がないかチェックしておきましょう。
GPUドライバーはクリーンインストール
グラフィックボードを交換しても症状が続く場合でも、旧ドライバーの残骸や設定ファイルが悪さをしている可能性があります。
- セーフモードで起動
- DDU（Display Driver Uninstaller）などを使い、既存GPUドライバーを完全削除
- 再起動後、最新のドライバーをインストール
という手順で一度クリーンに入れ直しておくと安心です。
クリーンブートで「3時間タイマーの犯人」を切り分ける
EXPO無効＆最新ドライバーでも3時間問題が出る場合、常駐アプリ／サービスによるドライバー不具合の疑いが強くなります。ここで役立つのがクリーンブートです。
クリーンブートの設定手順（Windows 11）
- Win + R キーで「ファイル名を指定して実行」を開き、
msconfigと入力してEnter。 - [サービス]タブで「Microsoftのサービスをすべて隠す」にチェックを入れたうえで、残りのサービスをすべて無効化。
- [スタートアップ]タブから「タスク マネージャーを開く」をクリックし、スタートアップアプリをすべて無効化。
- PCを再起動し、この状態で3時間以上放置してブルースクリーンが出るか確認。
結果の解釈は次の通りです。
- クリーンブート状態では3時間経っても落ちない
→ 停止したサービス／スタートアップアプリの中に原因となるドライバー／常駐ソフトが存在する可能性大。 - クリーンブートでも3時間で落ちる
→ OS標準コンポーネント、またはドライバーの深い層（ストレージ／チップセット／BIOS設定など）を疑う。
クリーンブートで安定する場合は、サービスとスタートアップを半分ずつ有効化する「二分探索」で問題のソフトを特定していきます。
Driver Verifierでサードパーティ製ドライバーを検証する
メモリ設定とクリーンブートで原因が絞り込めない場合は、Windows標準のDriver Verifierを使って、不正なカーネルモードドライバーをあぶり出します。ただし、あえてクラッシュさせる機能なので、作業前に復元ポイントの作成や重要データのバックアップを必ず行ってください。
Driver Verifierの使い方（概要）
- Win + R で
verifierと入力し、Enter。 - 「標準設定を作成する」→「次へ」。
- 「ドライバー名の一覧から選択する」→「次へ」。
- 一覧からサードパーティ製ドライバー（Microsoft以外の署名者）のみを選択。
- PCを再起動。
再起動後、しばらく使用していると、問題のあるドライバーがあればDriver Verifierが異常を検知して即座にブルースクリーンを発生させます。このときのミニダンプには、どのドライバーが原因かがよりはっきり記録されるはずです。
Driver Verifierの検証を解除するには、セーフモードで起動して以下を実行します。
verifier /reset
システムファイルの整合性チェック（SFC／DISM）
カーネル周辺のシステムファイルが破損している可能性もゼロではありません。管理者権限のPowerShellまたはコマンドプロンプトで、次のコマンドを順に実行します。
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
これにより、Windows 11のシステムファイルやコンポーネントストアの破損が修復される場合があります。
「3時間きっかり」を追跡：タスクスケジューラと電源設定
「3時間」という明確な間隔がある以上、何かの定期処理が関係している可能性は最後まで疑うべきです。
タスク スケジューラで起動トリガーを洗い出す
- Win キーを押して「タスク スケジューラ」と入力し起動。
- 左ペインから「タスク スケジューラ ライブラリ」配下、特に「Microsoft > Windows」配下のタスクを確認。
- 各タスクの「トリガー」タブで、「ログオン時から○分後」「コンピューターの起動時から○分後」「毎○時間」といった設定の有無をチェック。
特に、
- メーカー製ユーティリティの自動更新チェック
- バックアップソフト・クラウドストレージ同期
- ウイルス対策ソフトのフルスキャン
などは、一定時間ごとに動作することが多く、これが不安定なドライバーを通じてカーネルメモリ破損を引き起こすことがあります。
高速スタートアップ・ハイブリッドスリープを一時的に無効化
電源周りの省電力機能との相性で、起動後しばらくしてからクラッシュが発生することもあります。検証のため、以下を一時的に無効化して挙動を比較します。
- 高速スタートアップ
- ハイブリッドスリープ
コントロールパネルの電源オプションから設定を変更し、無効化した状態で同じように3時間放置してみて、挙動が変わるか確認してみましょう。
ハードウェアの健全性チェック：電源・熱・ケーブル
電源容量は十分に見える構成でも、
- ケーブルの挿し込み不良
- 特定レーンだけの接触不良
- 高負荷時にだけ起こる瞬間的な電圧降下
といった要因で、カーネルクラッシュが起きることがあります。次の点を確認しましょう。
- マザーボードの24ピンATX・8ピンCPU補助電源コネクタが確実に奥まで刺さっているか。
- モジュラー電源の場合は、別系統のケーブルに差し替えてみる。
- CPUクーラーやVRM周辺の温度をハードウェアモニタで確認し、高負荷時でも許容範囲内に収まっているかをチェック。
CPUやGPU、メモリのOCや電圧調整をしている場合は、検証中だけでもすべて標準設定に戻すのが鉄則です。
DCOM警告やOneCore-DeviceAssociationService警告は無関係なことが多い
イベントビューアーを開くと、
- DCOMのCLSID/APPID警告
- OneCore-DeviceAssociationService の警告
など、黄色の警告アイコンが大量に表示されていて、不安になるかもしれません。しかし、これらは多くの場合、
- 権限設定やデバイス認識に関する「よくある警告ログ」
- カーネルレベルのメモリ破損やBugCheck 0x139そのものとは直接関係しない
とされています。もちろん、全てを完全に無視してよいとは言えませんが、今回のようなntoskrnl.exe+オフセット付きのブルースクリーンの第一原因としては考えにくく、優先すべきはやはり、
- メモリ設定
- ドライバーの健全性
- BIOS／チップセット／ファームウェア
の3点です。
BugCheck 0x139（KERNEL_SECURITY_CHECK_FAILURE）について
ミニダンプのBugCheckコードとして 0x139（KERNEL_SECURITY_CHECK_FAILURE） が出ている場合、これはセキュリティクリティカルなカーネル構造が壊れたことを検出したことを意味します。代表的な原因としては、
- メモリのダブルフリー（同じ領域を2回解放してしまう）
- 境界外アクセス（バッファオーバーラン／アンダーラン）
- 不正なポインタ参照（NULLポインタ／解放済ポインタ）
などがありますが、これらは多くの場合、
- 不良ドライバーのバグ
- 不安定なメモリ設定によるデータ破損
が根本原因です。その意味でも、メモリの安定化とドライバーの洗い出しこそが最優先の対処と言えます。
再発時に共有すると良い追加情報（テンプレ）
フォーラムやQ&Aサイトで解析を依頼する場合、次のような情報をあらかじめ用意しておくと、的確なアドバイスが得られやすくなります。
- ミニダンプ複数（直近5件程度）
C:\Windows\Minidumpにある.dmpをZIPにまとめ、OneDrive／Google ドライブ／Dropboxなどにアップロード。 - MSINFO32の.nfo
msinfo32.exeを起動 → [ファイル] → [エクスポート] から保存。 - BIOSバージョンとメモリ設定
EXPO有効/無効、メモリ周波数、タイミング、電圧など。 - イベントビューアー（システム）のクラッシュ直前5分間のログ
該当時間帯のエラー／警告レベルのイベントIDをメモしておく。 - ドライバー一覧
管理者権限のコマンドプロンプトで以下を実行し、出力を保存。driverquery /v /fo csv > drivers.csv
ここまで揃っていると、「どのドライバーが怪しいか」「どの時期の更新がトリガーか」が非常に追いかけやすくなります。
Ryzen 5 7500F＋DDR5‑6400構成で特に気を付けたいポイント
今回のケースのように、
- Ryzen 5 7500F（Zen 4）
- DDR5‑6400 16GB×2
という構成では、次の点に注意が必要です。
- 公式サポートと実運用上の「 sweet spot 」は別
仕様上サポートされている周波数でも、実運用の安定ラインはもう少し低いことが多く、6000〜6200あたりで妥協するのが現実的です。 - メモリ2枚挿しの負荷
2枚挿し（デュアルチャネル）は1枚挿しよりコントローラへの負荷が高く、ボードやCPU個体差によっては6400が厳しい場合もあります。 - BIOSバージョンによる挙動差
同じメモリ・同じ設定でも、BIOSバージョンを変えるだけで「3時間で落ちる → まったく落ちなくなる」というケースもあります。
そのため、
- 最初は安定重視でDDS5‑6000前後からスタートし、
- MemTest86などで十分な検証を行ったうえで、
- どうしても必要な場合のみ慎重にクロックを上げる
という順番を守ることが重要です。
原因と対策のマッピングまとめ
| 観測される症状・手がかり | 濃厚な原因候補 | 優先して試す対策 |
|---|---|---|
起動から3時間きっかりでBSOD、コードは毎回バラバラだが ntoskrnl.exe+4b8550 | メモリ設定不安定＋定期タスク or 常駐アプリで不良ドライバーが踏まれる | EXPO無効・JEDECで長時間テスト、タスクスケジューラ確認、クリーンブート検証 |
| BugCheck 0x139（KERNEL_SECURITY_CHECK_FAILURE）が頻出 | カーネル領域のメモリ破損（ドライバー or RAM） | MemTest86、Driver Verifier、ドライバー／BIOS更新 |
| MemTest86で1ビットでもエラー | メモリクロックの攻めすぎ or メモリモジュールの個体不良 | 周波数を下げる、電圧見直し、モジュール単体テスト、可能なら交換 |
| クリーンブート状態だと3時間経っても落ちない | 常駐アプリ／サードパーティサービスが原因 | サービス／スタートアップを半分ずつ戻す二分探索で犯人特定 |
| DCOM警告・OneCore-DeviceAssociationService警告が多数 | よくある権限・デバイス関連のログ | 基本的には優先度低。メモリ・ドライバー・BIOS側の対策を先に進める。 |
まとめ：ntoskrnl.exe+オフセット系ブルースクリーンへの向き合い方
「ntoskrnl.exe+4b8550」のような表示は、あくまで「ここでカーネルがおかしいことに気付いた」というアドレス情報であって、真犯人は別の場所（メモリ設定・ドライバー・BIOSなど）にいることがほとんどです。
特に今回のように、
- 起動からちょうど3時間後にBSODが発生
- BugCheck 0x139（KERNEL_SECURITY_CHECK_FAILURE）が絡む
- ストレージやGPUを替えても改善しない
という条件がそろっている場合、
- EXPOを切ってJEDECでテストし、DDR5‑6000前後まで段階的に詰める。
- BIOS／チップセット／NVMeファームウェア／GPUドライバーを最新にする。
- クリーンブートで3時間タイマーが発動するかを確認する。
- MemTest86やDriver Verifierでメモリとドライバーを検証する。
- それでもダメなら、タスクスケジューラや電源設定を含めて「3時間後に動くもの」を徹底的に洗う。
という順番で一つずつ潰していくことが、最も再現性高く原因にたどり着く方法です。
ntoskrnl.exeが指されているからといって「Windowsがおかしい」「OSを入れ直せば直る」と短絡的に考えるのではなく、今回紹介したようにハードウェア（特にメモリ）・ドライバー・BIOSの3点セットにじっくり向き合うことで、多くの症状は収束していきます。
同じような「起動から数時間後に必ず落ちる」「ntoskrnl.exe+オフセット」が出る、といったトラブルで悩んでいる場合は、ここで紹介した手順をベースに、まず再現テストと設定の見直しから始めてみてください。
コメント