Windows Server 2022 Standard（クラウド環境）で、突然のBSOD後に自動再起動を繰り返す――イベントログに「bugcheck 0x00000192」と残り、直後にvolmgr警告が連発するケースは、ストレージスタックのドライバー競合が原因になりがちです。本記事では、volmgrx.sys と iaStorF.sys（Intel IRST）を軸に、原因の考え方と実務で効く切り分け手順をまとめます。
症状から読み解く：今回のポイント
まず整理したいのは「なぜハードウェア交換でも直らないのか」です。クラウド基盤側で物理機器を交換しても改善しない場合、OS（ゲスト）側のドライバーやフィルタが絡む“ソフトウェア起因”が濃厚になります。特にストレージ系は、物理障害だけでなくフィルタードライバー同士の相性でカーネルクラッシュが起きることがあります。
今回の事象は、次の組み合わせが揃っている点が重要です。
- イベントログに「The computer has rebooted from a bugcheck. The bugcheck was: 0x00000192…」が記録される
- ミニダンプ（
C:\Windows\Minidump\xxxxxx.dmp）が生成される - 直後に
volmgr関連の警告がまとまって出る - ダンプ解析で
volmgrx.sysが関与し、直前にiaStorF.sys（Intel IRST）が見える
| 観測できる現象 | 意味合い | 最初に見るべき場所 | 次の一手 |
|---|---|---|---|
| Bugcheck 0x00000192 | カーネルが「高いIRQLでロック取得」というルール違反を検出 | ミニダンプ／カーネルダンプ | 関与ドライバーの特定と更新・無効化 |
| volmgr 警告が連続 | クラッシュ前後のディスクI/Oやダンプ生成で異常が出ている可能性 | イベントビューア（System） | ディスク健全性確認、ダンプ設定確認、ストレージドライバー見直し |
| ハード交換でも再発 | 物理故障より、ゲストOS側のドライバー／構成が原因の可能性が上がる | デバイスマネージャ／driverquery | IRSTの要否を再評価し、構成を単純化する |
バグチェック 0x00000192 の意味：KERNEL_AUTO_BOOST_LOCK_ACQUISITION_WITH_RAISED_IRQL
0x00000192 は KERNEL_AUTO_BOOST_LOCK_ACQUISITION_WITH_RAISED_IRQL というバグチェックです。Windows が追跡しているロック（AutoBoost対象）をDISPATCH_LEVEL 以上の高いIRQLで取得してしまったことを検知したときに発生します。ユーザー視点では「突然のBSOD→自動再起動」に見えますが、中身はドライバー実装の不具合や相性で起きやすいタイプです。
加えて、Microsoft のバグチェック情報では、0x192 のパラメータ（括弧内の4つの値）は次の意味を持ちます。クラッシュダンプを読むときに“どこに注目すべきか”が明確になります。
| パラメータ | 内容 | 現場での読み方 |
|---|---|---|
| 1 | スレッドのアドレス | その時点で走っていた処理（スレッド）を特定する手がかり |
| 2 | ロックのアドレス | どのロックで違反が起きたか（ドライバーの内部状態に近い） |
| 3 | ロックを取得したIRQL | 「どれくらい高いIRQLでやってしまったか」を示す重要値 |
| 4 | 予約 | 通常は解析の中心になりにくい |
IRQL（割り込み優先度）は、カーネル内で「今このタイミングでやって良い処理／やってはいけない処理」を分ける大事なルールです。ストレージI/Oの完了処理やフィルタ処理が絡むと、“本来パッシブでやるべき処理を高IRQLでやってしまう”事故が起きやすく、結果として0x192で止まることがあります。
原因の方向性：volmgrx.sys と iaStorF.sys の“噛み合わせ”
ダンプで共通して volmgrx.sys（Volume Manager Extension Driver）内の処理で落ち、直前に iaStorF.sys（Intel Rapid Storage Technology：IRST のフィルタードライバー）からのI/O完了が見える場合、最も疑うべきはストレージスタック上の互換性問題（バグ）です。実際、同様の解析所見として「volmgrx!VmxpDiskExtentManageAttributesCompletionRoutine 付近でクラッシュし、直前に iaStorF から完了したI/Oが渡っている」パターンが報告されています。
ここで押さえておきたいのは、volmgrx.sys 自体はWindowsの中核ドライバーで、単体で“悪さをする”ことは通常ありません。にもかかわらず volmgrx がスタックに出続けるときは、その手前（下位）またはその上（フィルタ）にいるドライバーが、誤った前提でI/Oを完了させたり、IRQLの条件を崩したりしているケースが多いです。今回のように iaStorF.sys が見えるなら、IRSTがその候補になります。
| 層 | 代表コンポーネント | 役割 | ここで不具合があると… |
|---|---|---|---|
| アプリ／サービス | バックアップ、ウイルス対策、スナップショット | ファイルアクセスを発生させる／フィルタを挟む | I/O負荷増大、フィルタ競合 |
| ファイルシステム | NTFS/ReFS、フィルタ（MiniFilter） | ファイルの整合性・アクセス制御 | ファイルシステム破損やフィルタ衝突 |
| ボリューム管理 | volmgr.sys/volmgrx.sys | ボリューム／ディスク拡張の管理 | スタックに出やすい（原因の中心とは限らない） |
| ストレージコントローラ | iaStorF.sys など | コントローラ制御、I/O完了通知 | 高IRQLでの処理ミス、互換性問題でBSOD |
最優先でやる対処：安全度が高い順の切り分け
いきなり大改造をせず、影響が小さい順に切り分けるのがコツです。特にクラウド環境の本番サーバーでは、変更を最小化しつつ「再現頻度を下げる」「原因ドライバーを特定する」ことが目的になります。
Windows Update と Server 2022 の既知問題を確認
まずは累積更新プログラム（LCU）を含め、Windows Server 2022 を最新状態に寄せます。ストレージやクラッシュダンプ関連の修正はLCUに含まれることがあるためです。また、Server 2022 の既知の問題はリリースヘルス（Release Health）にまとまっています。自環境の現象に近い既知事象がないか、更新の適用状況と合わせて確認してください。
ストレージ／チップセット／IRST ドライバーを“更新またはロールバック”する
IRST 系は「最新版にすれば必ず安定する」とは限らず、特定の組み合わせでだけ不安定ということが現場ではよくあります。そのため、更新だけでなく一つ前の安定版に戻す判断も重要です。
- サーバーベンダー／クラウド事業者の推奨ドライバーを優先
- Intel の汎用ドライバーは、OEMカスタムがある場合に不一致を起こすことがあるため注意
現場でよく効くのは、次の確認です。
- 「実際にロードされている iaStorF.sys のバージョン」と「インストールされているドライバーパッケージ」が一致しているか
- 同じIRSTでも
iaStorF/iaStorAC/iaStorVDなど、構成が混在していないか
PowerShell での確認例（管理者）：
driverquery /v /fo table | findstr /i "iastor volmgr"
pnputil /enum-drivers | findstr /i "iastor"
Get-Item "C:\Windows\System32\drivers\iaStorF.sys" | Select-Object Name,Length,LastWriteTime
Get-Item "C:\Windows\System32\drivers\volmgrx.sys" | Select-Object Name,Length,LastWriteTimeIRST（iaStorF.sys）が必須でないなら“構成を単純化”する
クラウドのゲストOSで IRST が必須になるケースは限定的です（ゲスト内で本当にRAID制御をしている／特定の仮想SCSI実装で要求される、など）。一方で、IRSTが入っているだけでストレージスタックにフィルタが挟まり、相性問題のリスクは上がります。
RAID構成やベンダー要件で必須でないなら、次のいずれかをメンテナンス時間に試します。
- IRST ソフトウェア（管理コンソール等）をアンインストール
- ストレージコントローラーを Microsoft 標準ドライバーに切り替え（可能な場合）
重要：この操作は起動不能リスクがゼロではありません。クラウドならスナップショット／バックアップを取ってから、検証用の複製VMで先にテストするのが安全です。
サードパーティ製の“ストレージに触る系ソフト”を疑う
ウイルス対策、EDR、バックアップ、暗号化、重複排除、スナップショット系は、ファイルシステムフィルタやストレージ周辺にフックを入れることがあり、相性でクラッシュを引き起こすことがあります。まずは一時的に停止（または検証環境でアンインストール）して再発率が変わるかを見ます。
フィルタの確認例（管理者）：
fltmc filtersディスクとファイルシステムの健全性を確認する
volmgr 警告は、クラッシュダンプ生成のタイミングでI/Oが不安定だった場合にも出ることがあります。根本原因がドライバー競合でも、ディスク不整合や不良セクタがトリガーになって落ちることはあり得ます。論理・物理の両面で健全性を確認します。
- ファイルシステム整合性：
chkdsk - OSコンポーネント整合性：
SFC/DISM
chkdsk C: /f /r
sfc /scannow
DISM.exe /Online /Cleanup-Image /RestoreHealthログの取り方を整える：再発時に“勝てる証拠”を残す
原因がドライバー競合であるほど、再現性が低く「たまたま落ちた」で片付けられがちです。クラウド事業者やベンダーに調査を依頼するためにも、次の3点を整備しておくと話が早くなります。
| 残したい情報 | 目的 | 取得方法（例） |
|---|---|---|
| ミニダンプ／カーネルダンプ／完全メモリダンプ | 関与ドライバーとスタックの確定 | Startup and Recovery 設定、C:\Windows\Minidump、C:\Windows\MEMORY.DMP |
| System イベントログ（BugCheck/volmgr/storport/disk） | クラッシュ前後の時系列相関 | Get-WinEvent で抽出・保存 |
| ドライバー一覧（バージョン付き） | 互換性問題の切り分け | driverquery /v、pnputil |
クラッシュダンプ設定のおすすめ
ミニダンプで原因ドライバーのあたりが付くことは多い一方、ストレージスタックの複雑な競合は情報が足りないことがあります。状況に応じて「カーネルメモリダンプ」または「完全メモリダンプ」を検討します。完全メモリダンプはファイルが大きく、ページファイルや空き容量の要件があるため、クラウドのディスク構成・容量と相談しながら選んでください。
WinDbgで“最低限見るべき”チェック項目
ダンプ解析を自社で行う場合、最初の一手は「どのドライバーが関与したか」を確実に押さえることです。WinDbg では次の順に見ると迷いません。
!analyze -vでBUGCHECK_CODE/IMAGE_NAME/MODULE_NAME/STACK_TEXTを確認lmvm iaStorF/lmvm volmgrxで、実際にロードされているモジュールのバージョン・タイムスタンプを確認- 複数ダンプを比較し、毎回同じモジュール／同じ処理経路かを確認（再現性が高いほどドライバー起因の可能性が上がる）
クラウド事業者へ依頼する場合も、「0x192のパラメータ」「関与モジュール名（iaStorF / volmgrx）」「再発時刻と前後ログ」をセットで渡すと、調査が進みやすくなります。
イベントログ抽出の例
過去24時間など、範囲は環境に合わせて調整してください。
$start = (Get-Date).AddDays(-1)
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$start} |
Where-Object { $_.ProviderName -in @('Microsoft-Windows-WER-SystemErrorReporting','Microsoft-Windows-Kernel-Power','volmgr','disk','storport') } |
Select-Object TimeCreated,ProviderName,Id,LevelDisplayName,Message |
Export-Csv C:\Temp\System_BSOD_related.csv -NoTypeInformation -Encoding UTF8自動再起動の見直し
BSODが出た瞬間に画面がすぐ消えてしまい情報が読めない場合は、一時的に「自動的に再起動する」をオフにして、停止コードを確実にメモできるようにします（本番では影響もあるため、実施タイミングは要注意です）。
クラウド環境ならではの確認ポイント
クラウドでは、ゲストOSの上にハイパーバイザーと仮想ストレージがあり、オンプレよりも“境界”が増えます。次の観点で事業者に問い合わせると、調査が進みやすいです。
- 物理ホスト側のストレージファームウェア／ドライバーに既知障害がないか
- ハイパーバイザー更新（ホストメンテ）と再発タイミングが一致していないか
- 仮想ディスクの種類（SCSI/NVMe/専用ドライバー）と推奨ゲストドライバーの提示
- スナップショット・バックアップ・レプリケーションが走る時間帯と一致していないか
事業者に渡すと効く情報
| 渡すもの | 具体例 | 狙い |
|---|---|---|
| ダンプ | Minidump一式、必要なら MEMORY.DMP | 原因ドライバー／スタック確定 |
| イベントログ | System（.evtx）または抽出CSV | 前後のI/O異常や関連イベントの相関 |
| ドライバー情報 | ストレージコントローラ名、ドライバー提供元、バージョン | 既知の不具合組み合わせの照合 |
| OS更新状況 | Get-HotFix の結果 | 未適用修正の有無確認 |
再発防止の考え方：ドライバー“変更管理”を運用に組み込む
ドライバー起因のBSODは、1回直っても別の更新で再発することがあります。運用面では次の仕組みが効果的です。
- ストレージ／チップセット系は、OS更新と同じくらい慎重に段階適用（検証→少数→全体）
- ドライバー更新前後で、
driverquery /vの出力を保存して差分を取る - 再発時にすぐ出せるよう、ダンプ・ログの保管場所と手順をテンプレ化する
よくある質問
volmgr の警告が多い＝ディスク故障確定ですか？
確定とは言い切れません。volmgr はボリューム管理やクラッシュダンプ生成にも関わるため、クラッシュの前後で警告が増えることがあります。一方で、ディスクI/Oが不安定だとドライバーのバグを誘発することもあるので、chkdsk やストレージ診断、クラウド事業者の基盤監視結果と合わせて“トリガー”として扱うのが現実的です。
volmgrx.sys が落ちているのに、なぜMicrosoftのドライバーを疑わないの？
volmgrx.sys はストレージスタックの中心にいるため、スタック破壊や不正なIRQLでの完了処理があると“巻き込まれて”落ちやすいのが実情です。ダンプに iaStorF.sys のI/O完了が直前に出続けるなら、まずはその組み合わせ（IRSTとWindows側）を疑い、更新・無効化・構成単純化で再発率が下がるかを見ます。
結局、最短で効く対処は？
環境依存ですが、実務では次の順が“最短コース”になりやすいです。
- Server 2022 を最新の累積更新まで適用
- ストレージ／チップセット／IRST を推奨バージョンへ（必要ならロールバックも）
- IRST が不要なら外し、Microsoft標準ドライバーの構成に寄せる
まとめ
Windows Server 2022 の不定期再起動（Bugcheck 0x00000192）で、ダンプに volmgrx.sys と iaStorF.sys が繰り返し現れる場合、ストレージスタック上のドライバー互換性問題が強く疑われます。0x192 は高IRQLでのロック取得というカーネルルール違反を示すため、IRSTなどのフィルタードライバーを含めた更新・ロールバック、不要コンポーネントの削除による構成単純化が有効です。加えて、ログとダンプの取り方を整備し、クラウド事業者へ「時系列」と「ドライバー組み合わせ」を提示できる状態にしておくと、解決までの時間が短くなります。
コメント