Windows 11で突然ブルースクリーン（BSOD）が増え、イベントビューアーにイベントID 1001が大量に残る…。高性能自作PCほど原因が絞りにくいですが、ダンプ解析とDriver Verifierを使えば「犯人ドライバー」を特定できます。本記事は実例としてASUS AI Suite 3が原因だったケースの切り分け手順をまとめます。
症状の特徴：高負荷では安定、アイドル～ブラウジングで落ちやすい
自作PCが「組み立て直後は安定していたのに、ある時期からBSODが頻発する」パターンは珍しくありません。特に次の条件がそろうと、原因が見えにくくなります。
- CPU/GPU/メモリが強力（例：Core i9-14900KS、RTX 4080 SUPER、DDR5 64GB）
- 温度や電源容量は問題なさそう（高負荷テストは通る）
- ゲーム中よりも、YouTube視聴・SNS・ブラウジング・アイドルで落ちる
- イベントログにイベントID 1001が残り、ダンプが増え続ける
このタイプは「熱暴走」より、省電力状態への遷移や常駐ユーティリティの低レイヤ動作、ドライバーの相性が引き金になりやすいのが特徴です。
結論：イベントID 1001は“原因”ではなく、原因特定の入口
先に結論をまとめると、イベントID 1001は基本的に「バグチェック（クラッシュ）を検知し、ダンプを作成した」という記録です。つまり、イベントID 1001が出ている時点で「Windowsが落ちた」ことは確定しますが、何が落としたのかは別の情報で詰めます。
| 観測 | 意味 | 次にやること |
|---|---|---|
| イベントID 1001が多発 | クラッシュが起きた（結果） | 停止コードとダンプの場所を確認 |
| 解析でmemory corruptionの気配 | どこかがメモリを壊した可能性 | Driver Verifierで不正ドライバーを炙り出す |
| Driver Verifier後のダンプでASUS系が浮上 | 第三者ドライバーが直接の引き金 | ASUS AI Suite 3 / Armoury Crateを削除・クリーンアップ |
実例では最終的にASUS AI Suite 3（および関連ユーティリティ：Armoury Crate等）のドライバーが原因と判明し、削除と残骸クリーンアップでBSODが止まりました。
イベントID 1001とは：分かること／分からないこと
まずは「イベントID 1001＝原因」という誤解をほどきます。イベントビューアーに出る1001は、Windowsがクラッシュ後に再起動した際に残るログで、停止コード（BugcheckCode）やパラメータ、ダンプファイルの情報が含まれることがあります。
| イベントID 1001で分かること | イベントID 1001だけでは分からないこと |
|---|---|
| BSOD（バグチェック）が発生した事実 | 直接の原因ドライバー名（.sys） |
| おおまかな停止コード（BugcheckCode） | ソフト同士の相性、電源状態遷移の影響 |
| ダンプ作成の成否（保存先が出る場合も） | ハード故障かドライバー不具合かの断定 |
イベントビューアーで最低限チェックしたいポイント
調査の第一歩は「ログを眺める」ではなく、必要な情報だけを拾うことです。
- イベントID 1001の詳細：停止コード（BugcheckCode）やパラメータ、ダンプパスの有無
- Kernel-Power（イベントID 41）：突然の再起動や電源断が絡むか
- WHEA-Logger（例：イベントID 18/19/47など）：CPU/PCIe/メモリ周辺のハードエラーの気配があるか
特にWHEAが頻繁に出るなら、ドライバー以前にハード側（CPU設定、PCIe、メモリ、電源）の線が濃くなるため、後述の「定格化（XMP無効、BIOSデフォルト）」も優先度が上がります。
原因特定の準備：ダンプが確実に取れる状態にする
イベントID 1001の次に重要なのが「ダンプが解析できること」です。ダンプが取れていないと、切り分けは一気に難しくなります。
| 項目 | 目的 | 目安 |
|---|---|---|
| 自動再起動をオフ | 停止コードを読めるようにする | BSOD画面が一瞬で消えない |
| ダンプの種類 | 解析材料を残す | 「自動メモリダンプ」または「小メモリダンプ」 |
| ページファイル | ダンプ作成に必要 | システムドライブで有効 |
| 保存先 | 最新ダンプを追えるようにする | C:\Windows\Minidump / C:\Windows\MEMORY.DMP |
「ダンプが作成されない」場合は、ディスク空き容量、ページファイル設定、クリーンアップ系ソフトによる自動削除なども疑ってください。まずは最新のダンプを1つ確実に取ることが重要です。
アイドル時BSODで多い“真犯人”：第三者ドライバーによるメモリ破損
ダンプに「memory corruption」「IRQL」「page fault」などが出ると、初心者ほど「メモリが壊れた」と思いがちです。しかし実際には、ドライバーが不正なタイミングでメモリを触って壊す→結果として様々な停止コードで落ちる、という流れがよくあります。
ここで効くのがDriver Verifierです。通常運用では見逃されるような不正を、検証モードで表面化させ、ダンプに犯人を出しやすくします。
切り分けの王道：Driver Verifierで第三者ドライバーを検証
Driver Verifier（ドライバー検証ツール）は、ドライバーが本来やってはいけないメモリアクセスや整合性違反をした瞬間に、あえてBSODを起こして記録に残す仕組みです。普通の状態だと「どこかでメモリが壊れた」だけで終わるケースでも、Driver Verifierを使うと犯人ドライバー名（.sys）がダンプに出やすくなります。
実行前の注意点
- 検証中は意図的に落ちやすくなります。作業データを守るため、保存・バックアップ・復元ポイント作成を推奨します。
- 起動直後に落ちてしまう場合があります。そのときは後述の方法で解除できます。
実行例（提示されたコマンド）
管理者としてコマンドプロンプトを開き、次を実行します。
verifier /standard /all /bootmode resetonbootfail/allは全ドライバー対象になるため強めです。一般的には「Microsoft以外（第三者）ドライバーのみ」を対象にしたほうが安全に進めやすいので、GUI（verifierと入力して起動）で対象を絞る方法も覚えておくと安心です。
運用方法：普段通りに使い、BSODが出たら“新しいダンプ”を見る
設定後は、ベンチマークよりも普段落ちやすい状況（アイドル、ブラウジング、動画視聴）を再現します。BSODが出たら、その直後に作成された最新ダンプを解析します。古いダンプが大量にある場合は、必ず日付が新しいものから見てください。
解除方法：不安定すぎる／ブートループになったとき
起動できるなら管理者コマンドで解除します。
verifier /reset起動が難しい場合は、回復環境からセーフモードで起動して解除します。
- 電源投入後、Windowsロゴが出たら電源長押しで強制終了…を2〜3回繰り返し、回復画面へ
- 「トラブルシューティング」→「詳細オプション」→「スタートアップ設定」
- 再起動後に「セーフモード」（例：4キー）で起動
- 管理者コマンドで
verifier /resetを実行
メモリの確認も同時に：誤検知を減らすための安定化
Driver Verifierが効くとはいえ、土台のメモリ設定が不安定だと切り分けが混乱します。特にDDR5 64GBのような構成では、XMPが通っていても「環境によってはギリギリ」になりやすいので、いったん定格化して検証するのが安全です。
Windowsメモリ診断を「拡張（Extended）」で実行
mdsched.exeを実行し、再起動して診断開始- 開始時にF1キーでオプションを開き、Extendedへ切り替え
- 特定の%（例：20%前後）で何時間も止まる、再起動ループ、エラー表示が出る場合は要注意
BIOSでまず試したいこと
- XMPを一旦無効化して様子を見る
- メモリの周波数・電圧・タイミングがQVL（互換リスト）に沿っているか確認
- 自動OC（MCE/Enhanced Turbo等）を切り、まず定格で安定性を取る
WinDbgでミニダンプを解析する基本：まずは“ドライバー名”を拾う
最終的な答えはダンプにあります。完璧に理解しようとすると難しく感じますが、最初の目標は「怪しいドライバー（.sys）を見つける」だけで十分です。
最低限の流れ
- WinDbg（Preview）をインストール
C:\Windows\Minidumpの最新ファイルを開く- シンボル読み込み（例：
.symfix→.reload） !analyze -vで解析し、MODULE_NAME / IMAGE_NAMEを確認
よく使うコマンド例
!analyze -v
lm
lmvm ドライバー名
!verifier
!analyze -vの結果に特定のドライバー（例：xxxx.sys）が出れば、次のアクションが具体化します。逆に「memory_corruption」だけで終わる場合は、まだ犯人が隠れている可能性が高く、Driver Verifierを有効にした状態で取れた新しいダンプが効きます。
実例の最終原因：ASUS AI Suite 3（Armoury Crate等）のドライバー
この事例では、Driver Verifierを有効にした後のダンプ解析でASUS AI Suite 3関連ドライバーが原因と判明しました。ASUS系の常駐ユーティリティは、ファン制御、電圧監視、RGB制御、センサー読み取りなどのために、アプリだけでなくカーネルドライバーやサービスを導入します。
ここが不安定になると、ゲーム中よりも、むしろアイドル中に走る監視処理や省電力遷移のタイミングで破綻し、イベントID 1001とダンプが量産されることがあります。
ASUSユーティリティが不安定要因になりやすい理由
- Windows更新やBIOS更新で内部挙動が変わり、ユーティリティが追従できない
- センサー監視ツールを複数入れると、同じハードに同時アクセスして競合しやすい
- RGB/ファン制御が低レイヤに触るため、電源管理（スリープ/復帰/省電力）と衝突しやすい
対処：アンインストール＋残骸クリーンアップで止まることがある
単純なアンインストールだけでは、ドライバーやサービス、タスクが残ることがあります。実例では次の対応でBSODが止まりました。
| 対象 | やること | ポイント |
|---|---|---|
| Armoury Crate | アンインストール（必要なら専用アンインストールツールも活用） | 関連サービス/タスクが残っていないか |
| AI Suite 3 | アンインストール＋クリーナー（AI Suite 3 Cleaner等）で残骸削除 | ドライバー（.sys）やサービスが残っていないか |
| 再インストールの抑止 | BIOSの「Armoury Crate Download & Install」を無効化 | 削除しても勝手に復活するのを防ぐ |
| 再起動 | 削除後に必ず再起動 | 同じ使い方で再発しないか確認 |
最後の「BIOS側のArmoury Crate自動導入」が見落としポイントです。削除したのに数日後にまた不安定になる場合、バックグラウンドで再導入されている可能性があるため、必ず確認してください。
削除できたかの確認：残ったドライバーやサービスをチェック
「アンインストールしたはずなのに怪しい」と感じる場合、まずは“存在確認”だけでもすると状況が見えます。
C:\Windows\System32\drivers配下にASUS関連の.sysが残っていないか- サービス（
services.msc）にASUS関連が残っていないか - タスクスケジューラにASUS関連タスクが残っていないか
pnputil /enum-driversでASUS提供のドライバーパッケージが残っていないか
ドライバーの強制削除（pnputil /delete-driverなど）は状況次第でリスクもあるため、まずは専用の削除ツールや公式手順で落とし切れるかを優先してください。
それでも直らない場合の次の一手：優先順位つきチェックリスト
ASUSユーティリティの削除で改善しない場合は、同じ症状でも別ルートがあり得ます。優先度順に潰していくと迷いにくいです。
| 優先度 | 確認項目 | 狙い |
|---|---|---|
| 高 | BIOSを最新安定版へ更新し、設定を一旦デフォルトへ | マイクロコード/電力制御/互換性の改善 |
| 高 | XMP無効で安定するか | DDR5大容量の境界不安定を切り分け |
| 高 | WHEA-Loggerが出ていないか | ハード系エラーの兆候を早期に把握 |
| 中 | チップセット/ME/LAN/Wi-Fi/オーディオを公式ドライバーへ | 割り込み系ドライバーの不具合修正 |
| 中 | GPUドライバーのクリーンインストール（不要な常駐機能を外す） | オーバーレイ/録画/フック競合を排除 |
| 中 | 電源プランで「PCI Expressのリンク状態の電源管理」をオフにして様子を見る | 低電力遷移がトリガーか確認 |
| 低 | SSDファーム更新、接続ポート変更、ケーブル確認 | I/O起因の例外を排除 |
再発を防ぐ運用：高性能自作PCは“必要最小限”が最強
高性能環境ほど「監視・制御のための常駐」を増やしがちですが、安定性を優先するなら、むしろ引き算が効きます。
- ファンカーブは可能ならBIOS側（Q-Fan等）で完結させる
- RGBは設定したら常駐を切る、または常駐を最小化する
- 温度/電圧監視ツールは同時に複数走らせない
- 更新（Windows/BIOS/ドライバー）の直後は、問題が出る前に「追加された常駐」を見直す
まとめ：イベントID 1001を見たら、ダンプ解析とDriver Verifierで原因を名指しする
Windows 11でイベントID 1001が頻発する場合、ログ自体は「クラッシュした」という結果を示すだけで、原因の特定にはダンプ解析が欠かせません。特に「アイドル/ブラウジング中に落ちる」タイプは、常駐ユーティリティや省電力遷移が絡みやすく、Driver Verifierが決定打になりやすいです。
実例ではASUS AI Suite 3（およびArmoury Crate等）のドライバーが原因で、アンインストールとクリーンアップでBSODが止まりました。同じ症状で悩んでいる場合も、まずは第三者ドライバーの検証→ダンプ解析→怪しい常駐の排除という順で進めると、最短で答えにたどり着けます。
コメント