アプリを閉じた瞬間にWindows 11がフリーズしたりブルースクリーンになると、まずはグラフィックドライバーやメモリを疑いがちです。しかしイベントログに「svchost.exe が SRU.CHK にアクセスできない」と出ている場合、意外な犯人が「SRUDB.dat」という小さなデータベースファイルであることがあります。この記事では、SRUまわりの破損が原因で起こるクラッシュの仕組みと、安全に修復する具体的な手順を、初心者にもわかるように詳しく解説します。
症状の整理：アプリ終了直後にPCがクラッシュする
まずは、今回のトラブルでよく見られる症状を整理しておきます。あなたの環境とどれくらい一致しているかを確認してみてください。
- 複数のアプリをしばらく使ったあと、アプリを閉じた直後にフリーズやブルースクリーンが発生する
- イベントビューアーを見ると、svchost.exe が SRU.CHK へのアクセスに失敗しているログが残っている
sfc /scannowを実行しても「整合性違反は検出されませんでした」と表示される- 問題が発生している環境は主に Windows 11
これらが当てはまる場合、OSやハード全体の不具合というより、SRU（System Resource Usage Monitor）関連ファイルの破損・断片化が疑われます。
| 項目 | 典型的な状態 |
|---|---|
| 発生タイミング | アプリを終了した直後、あるいは大量のアプリを閉じたタイミング |
| OSバージョン | Windows 11（Home / Pro 問わず） |
| イベントログ | svchost.exe 関連のエラー、SRU.CHK へのアクセス失敗、アクセス権エラーなど |
| 事前に実施した対処 | sfc /scannow は問題なしと表示されている |
SRUとは？SRUDB.dat・SRU.CHKファイルの正体
原因に踏み込む前に、「SRUとは何か？」を簡単に押さえておきましょう。
SRU（System Resource Usage Monitor）は、その名の通り「システムリソースの使用状況」を記録するWindowsの仕組みです。アプリごとのネットワーク使用量や、バッテリー使用状況などを蓄積しており、タスクマネージャーや「バッテリー使用量」の画面などから参照されています。
| ファイル名 | 役割 |
|---|---|
SRUDB.dat | SRUのメインデータベース。アプリ・ネットワーク・電源状態などの履歴を保持する。 |
SRU.CHK などの *.CHK | ディスクチェック（ファイルシステム修復）時に作られる「復元用の断片ファイル」。元のファイルのかけら。 |
svchost.exe | 多数のWindowsサービスをホストする汎用プロセス。SRU関連サービスもこの配下で動作する。 |
SRUDB.dat はデータベースファイルなので、書き込み中に電源が落ちる・強制終了される・一部だけ上書きされる、といったことが起きると内部構造が壊れやすいという特徴があります。これを補うために、Windowsは修復処理の過程で SRU.CHK のような断片ファイルを作ることがあります。
ところが、この断片ファイルや破損したSRUDB.datが原因で、svchost.exe配下のサービスが延々エラーを吐き続ける → システムの安定性が損なわれる → クラッシュという流れになるケースがあります。
なぜアプリを閉じたタイミングでクラッシュするのか
「SRUの問題なのに、なぜアプリを閉じた瞬間に落ちるの？」と疑問に思うかもしれません。そのメカニズムをシンプルに分解すると次のようなイメージです。
- アプリを終了すると、Windowsは「アプリの実行時間」「ネットワーク使用量」「消費電力の統計」などをSRUDB.datに書き込みしようとする。
- ところが、SRUDB.dat が破損している、もしくは
SRU.CHKなどの断片と矛盾した状態になっている。 svchost.exe配下のSRU関連サービスが、この不整合なデータベースにアクセスしようとして例外やアクセス違反を起こす。- その結果、システムプロセスが巻き込まれ、ブルースクリーン（Stopエラー）やフリーズに発展する。
つまり、アプリ終了時は「SRUへの書き込みが集中的に行われるタイミング」でもあるため、SRUDB.datの破損が露呈しやすいというわけです。
最初にやるべきこと：SRUDB.datを削除して再生成させる
この問題に対して最も効果的で、かつ多くのケースで解決につながるのが、SRUDB.datを一度削除し、Windowsにクリーンなデータベースを作り直させる方法です。
作業前の注意事項
- 必ず管理者権限のアカウントで作業してください。
- SRUDB.datを削除すると、アプリの使用統計やネットワーク使用状況などの履歴がリセットされます（動作にはほぼ影響ありません）。
- 念のため、重要なファイルは事前にバックアップしておくことをおすすめします。
エクスプローラーからSRUDB.datを削除する手順
- キーボードの Windowsキー + E を押してエクスプローラーを開く。
- アドレスバーに次のパスを貼り付けて Enter を押す：
C:\Windows\System32\sru - フォルダ内にある
SRUDB.datを探す。 SRUDB.datを右クリックし、「削除」を選択する。- 削除が完了したら、PCを再起動する。
再起動後、Windowsは自動的に新しい SRUDB.dat を作成します。この時点で、SRU関連のデータベースは初期化された状態になり、破損によるエラーが解消されるケースが非常に多くあります。
環境によっては、再起動の過程で Cドライブの自動修復（チェックディスク）が走ることがありますが、これは想定内の動作です。
| 操作 | 結果 |
|---|---|
SRUDB.dat を削除 | 破損したデータベースが排除される。履歴データは消えるが、OS動作に大きな支障はない。 |
| 再起動 | Windowsが新しい SRUDB.dat を自動生成。必要に応じてディスクの整合性もチェックされる。 |
「ファイルが使用中で削除できません」と出る場合の対処
通常起動の状態だと、SRUDB.datがシステムによってロックされており、「このファイルは別のプログラムで使用されています」と表示されて削除できない場合があります。その場合は、セーフモードで起動してから同じ操作を行います。
回復オプションからセーフモードを起動する例
- スタートボタンを右クリックし、「ターミナル（管理者）」または「Windows PowerShell（管理者）」を開く。
- 次のコマンドを入力して Enter：
shutdown /r /o - 「Windowsをシャットダウンしますか？」の表示が出たら、そのまま待つとPCが再起動し、「オプションの選択」画面が表示される。
- 「トラブルシューティング」 → 「詳細オプション」 → 「スタートアップ設定」 → 「再起動」の順に選択。
- 再起動後に表示されるメニューで、「4）セーフモードを有効にする」を選択。
- セーフモードで起動したら、先ほどと同じように
C:\Windows\System32\sruを開き、SRUDB.datを削除する。 - 削除後、通常どおりPCを再起動してWindowsを起動する。
これでSRUDB.datの再生成が完了し、アプリ終了時のクラッシュが収まるかどうかを確認します。
SRUDB.dat削除で何が「修復」されているのか
SRUDB.datを削除するだけでなぜ改善するのか、内部で何が起きているのかをもう少し踏み込んで説明します。
- SRUDB.datは、アプリやネットワーク、電源状態のテレメトリ情報を蓄積するSQLite系データベースのような役割を持つ。
- ディスクの不整合や強制終了などで、データベースのインデックスやページ構造が壊れることがある。
- この状態のままアクセスを続けると、SRU関連サービスが例外（access violationなど）を起こす原因になる。
- SRUDB.datを削除すると、壊れたデータ構造そのものが消えるため、Windowsは空のクリーンなデータベースを新規に作成する。
- 結果として、svchost.exe配下のサービスは問題なくSRUDB.datに読み書きできるようになり、クラッシュループから抜け出せる。
副作用として、過去の履歴情報は失われますが、これは多くのユーザーにとって致命的なものではありません。むしろ、プライバシーの観点では「定期的にリセットされていても良い」部類のデータと言えます。
まだ落ちる場合：ミニダンプで原因を深掘りする
SRUDB.datを削除してもクラッシュが続く場合、より詳細な原因を探るためにミニダンプ（クラッシュ時のメモリダンプ）を確認するのがおすすめです。
ミニダンプファイルの場所を確認する
- エクスプローラーを開き、次のフォルダに移動する：
C:\Windows\Minidump - 拡張子
.dmpのファイル（例：120124-12345-01.dmp）があれば、それがクラッシュ時のミニダンプです。 - 念のため、別ドライブやデスクトップなどにコピーしてバックアップしておきます。
ミニダンプが存在しない場合は、「システムのプロパティ」から「起動と回復」の設定を確認し、「自動的にメモリダンプを保存する」などが有効になっているかチェックするとよいでしょう。
バグチェックコード（Stopコード）から当たりをつける
ミニダンプの詳細な解析には WinDbg などのツールが必要ですが、まず見るべきポイントはバグチェックコード（Stopコード）と疑わしいドライバー名です。
| 代表的なStopコード | 意味・傾向 | SRU関連との関係 |
|---|---|---|
NTFS_FILE_SYSTEM | NTFSファイルシステムの不整合やドライバーの問題が疑われる。 | SRUDB.datやSRU.CHKがあるCドライブの軽微な不整合が背後に潜んでいる可能性。 |
CRITICAL_PROCESS_DIED | 重要なシステムプロセスが異常終了した。 | svchost.exe配下サービスの異常終了がトリガーになっている場合がある。 |
KERNEL_DATA_INPAGE_ERROR | ディスクからの読み込みエラーなど、ストレージ寄りの問題。 | SRUだけでなく、SSD/HDDそのもののエラーも視野に入る。 |
Stopコードがストレージやファイルシステム由来のものに偏っている場合は、次章で紹介する DISM / SFC / CHKDSK を優先して実施する価値があります。
ストレージとOSの整合性チェック：DISM / SFC / CHKDSK の実行
SRU周りの破損は、しばしばその背後にディスクの不整合やシステムコンポーネントの軽い破損が潜んでいるサインでもあります。次の3つのコマンドを、以下の順番で実行することをおすすめします。
1. DISMでコンポーネントストアを修復
まずは、Windowsの「部品置き場」にあたるコンポーネントストアの整合性をチェック・修復します。
- スタートボタンを右クリックし、「ターミナル（管理者）」または「Windows PowerShell（管理者）」を開く。
- 次のコマンドを入力して Enter：
DISM /Online /Cleanup-Image /RestoreHealthネットワーク環境やPCの性能によりますが、数十分程度かかることがあります。途中で止まっているように見えても、できるだけ完了まで待ちましょう。
2. SFCでシステムファイルを検証・修復
DISMが終わったら続けて、SFC（システムファイルチェッカー）でWindowsシステムファイル本体の検証と修復を行います。
sfc /scannowすでに実行済みでも、DISM後にもう一度行うことで修復できるケースがあります。「破損したファイルを修復しました」と表示された場合は、念のためPCを再起動してから様子を見てください。
3. CHKDSKでCドライブのファイルシステムを検査
最後に、SRUファイルが存在するCドライブのファイルシステムをCHKDSKで検査・修復します。
chkdsk C: /f- 実行すると「次回の再起動時にチェックをスケジュールしますか？」と表示されるので、「Y」を入力してEnter。
- PCを再起動すると、起動前にCドライブの検査と修復が行われます。
- この過程で
*.CHKファイルが新たに作られたり、既存の断片が整理されることがあります。
| ツール | 主な役割 | どの層をチェックするか |
|---|---|---|
| DISM | コンポーネントストアの破損を検出・修復 | OSの部品置き場（イメージ） |
| SFC | システムファイル本体を検証して公式版に戻す | Windows本体のファイル |
| CHKDSK | ファイルシステムとディスクの論理エラーを修復 | NTFSファイルシステム、クラスタの整合性 |
この3ステップを終えた後に、再度SRUDB.datを削除 → 再起動を試すと、ファイルシステムレベルとOSレベルの両方がリフレッシュされた状態で検証できます。
再発防止のポイント：SRU破損を招きやすい行動を避ける
一度直っても、同じようにSRUDB.datが破損してしまえば再発してしまう可能性があります。以下のポイントを意識しておくと、SRU周りのトラブルを減らしやすくなります。
- 突然の電源断や強制終了を避ける
電源ボタン長押しやコンセント抜きは、ファイルシステムとデータベースにとって最悪のパターンです。フリーズしたように見えても、まずは Ctrl + Alt + Del や Win + X からのシャットダウンを試してください。 - クリーンアップ系ソフトでSystem32配下を不用意にいじらない
一部の「最適化」ツールやクリーンアップツールが、C:\Windows\System32\sru内のファイルを「不要ファイル」と誤認識して削除・ロックするケースがあります。こうしたツールを使う場合は、SRU関連フォルダを除外設定しておくと安全です。 - ストレージの健康状態を定期的に確認する
SSD/HDDのSMART情報を確認できるツールで、代替セクタ数や読み取りエラーが増えていないかチェックしましょう。物理的な劣化が進んでいると、SRUDB.dat以外にも様々なファイルが壊れやすくなります。 - Windows Updateとストレージ／チップセットドライバーを最新に保つ
ファイルシステムやストレージドライバー周りのバグ修正が含まれることも多いため、更新は基本的に適用しておく方が安全です。
よくある疑問へのQ&A
Q. SRUDB.datを削除しても本当に大丈夫？システムは壊れない？
A. SRUDB.datはテレメトリや統計情報のデータベースであり、削除してもWindowsの起動やアプリのインストールに直接必要なファイルではありません。削除後にWindowsが自動で新規ファイルを作り直す仕様なので、基本的には安全な対処です。ただし、念のためシステムの復元ポイントやバックアップを取ってから実施すると安心です。
Q. SRU.CHKを手動で削除してもいい？
A. *.CHK ファイルはファイルシステム修復の断片なので、状況によっては消せる場合もありますが、役割や状態を理解せずに削除するのは非推奨です。まずは CHKDSK を実行し、Windows標準の手順で整合性を取ることを優先しましょう。そのうえで自動的に不要になった断片は、システム側で整理されるのが理想です。
Q. sfc /scannow で問題なしと出たのに、なぜクラッシュが直らない？
A. SFCはあくまで「Windowsのシステムファイルそのもの」の整合性をチェックするツールです。SRUDB.datはユーザー環境ごとに内容が変わるデータベースであり、SFCのチェック対象外です。そのため、SRUDB.datが壊れていてもSFCでは検出されません。今回のようなケースでは、SFCだけでなくSRUDB.datの再生成やディスクの整合性チェックが必要になります。
Q. ミニダンプ解析が難しい場合はどうすれば？
A. WinDbgなどの解析ツールは確かに取っつきにくいですが、「Stopコード」と「怪しいドライバー名」だけでも控えておくと、サポート窓口やコミュニティで相談しやすくなります。どうしても自分で解析が難しい場合は、ミニダンプをバックアップしたうえで、専門のサポートやフォーラムに相談するのがおすすめです。
トラブルシューティングの流れを整理（チェックリスト）
ここまでの内容を、実際の作業フローとして整理すると次のようになります。
| ステップ | 作業内容 | 目的 |
|---|---|---|
| 1 | イベントログで「svchost.exe」「SRU.CHK」関連のエラーを確認 | SRUまわりの問題かどうかの当たりをつける。 |
| 2 | C:\Windows\System32\sru で SRUDB.dat を削除 → 再起動 | 破損したSRUデータベースを初期化し、クリーンな状態に戻す。 |
| 3 | 削除できない場合はセーフモードで同じ操作を実施 | システムによるロックを避け、安全に削除する。 |
| 4 | 改善しない場合はミニダンプ（C:\Windows\Minidump）を確認 | Stopコードや疑わしいドライバーから原因を深掘りする。 |
| 5 | DISM → SFC → CHKDSK の順で整合性チェック | OSコンポーネントとファイルシステムの不整合をまとめて解消する。 |
| 6 | 再度SRUDB.datを削除 → 再起動 → 動作確認 | 修復後のクリーンな環境でクラッシュが再発するか確認する。 |
まとめ：まずはSRUDB.datリセットで様子を見る
Windows 11で「アプリを閉じるとPCがクラッシュする」「svchost.exeがSRU.CHKにアクセスできない」といった症状がある場合、原因はハードウェアではなく、SRUDB.datの破損やSRUファイルの断片化であることが少なくありません。
- 第一優先：
C:\Windows\System32\sruのSRUDB.datを削除し、再起動して再生成させる。 - まだ落ちるとき：ミニダンプでStopコードを確認し、ストレージ・ファイルシステム系が怪しければ DISM / SFC / CHKDSK を順番に実行する。
- 再発防止：電源断や強制終了を避け、クリーンアップツールの設定やストレージの健康状態を見直す。
これらのステップを踏むことで、単なる「再インストール頼み」の解決ではなく、なぜクラッシュしていたのかを理解しながら根本原因にアプローチできます。Windows 11環境で同様の症状が出ている場合は、ぜひ本記事の手順を上から順に試してみてください。
コメント