学校内の同一ネットワークで、特定モデルのWindows 11端末が相次いでブルースクリーン（BSOD）を起こす――現場では「ハードは替えた、イメージも替えた、それでも直らない」という袋小路に陥りがちです。本稿では、VeryPCデスクトップ（ASUS Prime A520M‑A II）＋FOGでの展開・ドメイン参加後に発生するBSODを、アップデート／ファームウェア／ドライバー／初期負荷／ログ解析の5軸で段階的に切り分け、短期の回避と中期の恒久対策までを実務レベルでまとめます。
想定環境と症状の整理
- ハード構成：VeryPC デスクトップ、ASUS Prime A520M‑A II マザーボード、SSD（メーカー複数想定）
- 運用：FOGサーバーで検証済み Windows 11 イメージを展開、Sysprep後ドメイン参加
- 現象：ここ1か月で5〜10台が頻発BSOD→自動ドライブ検査（chkdsk）が走るケースあり
- 実施済み：SSD交換、新品RAM、別イメージ＝効果なし
- 手掛かり：ドメイン参加後にWindows Updateを実行すると発生しやすい。8月配信の累積更新が関与の可能性あり
何が衝突しているのか（原因の見立て）
同一ロットで複数台、短期間にBSODが顕在化する場合、以下の重なりが典型です。
- 品質更新（累積更新）でストレージ／I/O関連ドライバーの挙動が変わる
- BIOS・チップセット・SSDファームが古く、最新のWindows側挙動と境界条件で不整合
- 初期セットアップの高負荷（インデックス、Defender初回スキャン、UWP一括更新）がI/Oボトルネックを刺激
- ドメイン参加に伴うGPO適用・再起動が短時間に連続し、更新と競合
よって、①更新の制御→②ファーム／ドライバーの正常化→③負荷を下げる→④ログ根拠で原因を特定の順で攻めるのが、影響範囲を最小化しつつ成功しやすい手順です。
短期の暫定回避：更新の停止とドライバー抑制
Windows Updateを即時一時停止（最大35日）
イメージ展開直後に適用。GUI操作が難しい場合はスクリプトで一律適用します。
# 管理者PowerShell
# WUfBの品質更新を35日停止
New-Item -Path "HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings" -Name PauseQualityUpdatesStartTime -Type String -Value (Get-Date).ToString("o")
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings" -Name PauseQualityUpdatesEndTime -Type String -Value (Get-Date).AddDays(35).ToString("o")
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings" -Name PauseQualityUpdates -Type DWord -Value 1
グループポリシー／Intuneでの制御ポイント
| 目的 | ポリシー階層 / 設定名 | 推奨値 |
|---|---|---|
| 品質更新の延期 | コンピューターの構成 > 管理用テンプレート > Windows Update for Business > 「品質更新プログラムを延期する期間（日数）」 | 35日 |
| 即時一時停止 | 同上「最新の更新プログラムの受信を一時停止」 | 有効 |
| ドライバー更新の抑制 | コンピューターの構成 > 管理用テンプレート > Windows Update > 「Windows の品質更新プログラムにドライバーを含めない」 | 有効 |
| 再起動の使用時間 | コンピューターの構成 > 管理用テンプレート > Windows Update > 「アクティブ時間を自動的に調整」 | 有効（授業時間に再起動回避） |
問題更新のピンポイント除外（検証用）
問題のKBが推定できる場合は、テスト端末限定でアンインストールし再現性を見ます。
# インストール済み更新一覧（直近の品質更新を特定）
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10
# 例：KB番号がわかった場合のアンインストール
wusa /uninstall /kb: /quiet /norestart 同時に、DISM /Online /Get-Packages /Format:TableでパッケージIDを記録しておくと、ドライバー/スタック更新との関係を辿りやすくなります。
自動再起動を止め、ミニダンプを必ず残す
# BSOD後の自動再起動を停止し、ミニダンプを確実に取得
wmic recoveros set AutoReboot = False
wmic recoveros set DebugInfoType = 1 # 1: Small memory dump (Minidump)
wmic recoveros set OverwriteExistingDebugFile = True
# ミニダンプ保存先：C:\Windows\Minidump
ファームウェア＆ドライバーの整備（衝突の温床をなくす）
ASUS Prime A520M‑A II：BIOS更新と既定の見直し
- BIOSを最新化：ストレージ互換性やブート周りが改善される場合があります。
- 最適化デフォルトを読み込み（Load Optimized Defaults）後、以下を重点確認：
| 項目 | ポイント |
|---|---|
| CSM（Compatibility Support Module） | イメージ構成に合わせる（UEFI統一が理想）。レガシー混在は避ける。 |
| PCIe/NVMe | Autoで問題が出る場合、Gen指定の固定やAbove 4G Decodingを確認。 |
| SATA Mode | AHCIで統一。RAIDを無効（未使用なら）にして複雑性を下げる。 |
| SVM（仮想化） | Hyper-V/VDI要件に応じて明示的にON/OFF。中途半端な有効化は避ける。 |
AMD Chipset Driverの更新（PCIe/I/Oの土台）
古いチップセットドライバーは、Storport/StorNVMeの境界条件でBSODを誘発することがあります。最新のAMD Chipset Driverを適用し、インストール後は再起動→イベントログのクリーン度（警告129/153の消失）を確認します。
SSDファームウェアの更新
メーカー提供ユーティリティでファームを確認。世代違いが混在する学内では、特定型番のみBSODが連発するケースが典型です。型番別にFWバージョンと発生率をひも付けて記録しましょう。
新規24H2クリーンイメージでの再現性チェック
既存イメージの累積更新履歴や、ストアアプリのプリキャッシュがノイズになっている可能性があります。Microsoft公式ISOから24H2クリーンで構築し、次の順で最小構成を検証します。
- ネット未接続でクリーンインストール（ローカルプロファイル）
- AMD Chipset Driver → LAN/Audioなど必須最小ドライバーのみ導入
- 不要サービス停止（後述の初期負荷軽減）
- Sysprep /generalize /oobe /shutdown
- FOGでキャプチャ→テスト端末へデプロイ→更新を停止した状態でドメイン参加
- BSODが出るか観測。出ない場合、更新を1段ずつ解禁して原因を特定
初期セットアップの負荷を下げる（I/O嵐を作らない）
初回ログオン直後の数十分は、インデックス作成・Defender初回スキャン・ストア更新が重なります。BSODがI/O系の場合、この時間帯をやり過ごすだけで安定することも多いです。
推奨の一時的設定（デプロイ時に自動適用）
# 高速スタートアップを無効化（ハイバネーションOFF）
powercfg -h off
# インデックス一時停止（後で有効化可）
Stop-Service WSearch -Force
Set-Service WSearch -StartupType Manual
# ストア自動更新の遅延（教育現場での一斉更新を避ける）
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsStore\WindowsUpdate" /v AutoDownload /t REG_DWORD /d 2 /f
# Microsoft Defenderの初回スキャンを授業外にスケジュール
Set-MpPreference -ScanScheduleDay 7 -ScanScheduleTime 120 # 日曜2:00 数日安定稼働を確認できたら、インデックスやハイバネーションの設定は元に戻して構いません。
追加診断：停止コードと直前ログで原因を絞る
よく出る停止コードと仮説
| 停止コード | よくある要因 | 第一に試すこと |
|---|---|---|
| UNEXPECTED_STORE_EXCEPTION | ストレージI/O／ドライバー（Storport/SSD FW） | チップセット/ストレージドライバー更新、SSD FW更新、電源設定見直し |
| DPC_WATCHDOG_VIOLATION | NVMe/Storportタイムアウト、古いコントローラドライバー | NVMeドライバー切替/更新、イベントID129/153の前兆確認 |
| CRITICAL_PROCESS_DIED | システムファイル破損／更新直後の不整合 | SFC/DISM、最近の品質更新ロールバック |
| KERNEL_SECURITY_CHECK_FAILURE | 古いドライバー、RAM不良、ミニポート競合 | Driver Verifier短期実行、MemTest、周辺機器最小化 |
| INACCESSIBLE_BOOT_DEVICE | AHCI/RAID切替、ブートストレージドライバー不整合 | BIOSのSATAモード点検、DISMでドライバー注入、KBの影響切り分け |
ミニダンプの読み取り（BlueScreenView/WinDbg）
# 直近のミニダンプをコピー（収集用共有へ）
$src = "C:\Windows\Minidump"
$dst = "\\<fileserver>\BSOD_dump\$(Hostname)"
New-Item -ItemType Directory -Force -Path $dst | Out-Null
Get-ChildItem $src -Filter *.dmp | Sort-Object LastWriteTime -Descending | Select-Object -First 5 | Copy-Item -Destination $dst
# WinDbgで見る際の基本コマンド（例）
# .symfix; .reload; !analyze -v
犯人候補のドライバー名（例：storport.sys、stornvme.sys、amd_sata.sys等）が示されるので、該当ドライバーのバージョン差を「落ちる端末／落ちない端末」で比較します。
イベントログで直前の警告を拾う
- システム：ID 41（予期せぬ再起動）、ID 1001（バグチェック）
- Disk/Storport：警告ID 129（デバイスのリセット）、ID 153（繰り返しの再試行）、ID 51/7（I/Oエラー）
これらがBSOD直前に並んでいれば、I/O層の疑いが濃厚。チップセット／NVMe/SSD FWの更新優先度を上げます。
システム整合性の修復
# イメージの健全性確認と修復
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
# ファイルシステムのオンラインスキャン（オフライン修復は授業外に）
chkdsk /scan メモリ／ドライバー検証（限定的に）
# Driver Verifier（短期間・授業外で実行推奨）
verifier /standard /all
# 解除
verifier /reset
RAMは既に交換済みとのことですが、MemTestを一晩走らせて二重否定しておくと切り分けが明確です。
ドメイン参加後に起きやすい理由と、ネットワーク側の足場固め
- GPOの連続適用でサービス再起動が発生、更新と衝突しやすい
- WSUS/WUfBの整合性（両建て）は不安定化の温床：どちらかに統一する
- Defenderクラウド保護＋ストア更新＋OneDrive初回同期の三重負荷
授業開始直後のブート嵐を避けるため、電源投入の時差運用とアクティブ時間の一括設定を行います。さらに、教室・図書室など用途単位でQoSポリシーを設定し、更新トラフィックを授業時間に広げない工夫も有効です。
恒久対策：リング更新＋KIRウォッチ＋標準運用の明文化
リング更新モデル（推奨）
| リング | 対象台数 | 対象端末 | 運用 |
|---|---|---|---|
| Ring 0（ラボ） | 2〜3台 | テスト用／IT部門管理 | 新しい累積更新を受けて1週間監視。BSODやID129/153の有無を確認。 |
| Ring 1（パイロット） | 全体の10％ | 授業で重要度中の教室 | 2週間の安定確認。問題が出たらロールバック手順を記録・共有。 |
| Ring 2（全体） | 残り | 全教室・図書室・職員室 | 期末考査などイベント前の凍結期間を設定し、一括反映を避ける。 |
既知の問題ロールバック（KIR）の活用
品質更新に起因する既知の不具合は、MicrosoftのKIRで自動的に緩和される場合があります。KIRが出たかどうかは、グループポリシーで提供される専用テンプレートが配布されるケース（問題ごとのADMX/設定名が用意される）や、レジストリの緩和フラグで判断します。リング0/1の観測で、KIR適用後にイベントが静まるかを見極め、展開判断に反映します。
現場に役立つ一括点検表（BSODが出た端末に）
| 観点 | 点検内容 | 判定 | 備考 |
|---|---|---|---|
| 更新 | 品質更新を35日停止済み | 済 / 未 | Pauseフラグの開始・終了時刻を確認 |
| BIOS | 最新BIOS＋最適化デフォルト読込み | 済 / 未 | CSM/UEFI統一、SATA AHCI |
| チップセット | AMD Chipset Driver 最新 | 済 / 未 | 再起動後にID129/153が消えるか |
| SSD FW | 型番別にFW確認 | 済 / 未 | 発生率とFWバージョンを突合 |
| 初期負荷 | 高速スタートアップ/インデックス一時停止 | 済 / 未 | 数日後に戻す |
| ログ | Minidump収集・!analyze -v実施 | 済 / 未 | 容疑ドライバー名を控える |
| イベント | ID41/1001/129/153/51の直前相関 | 有 / 無 | I/O層が濃厚かを判断 |
| ドライバー | 「品質更新にドライバーを含めない」適用 | 済 / 未 | WUfB/WSUSの二重適用をしない |
FOG展開フローへの組み込み（再発を防ぐ標準化）
- Golden Imageの原則：24H2クリーン＋最小ドライバー＋更新停止済みでキャプチャ
- ポストデプロイスクリプト：更新停止・高速スタートアップOff・ミニダンプ設定を自動投入
- 初回ブート：ローカルで5〜10分アイドル（指数関数的バックグラウンド負荷を逃がす）
- ドメイン参加：GPOは「ドライバー含めない」「アクティブ時間」「自動再起動抑制」を先に適用
- 観測期間：1週間BSODが無ければ、インデックス/ハイバネーションを復帰
よくある質問（教育機関向け）
Q. SSDとRAMを替えてもBSODが続くのはなぜ？
品質更新とストレージドライバー/ファームの境界で、特定の負荷パターン（初期スキャン・同期）がトリガーになっている可能性があります。ハード単体の不良というより、バージョン組み合わせの問題であることが多いです。
Q. 8月の累積更新が怪しいが、特定するコツは？
リング0（ラボ）に限って、該当KBをアンインストール→再現確認→Get-HotFixとイベントログを比較。学内で「KB別の発生率」を表にすると、判断が早まります。
Q. ストレージ系のBSODかどうか、早見表は？
停止コードが上表のUNEXPECTED_STORE_EXCEPTION / DPC_WATCHDOG_VIOLATION、かつ直前にID129/153/51が並ぶなら、ほぼI/O層です。
付録：現場投入できるスクリプト集
① 更新の一時停止（35日）＋ドライバー含めない
# 更新停止（WUfB）
$k = "HKLM:\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings"
New-Item -Path $k -Force | Out-Null
Set-ItemProperty -Path $k -Name PauseQualityUpdatesStartTime -Type String -Value (Get-Date).ToString("o")
Set-ItemProperty -Path $k -Name PauseQualityUpdatesEndTime -Type String -Value (Get-Date).AddDays(35).ToString("o")
Set-ItemProperty -Path $k -Name PauseQualityUpdates -Type DWord -Value 1
# ドライバーを品質更新に含めない（GPO相当のレジストリ）
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v ExcludeWUDriversInQualityUpdate /t REG_DWORD /d 1 /f ② ミニダンプ強制＆自動再起動抑止
wmic recoveros set AutoReboot = False
wmic recoveros set DebugInfoType = 1
New-Item -ItemType Directory -Force -Path "C:\Windows\Minidump" | Out-Null
③ 初期負荷の抑制（後日戻す）
powercfg -h off
Stop-Service WSearch -Force
Set-Service WSearch -StartupType Manual
Set-MpPreference -ScanScheduleDay 7 -ScanScheduleTime 120
④ イベントログ＆ミニダンプ収集（共有へ）
$hostName = $env:COMPUTERNAME
$target = "\\<fileserver>\BSOD_collect\$hostName"
New-Item -ItemType Directory -Force -Path $target | Out-Null
# システムログ（直近3日）
wevtutil epl System "$target\System.evtx" /q:"*[System[TimeCreated[timediff(@SystemTime) <= 259200]]]"
# BugCheckログ
wevtutil epl "Microsoft-Windows-WER-SystemErrorReporting/Operational" "$target\WER_BugCheck.evtx"
# Minidump
Copy-Item "C:\Windows\Minidump*.dmp" -Destination $target -ErrorAction SilentlyContinue ⑤ 電源＆PCIeの安定化（I/Oタイムアウト緩和）
# 電源プラン：高パフォーマンスを作成/適用（必要時）
powercfg -duplicatescheme e9a42b02-d5df-448d-aa00-03f14749eb61
powercfg -setactive e9a42b02-d5df-448d-aa00-03f14749eb61
# PCIe Link State Power ManagementはGUIでオフ推奨（GPOでも可）
実行順ロードマップ（校内一斉対応の指針）
- 更新を止める（全台）：品質更新35日停止、ドライバー含めない
- ログを残す（全台）：自動再起動OFF、ミニダンプON、収集スクリプト配布
- ファーム＆ドライバー（対象群）：A520M‑A II BIOS、AMD Chipset、SSD FW
- 初期負荷を抑える（展開時）：高速スタートアップ/インデックス一時停止
- ラボでKB切り分け：問題KB疑いのロールバック検証
- リング展開へ移行：KIR観測と合わせて本展開判断
まとめ：原因の芯を突くために
今回のように「ドメイン参加後・更新実行で顕在化」「chkdskが走る」という手掛かりは、I/O層×品質更新を濃厚に示唆します。まずは更新を安全に止め、A520世代に適したBIOS/チップセット/SSD FWの三点セットを最新化。初期セットアップのI/O嵐を避けつつログを取り、停止コード・容疑ドライバー・イベントIDの三点で因果を固めます。最後にリング更新とKIR監視を標準運用へ落とし込めば、再発確率は大きく下がります。
参考：設定パス／操作のメモ（現場ポケット用）
- 自動再起動OFF：システムのプロパティ > 詳細設定 > 起動と回復 > 自動的に再起動する をOFF
- ミニダンプの場所：C:\Windows\Minidump
- イベントビューア：Windowsログ > システム、アプリケーション / アプリとサービスログ > WER
- ストレージの健全性：「ドライブのプロパティ > ツール > エラーチェック」およびS.M.A.R.T.確認
- 電源プラン：コントロールパネル > ハードウェアとサウンド > 電源オプション
- WSUS/WUfB統一：片方に寄せる（UseWUServerの整合に注意）
最後に：原因切り分けの黄金律
1変更＝1観測を守ると、真犯人に確実に近づけます。更新の停止→BIOS/ドライバー更新→負荷調整→ログ解析の順で、各ステップごとに「BSOD有無」「イベントID」「停止コード」を記録。校内で同型機が多いほど、同型・同FW・同KBという軸でのマトリクス分析が効きます。この記事の手順を、FOGのポストデプロイやGPOに落とし込み、標準運用として自動化していくことが再発防止の最短路です。
コメント