Azure Migrate（ASR）でWindows Server 2008 R2をAzureへP2V移行したら、再起動/シャットダウン時だけ0x9F（DRIVER_POWER_STATE_FAILURE）が発生――。動的ディスク（スパン）＋MPIO構成で起きやすい落とし穴と、現場で再現性の高い切り分け・移行手順を整理します。
今回の現象を整理：移行はできるのに、電源操作でだけBSODが出る
Azure Migrate（Server Migration）/ Azure Site Recovery（ASR）を使った移行では、「レプリケーションは進む」「テスト移行で起動もする」一方で、本番カットオーバー後の再起動/シャットダウンでだけ問題が噴き出すことがあります。今回のケースは、まさにその典型です。
- 対象OS：Windows Server 2008 R2
- ディスク構成：動的ディスクのスパン（結合）ボリュームを多数（約10本）
- 接続形態：MPIO（Microsoft DSM）構成
- 移行後の症状：0x0000009F DRIVER_POWER_STATE_FAILURE（再起動/シャットダウン時）
- 当初はvolmgrsx.sys、解析を進めるとvolsnap.sysが疑われた
- 再起動/シャットダウンが極端に遅い（タイムアウト級）
ここで重要なのは、「動的（スパン）＋MPIO」という構成そのものが移行で完全サポートなのか、そしてサポート外要素があるならデータ損失なくどう移行するのか、という2点です。
まず結論：動的（スパン）自体は条件付きでOK、ただし“ゲストMPIO”は非サポート
Microsoftのサポートマトリクスを見ると、ポイントは次の通りです。
| 項目 | サポート | 実務上の意味（落とし穴） |
|---|---|---|
| OSディスクが動的ディスク | 不可 | 移行（レプリケーション）に乗っていても、途中で制約に当たることがあります。OS側の変換が必要になるケースがあります。 |
| データディスクが動的ディスク | 可 | 「データ側だけ動的」は許容される前提。ただし、後述のフィルタドライバ問題などは別軸で起きます。 |
| データディスクのスパン（結合）ボリューム | 可 | スパンだから即アウト、ではありません。ただし構成が複雑なほどトラブル時の切り分けが難しくなります。 |
| ゲスト（OS）側のMultipath（MPIO） | 不可 | 移行後のAzure VM内でMPIOを維持する前提は危険です。原因不明の停止・遅延・BSODの温床になり得ます。 |
ここで混同しやすいのが「MPIOが完全にダメなのか？」という点です。サポートマトリクスにはHost multipath（ホスト側）はテスト済みとして記載される一方、Guest/server multipath（ゲストOS側）は明確に“NO”です。つまり、ストレージの冗長化はホスト/基盤側で担保するが、ゲストOS内にMPIOを持ち込む構成は想定外、という読み方が安全です。
また、Azure Migrate側のサポートマトリクスでも、Dynamic OS diskは非サポート、Multipath IOは非サポートとして明記されています。加えてWindows Server 2008/2008 R2などEOSのOSは、移行の結果が安定しない可能性があるためアップグレード推奨、という注意書きもあります。
0x0000009F DRIVER_POWER_STATE_FAILUREとは：電源遷移でドライバが“完了できない”状態
0x9Fはざっくり言うと、電源状態の遷移（シャットダウン/再起動/スリープ等）において、ドライバが要求（Power IRP）を完了できずにタイムアウトや不整合を起こしたときに発生するバグチェックです。典型的には「シャットダウンが異常に長い → 最終的にBSOD」になりやすいタイプです。
Microsoft Learnの説明では、0x9Fは「ドライバが不整合または無効な電源状態にある」ことを示し、原因としては「未完了の電源要求が残っている」「電源遷移がタイムアウト」「IRPをブロックしている」などが挙げられています。
現場目線で理解しやすいよう、0x9Fの“よくある型”を表に落とすと次のイメージです（詳細解析はダンプに依存します）。
| 典型パターン | 起きていること | 現場で疑うべきもの |
|---|---|---|
| IRPが詰まる | デバイススタックのどこかがPower IRPを長時間ブロックし、電源遷移が完了しない | ストレージ/バックアップ/AV/暗号化/フィルタドライバ、MPIO/DSM、古いドライバ |
| PnP同期で詰まる | PnPサブシステムとの同期待ちがタイムアウトする | デバイスの入れ替わり（移行後の仮想ハード変更）、不整合なドライバ残骸 |
| 完了処理が不正 | IRPは完了したように見えるが、電源IRPの正しい後処理がされない | 古い/壊れたドライバ、互換性の低いフィルタドライバ |
volmgrsx.sys / volsnap.sys が疑われるときの見立て：本体より“周辺ドライバ”を疑う
今回のケースでは当初volmgrsx.sysが疑われ、後の解析でvolsnap.sysが原因として浮上しました。ざっくり役割を整理すると、次のように捉えると理解が進みます。
- volmgrsx.sys：ボリューム管理（特に動的ディスク系）に関わる層に近い
- volsnap.sys：VSS（Volume Shadow Copy）やスナップショット、バックアップ/保護系の仕組みに近い
そして、ここが実務の勘所なのですが、volsnap/volmgr系がダンプに見えていても、それが“真犯人”とは限りません。理由は単純で、ディスクI/Oの経路にはAVやバックアップ、暗号化、監査系などのフィルタドライバが入り込みやすく、電源遷移でのフラッシュやクローズ処理で詰まりやすいからです。
事例で決定打になった対処：Symantec Endpoint Protectionの残骸をCleanWipeで完全削除
Microsoft Q&Aのスレッドでは、質問者がクラッシュダンプを解析した結果、volsnap.sysが根にあると推定し、「過去に入っていたSymantec Endpoint Protection（SEP）がアンインストール済みでも残骸が残り、ディスク/スナップショット系ドライバに干渉しているのでは？」という仮説に到達しています。そして、ベンダーのクリーンアップツールCleanWipeを実行したところ、再起動時のBSODが止まったと報告されています。
さらに回答側も「AV（アンチウイルス）はBSOD要因になり得る」と認めています。つまり今回の“効いた一手”は、ディスク構成そのものをいじる前に、フィルタドライバ（特にAV）を完全削除して切り分けたことです。
この流れは汎用性が高く、Azure移行に限らず「環境が変わった直後だけ電源操作で落ちる」系の障害で、最短で勝ちやすいパターンです。
最短で原因に辿り着く切り分けフロー（移行案件で使える現実解）
「動的（スパン）＋MPIOだから仕方ない」と決めつけてしまうと、必要以上に移行設計が重くなります。まずは再現性の高い順番で潰していくのが得策です。
- ゲストMPIOの“必要性”をゼロベースで見直す（Azure上で本当に要るか？）
- AV/バックアップ/暗号化などのフィルタドライバを“完全削除”して再現確認
- クラッシュダンプで0x9FのパラメータとブロックしているIRP/デバイススタックを確認
- OSディスクが動的なら、サポート要件に合わせて基本ディスクへ
- スパン構成は“動かす”のではなく“卒業する”設計（データ移行）を検討
現場でそのまま使えるチェックリストも置いておきます。
| チェック項目 | 確認方法（例） | NGだった場合の対処 |
|---|---|---|
| Azure Migrateのサポート要件（Dynamic OS / MPIO） | サポートマトリクスを確認し、構成を棚卸し | OSディスクが動的なら変換/再構築、ゲストMPIOは撤去方針へ |
| MPIO/DSMの有無 | mpclaim -s -d | Azure側で不要ならMPIO機能/DSMを無効化・アンインストールして比較 |
| フィルタドライバの棚卸し | fltmc filters | AV/バックアップ/暗号化/監査系を“完全削除”し、再起動で再現確認 |
| 0x9Fの解析（IRP詰まり） | WinDbgで!analyze -v → Arg/IRP/スタック確認 | 詰まっているドライバ/デバイスを特定し、更新・削除・置換 |
| 動的→基本への変換可否 | ディスク管理でOS/データの種別を確認 | Windows標準の変換は「ボリューム削除前提」。無停止変換は慎重に設計 |
「データ損失なく移行」するための現実的な選択肢
結論から言うと、“動的→基本ディスク変換を無停止・無損失でやり切る”ことを主戦略にするのは危険です。理由は、Windows標準手順ではボリューム削除（＝事前バックアップ/退避）を前提としているためです。
では、移行プロジェクトで「データ損失なく」を成立させるには、どう組むべきか。おすすめの考え方は次の3パターンです。
| パターン | 狙い | ダウンタイム感 | 向いている条件 |
|---|---|---|---|
| A：構成維持で移行 | スパンは維持し、まずはAzureで“動かす” | 短い（最終同期＋切替） | OSディスクが基本、ゲストMPIOを撤去できる、フィルタドライバを整理できる |
| B：Azure側で受け皿再設計 | Azureで新しいディスク設計に作り替えてデータを移す | 中（コピー時間は必要） | 長期運用を見据えたい、動的ディスクを卒業したい、性能/運用を最適化したい |
| C：OS再構築＋データ移行 | OSは新規、データだけ移す（リフトではなくリプレース寄り） | 中〜長（検証多め） | Windows Server 2008 R2を延命したくない、アプリ更改も視野 |
特にBは、Azure移行後の運用で効いてきます。動的ディスクはMicrosoft Learnでも「現在は非推奨（deprecated）で、新規では推奨されない」とされ、代替として基本ディスクやStorage Spacesが挙げられています。移行を機に“卒業”する設計は、障害対応・運用標準化のコストを下げやすいです。
Azure Migrate（ASR）移行の“ゼロデータ損失”の考え方：最後は停止して最終差分同期
「データ損失なく移行」と言うと、ディスク変換に目が行きがちですが、Azure Migrateの移行手順そのものが最終カットオーバー時にソースを停止し、最後の差分同期を流すことで“ほぼゼロ損失（少なくとも意図したRPO）”に寄せる設計です。
公式の説明でも、最終的なMigrate操作の際にソースをシャットダウンして最終増分レプリケーションを行い、そのレプリカからAzure VMを作る流れが示されています。つまり、切替の瞬間に止めるのはサーバーであって、データは最後に合わせ込むのが基本戦略です。
ただし重要な注意点として、最終移行後にオンプレ側を止めた段階で、Azureからオンプレへ“ロールバック”はできないと明記されています。テスト移行で十分に検証し、切替手順（戻し手順含む）を別途用意しておくのが安全です。
動的ディスク→基本ディスク変換の注意点：Windows標準は“ボリューム削除前提”
「サポート外なら動的→基本に変換してから移行したい」という相談は多いのですが、Windows標準機能だけで安全にやろうとすると、基本的に次の前提になります。
- 変換前にデータをバックアップ/退避する
- 対象ディスク上のボリュームを削除する
- その後に基本ディスクへ変換する
つまり、無停止で「変換だけ」やって解決、という発想は取りにくいです。移行プロジェクトでの現実解としては、次のどちらかを選ぶことが多いです。
- （短期）サポート範囲で動く構成に寄せてまず移行（例：ゲストMPIO撤去、フィルタドライバ整理）
- （中長期）Azure側で新ディスクを用意し、データ移行で“動的ディスク卒業”
再発防止：移行前後でやっておくと事故が減るポイント
最後に、同種の0x9F（特にストレージ周り）の再発を減らすための実務ポイントをまとめます。
移行前（オンプレ側）
- ゲストMPIOを使っている理由を棚卸しし、Azure側で代替できるか判断（多くの場合、維持するメリットが薄い）
- AV/バックアップ/監視など、フィルタドライバを入れる製品は一覧化（アンインストールしたつもりの残骸が一番危険）
- テスト移行を前提に、切替手順（停止→最終同期→起動→疎通）を標準化
移行後（Azure側）
- まずは再起動/シャットダウンを複数回行い、0x9Fの再現性を確認（「たまたま直った」を排除）
- 原因切り分けが終わるまでは、AVは「入れ直す/戻す」を焦らない（戻した瞬間に再発しやすい）
- 動的スパンを維持した場合でも、次の更改タイミングで基本ディスク＋Storage Spaces等へ段階移行するロードマップを作る
まとめ：0x9Fは“動的ディスクだから”ではなく、“電源遷移に耐えないドライバ”から疑う
今回のポイントを短くまとめると次の通りです。
- 動的ディスク（データ）やスパンはサポートされ得るが、OSディスクの動的は不可
- ゲストOS側のMPIOは非サポート。維持前提の移行は危険
- 0x9Fは「電源遷移でドライバが完了できない」系。AV/バックアップ等のフィルタドライバ残骸が刺さりやすい
- 実例ではSymantec Endpoint Protectionの残骸をCleanWipeで除去して解決
- “データ損失なく”を成立させるなら、無理な変換より最終差分同期＋切替を軸に、必要ならAzure側で受け皿を再設計する
コメント