Windows 10 を使っていると、突然ブルースクリーンが出て再起動を繰り返し、「自動修復を準備しています」→「ハードディスクが見つからない」という表示で先に進めなくなることがあります。しかも SrtTrail.txt には OS の場所が G:\Windows と記録され、ディスク診断や sfc では異常なし……。この記事では、ミニダンプ解析で判明した「チップセットドライバーの不具合」を前提に、この症状をどのように切り分け・解決していくかを、実践的な手順とともに詳しく解説します。
症状の全体像：BugCheck 0x4E と SrtTrail.txt の「ハードディスクが見つからない」
まずは、今回の典型的な症状を整理します。
- Windows 10 起動時にブルースクリーン（BugCheck 0x4E）が発生し、自動的に再起動される
- 再起動後、Windows 回復環境（自動修復 / Startup Repair）が起動する
- 自動修復の結果として「ハードディスクが見つからない」「オペレーティングシステムが見つからない」といったエラーが表示される
SrtTrail.txtを開くと、OS の場所がG:\Windowsなど、本来とは異なるドライブレターで記録されているsfc /scannow、chkdsk /f /r、DISM /RestoreHealthを実行してもファイルシステム上は異常なしC:\Windows\MinidumpまたはC:\Windows\Minidumpsにあるミニダンプを解析すると、チップセットドライバーが原因の BugCheck 0x4E（PFN_LIST_CORRUPT に相当）が検出される
見た目は「ハードディスクが壊れた」「OS が消えた」というエラーですが、実際には OS やストレージそのものではなく、チップセットドライバーがメモリ管理やストレージ制御を乱しているために、自動修復が誤動作しているケースです。
| 項目 | 典型的な症状 | 実際の状態 |
|---|---|---|
| ブルースクリーン | BugCheck 0x4E（PFN_LIST_CORRUPT） | メモリ管理を担当するコンポーネントが破損を検知。多くはドライバーが原因。 |
| 自動修復 | 「ハードディスクが見つからない」と表示 | 実際にはディスクは認識されているが、ドライバーの不具合で I/O が不安定。 |
| SrtTrail.txt | OS の場所が G:\Windows と表示 | 回復環境側から見た一時的なドライブレター。必ずしも異常ではない。 |
| ディスク・システムファイル診断 | sfc・chkdsk・DISM すべて正常 | ストレージやシステムファイルは問題なし。根本原因はドライバー側。 |
BugCheck 0x4E（PFN_LIST_CORRUPT）とは何か
BugCheck コード 0x4E は、Windows のメモリ管理コンポーネントが「PFN（Page Frame Number）リストの破損」を検出したときに発生するエラーです。
- PFN は、物理メモリのどの場所にどのページがあるかを管理する情報
- このリストが破損するのは、通常は OS カーネルやドライバーが不正なメモリアクセスを行ったとき
- 特にチップセットドライバーは、メモリ・PCIe・ストレージなど多数のハードウェアとの橋渡し役であり、破綻すると OS 全体に影響が出る
ミニダンプを解析すると、コールスタック上にチップセット関連のドライバー（例：Intel の場合は iaStor* 系やチップセット INF、AMD の場合は amdkmpfd.sys など）が見えてくることが多く、「特定のチップセットドライバーの更新後から発生する」「別のバージョンに戻すとおさまる」といった情報と合わせて、原因を特定できます。
解決のゴールと方針
今回のケースで目指すゴールは次の 2 つです。
- BugCheck 0x4E を引き起こしているチップセットドライバーを、正常なバージョンに置き換える
- 結果として、
SrtTrail.txtによる自動修復ループ（「ハードディスクが見つからない」）を収束させる
そのために、次の順序で対応するのが効果的です。
- Windows が起動できる状態であれば、まずはチップセットドライバーを上書きインストール
- うまくいかない場合は、デバイスマネージャーからチップセット関連ドライバーをクリーン削除 → 再インストール
- その後、メモリ診断やストレージの物理チェックで、ハードウェアの故障を念のため除外
sfcとDISMを再度実行して、システムファイルの整合性を確認- それでも再発する場合は、ミニダンプを再解析して他のドライバーやハードウェア故障を疑う
最優先：チップセットドライバーを再インストールする
もっとも効果が高く、かつリスクが低い対処が、チップセットドライバーの再インストールです。Windows が何とか起動できる状態（通常起動・セーフモードどちらでも可）であれば、真っ先に試す価値があります。
ベンダー公式サイトからドライバーをダウンロードする
自動更新や汎用ドライバーではなく、PC / マザーボード製造元の公式ページから入手したチップセットドライバーを利用するのが重要です。Windows Update 経由のドライバーが原因で不具合が起きているケースもあるためです。
- 自分の PC の型番、またはマザーボードの型番を確認する
- 製造元のサポートページで、該当モデル向けの「ドライバー」または「ダウンロード」を開く
- 「チップセット」「Chipset」「INF」「Intel Chipset Device Software」「AMD Chipset Driver」などの名称のドライバーを探す
- OS バージョン（Windows 10 64bit など）に合った最新版または「推奨版」とされているバージョンをダウンロードする
| プラットフォーム | よくあるドライバー名称 | 補足 |
|---|---|---|
| Intel | Intel Chipset Device Software / INF Update Utility | ストレージドライバー(RST)と別になっている場合あり。 |
| AMD | AMD Chipset Drivers | USB、SATA、PCIe 等が一括で含まれることが多い。 |
| ノート PC メーカー | Chipset / System / INF など | メーカー独自チューニング版のため、まずはここから入手するのが安全。 |
チップセットドライバーの上書きインストール手順
- ダウンロードしたインストーラー（
.exeなど）を右クリックして「管理者として実行」する - 画面の指示に従ってインストールを進める（基本的には「次へ」「はい」で問題ない）
- インストール完了後、必ず PC を再起動する
- 再起動後、ブルースクリーンや自動修復ループが発生しないかを確認する
これだけで改善する場合も多く、ミニダンプでチップセットドライバーが原因と判明しているなら、まずはこの上書きインストールを試すのが最も合理的です。
Windows が起動できない場合のポイント
自動修復ループが連続し、通常起動ができない場合は、セーフモードでの起動を試します。
- 「自動修復を準備しています」→「自動修復の準備ができました」が表示されたら、［詳細オプション］をクリック
- ［トラブルシューティング］ → ［詳細オプション］ → ［スタートアップ設定］ を選択
- ［再起動］をクリックし、再起動後に表示されるメニューで ［5）ネットワークを有効にしたセーフモード］ を選択
- セーフモードで起動できたら、上記と同様にチップセットドライバーのインストールを行う
セーフモードでは不要なドライバーやサービスが読み込まれないため、ギリギリの状態でも作業できる可能性があります。
うまく更新できない場合：ドライバーをクリーン削除して再導入
単純な上書きインストールで改善しない場合は、一度ドライバーを削除してから入れ直す（クリーンインストール）ことを検討します。
デバイスマネージャーからチップセット関連デバイスを削除する
- スタートボタンを右クリックし、［デバイス マネージャー］ を開く
- 一覧から ［システム デバイス］ を展開する
- 「Chipset」「PCI Express Root Port」「SATA Controller」「Platform Controller Hub」など、チップセット関連と思われる項目を一つずつ右クリック
- ［デバイスのアンインストール］ を選択し、「このデバイスのドライバー ソフトウェアを削除します」にチェックを入れて実行
- 必要な項目の削除が終わったら、PC を再起動する
- 再起動後、あらかじめダウンロードしておいた公式チップセットドライバーをインストールする
注意点として、CPU や重要なブリッジデバイスを片っ端から削除しすぎると、一時的に不安定になる可能性があります。分からない場合は、「明らかにチップセット名が入っているもの」「メーカーのドキュメントで指定されたもの」のみに絞るのが安全です。
クリーンインストール時のチェックポイント
- 作業前に重要なデータのバックアップを取っておく（別ドライブ・クラウドなど）
- ノート PC の場合は AC アダプタを接続し、途中で電源が落ちないようにする
- 操作に不安がある場合は、削除する前にスクリーンショットを撮っておくと、元の状態を把握しやすい
- クリーンインストール後は、Windows Update を一度実行しておき、その後に再度不具合が出ないか確認する
BIOS（UEFI）のロールバックは基本的に不要
ブルースクリーンが発生すると、「最近 BIOS を更新したのが原因では？」と不安になりがちですが、本ケースではBIOS を元に戻す必要は通常ありません。
- BugCheck 0x4E の原因は、ミニダンプ解析の結果、チップセットドライバーに集約されている
- BIOS アップデート自体は、セキュリティ修正や新 CPU 対応などが目的で、むしろ戻すことで別の問題を生むリスクがある
- BIOS を頻繁に書き戻すと、最悪の場合フラッシュ失敗による起動不能の危険もある
したがって、「ドライバーを正しく更新してもなお、別の問題が疑われる」という段階に到達するまでは、BIOS に手をつけないのが安全です。
ミニダンプの保存先：Minidump / Minidumps どちらでも仕様範囲内
ミニダンプ解析を行った際に、C:\Windows\Minidump ではなく C:\Windows\Minidumps に保存されていることがありますが、これは特に異常ではなく仕様範囲です。
| パス | 意味 | 対処 |
|---|---|---|
C:\Windows\Minidump | 一般的な既定パス | 多くの解説で紹介される標準パス。 |
C:\Windows\Minidumps | 環境によってはこちらになることがある | 場所が違うだけで内容は同じ。気にせず解析してよい。 |
重要なのは「どのフォルダにあるか」ではなく、「BugCheck コードと、スタックに現れるドライバー名を読み取れるか」です。フォルダ名が違っていても、ミニダンプさえ取得できていれば問題ありません。
ミニダンプを活用するメリット
- 再現が難しいブルースクリーンの原因を後から追跡できる
- 怪しいドライバーを絞り込むことで、無駄なパーツ交換を避けられる
- サポートに依頼する場合でも、具体的な推測材料になる
チップセットドライバーの不具合が疑われる場合も、ミニダンプ解析によって確証を得ておくと、無駄なリカバリや再インストールを避けやすくなります。
追加チェック：トラブルが続く場合に確認したいポイント
チップセットドライバーを更新しても症状が続く、あるいは再発する場合は、ハードウェア故障や他のドライバーの問題も視野に入れてチェックします。
メモリ診断で RAM 故障を除外する
PFN_LIST_CORRUPT（BugCheck 0x4E）は、物理メモリの故障で発生することもあります。最低限、次のメモリ診断は実施しておきましょう。
- Windows メモリ診断（
mdsched.exe）- スタートメニューで
mdsched.exeと入力し、Enter - 「今すぐ再起動して問題の有無を確認する（推奨）」を選択
- 再起動後、自動的にメモリチェックが実行され、結果は次回ログオン時に通知される
- スタートメニューで
- MemTest86 などの専用ツール
より厳密なテストを行いたい場合は、USB メモリから起動するタイプのメモリテストツールを利用する方法もあります（使用方法は各ツールの手順に従う）。
SSD / HDD の物理状態とケーブルを確認
「ハードディスクが見つからない」というメッセージが出ている以上、ドライバーだけでなくストレージ側も確認しておくと安心です。
- デスクトップ PC の場合
- 電源を切り、電源ケーブルをコンセントから抜く
- ケースを開け、SSD / HDD に接続されている SATA ケーブル・電源ケーブルがしっかり奥まで刺さっているか確認する
- ケーブルに折れや異常な曲がりがないかを目視チェックする
- ノート PC の場合
- ユーザーが簡単に開けられない機種も多いため、無理に分解はしない
- 代わりに、メーカー提供の診断ツール（ストレージチェック機能）などがあれば実行する
SSD / HDD のファームウェアアップデートが提供されている場合は、メーカーの案内に従って最新にしておくと、不具合や相性問題の回避につながる場合があります。
チップセット更新後にあらためて SFC と DISM を実行する
ドライバー更新後は、念のためシステムファイルの整合性も再チェックしておくと安心です。
- スタートボタンを右クリック → ［Windows ターミナル（管理者）］ または ［コマンド プロンプト（管理者）］ を開く
- 次のコマンドを順番に実行する
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
これにより、ドライバー更新によって生じた可能性のある整合性の乱れも含めて修復できます。
コマンドと操作のまとめ表
今回のトラブル対応でよく使うコマンド・操作を、目的別に整理しておきます。
| 目的 | コマンド / 操作 | 概要 |
|---|---|---|
| システムファイル整合性チェック | sfc /scannow | Windows のシステムファイルをスキャンし、破損があればキャッシュから修復。 |
| コンポーネントストア修復 | DISM /Online /Cleanup-Image /RestoreHealth | Windows イメージ自体の破損を修復し、SFC の修復元としての健全性を保つ。 |
| ディスクの不良セクタ検査 | chkdsk C: /f /r | ファイルシステムの論理エラー修復に加え、不良セクタを検出・隔離する。 |
| メモリ診断 | mdsched.exe | 再起動時に RAM のエラーがないかをチェックする。 |
| セーフモード起動 | 回復環境 → ［スタートアップ設定］ | チップセットドライバーの再インストールなど、最小限構成での作業に利用。 |
「G:\Windows」と表示されるのは本当に異常か？
SrtTrail.txt のログで OS の場所が G:\Windows になっていると、「ドライブレターが勝手に変わった」と不安になりますが、回復環境から見ると C ドライブが別の文字になるのはよくある動作です。
- 通常起動時の C: ドライブが、回復環境では D: や E:、G: として見えることがある
- これは「回復環境自身のドライブ」「リカバリパーティション」「USB メモリ」などが優先的に A～C を占有するため
- そのため、
G:\Windowsだからといって OS が移動したわけではない
重要なのは、ドライブレターではなく、「ファイルシステム上のチェックでエラーが出ているかどうか」です。chkdsk やベンダー診断ツールで異常が出ていないのであれば、今回のようにドライバーが OS の認識を狂わせているだけというケースが強く疑われます。
なぜチップセットドライバーでストレージエラーが出るのか
チップセットドライバーは、単に「CPU とメモリの橋渡し」をしているだけではなく、実際には次のような役割を担っています。
- PCI Express バスの管理
- SATA / NVMe コントローラーの制御
- USB ポート、オンボードデバイス（LAN / オーディオなど）の制御
- 電源管理（省電力、スリープ復帰など）との連携
ここに不具合があると、ストレージ I/O が一時的に失敗したり、タイムアウトが発生したりします。その結果：
- OS から見ると「システムディスクへのアクセスが時々失敗する」
- Windows は「ストレージに問題がある」と判断し、自動修復を起動する
- しかし実際にはドライバー起因の一時的なエラーであり、
sfcやchkdskは異常を検出しない
この矛盾こそが、「ハードディスクが見つからない」と言われつつ、診断ツールでは異常なし、という状況を生み出します。ミニダンプ解析でドライバーが原因と分かったのであれば、ストレージ交換よりも先にドライバー更新で様子を見る方が合理的です。
それでもブルースクリーンが続く場合の次の一手
ここまでの対策（チップセットドライバーの再インストール／クリーンインストール、メモリ・ストレージチェック、sfc・DISM）を行っても BugCheck 0x4E が再発する場合は、次のような点も確認してみてください。
- 最近追加・更新した別のドライバー
- グラフィックドライバー
- ウイルス対策ソフトやセキュリティスイート
- 仮想ドライブ、バックアップソフト、システム監視ツールなど
- オーバークロックや XMP 設定
- メモリクロックや電圧をカスタムしていると、PFN エラーを誘発することがある
- 一度 BIOS 設定を「最適化された既定値」や「デフォルト」に戻して様子を見る
- 物理的なメモリモジュールの抜き差し
- メモリを 2 枚以上搭載している場合は、1 枚ずつにして動作確認する
- スロットを変えて挿し直すことで、接触不良が解消することもある
この段階まで来ると、原因は「チップセットドライバー単独」ではなく複合的な要因になっている可能性があります。ミニダンプを再度取得し、新たに現れたドライバー名やモジュール名がないかを確認していくことが有効です。
まとめ：正しいチップセットドライバーで BugCheck 0x4E と SrtTrail.txt ループを断ち切る
Windows 10 起動時の BugCheck 0x4E と、自動修復による SrtTrail.txt の「ハードディスクが見つからない」メッセージは、ぱっと見では「ストレージ故障」や「OS 消失」を連想させる深刻なエラーです。しかし：
sfc/chkdsk/DISMでは異常なし- ミニダンプ解析でチップセットドライバーが原因と判明
という条件がそろっているなら、まず疑うべきはストレージではなくチップセットドライバーです。
この記事で紹介したように、
- 製造元公式サイトからチップセットドライバーを入手し、上書きインストールする
- うまくいかない場合はデバイスマネージャーからクリーン削除して入れ直す
- BIOS のロールバックには安易に手を出さない
- メモリ診断・ストレージチェックでハードウェア故障も念のため確認する
といった手順を踏めば、多くのケースで BugCheck 0x4E と自動修復ループが解消することが期待できます。
最終的には、ミニダンプ解析で得られた情報をもとに「何が原因なのか」を冷静に絞り込み、順番に潰していくことが重要です。いきなり OS の再インストールやストレージ交換に踏み切る前に、チップセットドライバーの見直しから着手してみてください。
コメント