
Windows 7/Server 2008 R2で「STOP 0x000000B8(ATTEMPTED_SWITCH_FROM_DPC)」がシャットダウン/休止で発生する原因と解決策
Windows 7 や Windows Server 2008 R2 環境で、シャットダウンや休止状態に入ろうとした瞬間にブルースクリーン(STOP エラー)が出て落ちる――この症状は、特定のストレージ/ネットワーク系拡張カード構成で起きやすい代表例があります。この記事では「STOP: 0x000000B8(ATTEMPTED_SWITCH_FROM_DPC)」が出る典型パターン、根本原因、現場での切り分けと再発防止までを、実務目線でまとめます。
0x000000B8(ATTEMPTED_SWITCH_FROM_DPC)とは何か
STOP 0x000000B8 は、カーネル内部の“割り込みに近い高優先度処理”である DPC(Deferred Procedure Call) 実行中に、「その場でやってはいけない待機・アタッチ・スレッド切替のような操作が行われた」場合に発生します。表示上は次のような形です。
-
STOP: 0x000000B8 (p1, p2, p3, p4) -
ATTEMPTED_SWITCH_FROM_DPC
4つのパラメータは環境やクラッシュ地点で変わるため、数値だけで断定はできません。ただし、後述の条件に合致するなら同系統の不具合である可能性が高まります。
起きやすい典型シナリオ(症状の特徴)
次の構成に心当たりがある場合、シャットダウン/休止で0xB8が出る“ハマりどころ”に入りやすくなります。
-
Windows 7 / Windows Server 2008 R2 を使用している
-
PCI-Express の Fibre Channel HBA や CNA(Converged Network Adapter) を増設している
-
その HBA/CNA に接続されたストレージを含む構成、またはブート経路に関与している(起動ディスクがHBA経由、SANブート等)
-
通常操作はできるのに、シャットダウン/休止のタイミングだけ 青画面になる
「普段は動くが電源状態遷移で落ちる」のがポイントで、ドライバの競合や特定のI/O終端処理が引き金になっていることが多いです。
根本原因:Pci.sys がDPC中に“禁止動作”を踏んでしまう
この症状でよく問題になるのが Pci.sys(PCIバス関連のシステムドライバ) の挙動です。DPC 処理中は、OSの設計上「待つ」「スレッドを切り替える」「特定の同期を取る」といった操作が厳しく制限されます。ところが特定条件下で Pci.sys が DPC中に許可されない操作(wait/attach/yield など) を試み、結果として 0xB8 が発生します。
重要なのは、0x000000B8 の原因は他にもあり得る点です。“Pci.sys が原因のケース”はあくまで一つの代表パターンなので、次の切り分けで確度を上げます。
まずやるべき切り分け(再現条件と証拠を固める)
1) 休止だけ/シャットダウンだけで落ちるかを確認
-
休止だけで落ちる:電源状態遷移(S4)関連のドライバが濃厚
-
シャットダウンだけで落ちる:デバイス停止・ドライバ解放の終端処理が濃厚
-
両方で落ちる:バス/ストレージ系の共通処理(PCI周り)を疑いやすい
2) ミニダンプ/メモリダンプを取得する
原因の確定にはダンプが最短です。最低でも ミニダンプ(%SystemRoot%\Minidump) が残る設定にしておきます。解析環境があるなら WinDbg で次を実行します。
lmvm pci
ここでスタックに pci.sys が絡み、HBA/CNA などのベンダードライバ(例:storport/miniport系)が近接していれば、今回の系統を強く疑えます。
解決策:優先順位の高い順に実施
対応1:Windows Update と既知修正(ホットフィックス/更新プログラム)を適用
この不具合は、OS側の修正で改善することがあります。特に Windows 7/Server 2008 R2 は更新の適用状況で挙動が変わりやすいため、以下を優先します。
-
OS を SP1 適用済みにする(未適用なら最優先)
-
可能な限り最新の更新プログラムを適用する
-
既知の修正(ホットフィックス)が提供されている場合は、その条件に合う環境へ適用する
ポイントは、修正は「この症状向け」であり、無関係な環境に闇雲に入れると別トラブルを招く可能性があることです。再現条件とダンプ根拠が揃っているときに適用するのが安全です。
対応2:HBA/CNA のドライバとファームウェアを“セットで”更新
電源状態遷移で落ちるトラブルの多くは、OS側だけでなく デバイス側のドライバ/ファーム不整合が関与します。
-
HBA/CNA の ベンダー公式ドライバを最新化(Microsoft標準よりベンダー提供が安定することが多い)
-
可能なら ファームウェア更新も同時に行う
-
既に最新で不安定なら、安定実績のあるバージョンへ ロールバックも検討
特にSANブートやマルチパス構成がある場合、ストレージ系は“組み合わせ依存”が強いので、ベンダーの互換表(推奨ドライバ/FW)に寄せるのが近道です。
対応3:当面の回避策(業務停止を防ぐ)
根治に時間がかかる場合、次の回避で被害を抑えられます。
-
休止状態の運用を停止し、シャットダウン/再起動に寄せる
-
逆にシャットダウンで落ちるなら、計画停止は再起動に寄せてダンプ採取を優先
-
不要なPCIeカードや周辺機器を外し、最小構成で再現性を確認(原因デバイスの特定に効く)
回避は一時しのぎですが、「いつでも落ちる」状態から「条件付きで落ちる」状態に変えるだけで、調査と復旧が一気に楽になります。
再発防止の実務ポイント
-
電源状態遷移(休止/シャットダウン)まで含めて、更新後の回帰テストを行う
-
HBA/CNA、マルチパス、ストレージ管理ツールなど“カーネルに近い層”は、更新を単体でやらず セット管理する
-
同じ型番でもFW世代が混在すると挙動差が出るため、資産台帳に ドライバ/FWの版数を残す
-
可能なら、重要サーバーは「休止を使わない」など運用ルールでリスクを減らす(特に旧OS)
まとめ
「STOP 0x000000B8(ATTEMPTED_SWITCH_FROM_DPC)」がシャットダウンや休止で出る場合、DPC中の禁止動作に起因する典型パターンがあり、PCI周り(Pci.sys)とHBA/CNAドライバの組み合わせがトリガーになり得ます。
最短ルートは、ダンプで根拠を固める → OS修正(更新/ホットフィックス) → HBA/CNAのドライバとFWを整合させるの順で手を打つこと。回避策も併用すれば、業務影響を抑えつつ確実に収束させられます。