Windows Server 2025 KB5062553 適用後に発生する IRQL_NOT_LESS_OR_EQUAL ブルースクリーンの原因と対処法まとめ

Windows Server 2025 に 2025 年 7 月以降の累積更新プログラムを適用すると、AMD EPYC ベースの物理サーバーで IRQL_NOT_LESS_OR_EQUAL ブルースクリーンが連発する──そんな報告が世界中の管理者から上がっています。本記事では、特に KB5062553 以降で問題が目立つ環境を整理し、すぐに取るべき回避策から恒久対策、運用設計の見直しポイントまでを、実運用目線で詳しく解説します。

Windows Server 2025 KB5062553 適用後に発生するブルースクリーンの全体像

どんなときに IRQL_NOT_LESS_OR_EQUAL が発生しているのか

現在、国内外のフォーラムやブログで共通して報告されているパターンは以下のようなものです。

• 対象 OS：Windows Server 2025 Standard / Datacenter（OS ビルド 26100 系）
• 問題となる更新：2025 年 7 月以降の累積更新
  • KB5062553（OS ビルド 26100.4652） – 2025-07-08 公開
  • KB5064489（26100.4656, OOB） – 2025-07-13 公開
  • KB5063878（26100.4946） – 2025-08-12 公開
• 問題が出ていないとされる直前の安定ビルド：KB5060842（26100.4349, 2025-06-10）
• 再起動後ログオン直後〜数分以内にブルースクリーン（Stop: IRQL_NOT_LESS_OR_EQUAL）
• ブルースクリーン画面の「What failed」には多くのケースで ntoskrnl.exe と表示
• クリーンインストール直後に更新を当てても再現するケースがある

これらのビルドと KB 番号の対応は、Microsoft の公式「Windows Server release information」にも一覧として掲載されています。

発生が報告されているハードウェア構成の傾向

現時点で報告が集中しているのは、主に AMD EPYC 搭載の物理サーバー です。特に下記構成での事例が多数共有されています。

観点	内容
CPU	AMD EPYC 7443 / 7443P / 7402P など Rome / Milan 世代
HPE サーバー	HPE ProLiant DL325 Gen10 / Gen10 Plus v2（EPYC 7443P, 7402P 構成）
その他サーバー	GIGABYTE H252‑Z10‑00、Supermicro H12SSL 系マザーボード搭載機
仮想化	多くの報告は「ベアメタル（ハイパーバイザーなし）」構成
ブートモード	Legacy BIOS モード での再現報告が目立つが、UEFI でも発生したという声もある
ストレージ	RAID コントローラー／NVMe ストレージなどを搭載。特定ベンダーに偏りはあるが決定打ではない

Microsoft Q&A や海外ブログでは、上記のような構成で「KB5062553 を適用すると IRQL_NOT_LESS_OR_EQUAL が発生し、KB5060842 までは安定していた」という報告が複数確認できます。

影響を受ける更新プログラムの整理

問題発生の有無をビルド単位で整理すると、概ね次のような傾向になります（あくまで報告ベースの情報です）。

更新プログラム	OS ビルド	状況（報告ベース）	備考
KB5060842	26100.4349（2025-06-10）	多くの環境で「安定」と報告	問題発生前の基準ビルドとして扱われることが多い
KB5062553	26100.4652（2025-07-08）	IRQL_NOT_LESS_OR_EQUAL 多数報告	AMD EPYC + HPE/Supermicro/GIGABYTE などで BSOD
KB5064489（OOB）	26100.4656（2025-07-13）	同様の症状報告あり	KB5062553 の後追い適用でも再現する事例
KB5063878	26100.4946（2025-08-12）	一部環境で BSOD 継続	6〜8 月の一連の更新で再現するケースも
KB5072359（OOB）	26100.7178（2025-11-18）	IRQL_NOT_LESS_OR_EQUAL を修正する旨の記載あり	ただし AMD EPYC 固有問題かどうかは明記されていない

なお、Microsoft の「Resolved issues in Windows Server 2025」では、KB5062553 の既知の問題としては「Changjie IME」や一部 Azure VM の起動失敗などが挙げられているのみで、IRQL_NOT_LESS_OR_EQUAL は公式の既知の問題として明示されていません（2025年11月時点）。

一方、Windows Server 2025 用の OOB 更新 KB5072359（OS ビルド 26100.7178） では、クロスロケールのサマリーページにて「Windows が停止し、IRQL_NOT_LESS_OR_EQUAL エラーを生成する問題を修正する」という記述も確認できます。ただし、AMD EPYC + 特定プラットフォームの組み合わせで発生した現象をピンポイントに解決するものかどうかは明示されていないため、本番展開前に必ず検証環境での確認が必要です。

直ちに業務影響を止めるための回避策

KB5062553 など問題の更新をアンインストールする

最優先で行うべきなのは、ブルースクリーンを引き起こしている更新プログラムをロールバックして、サーバーを安定ビルドに戻すことです。

OS が起動できる場合（ログオン可能な場合）

GUI からアンインストールする方法に加え、コマンドラインで一括対応することもできます。

• コントロールパネル >［プログラムと機能］>［インストールされた更新プログラムを表示］で KB5062553 を選択し削除
• または、管理者権限のコマンドプロンプト／PowerShell で以下を実行

wusa /uninstall /kb:5062553

一度でロールバックしきれない場合は、KB5064489 や KB5063878 など、同系統ビルドを順にアンインストールしていき、26100.4349（KB5060842）など安定ビルドまで戻すのが現実的です。

OS が起動しない場合（起動直後に BSOD）

既にブルースクリーンが連発して通常起動できない場合は、Windows 回復環境（WinRE） を利用してアンインストールします。

1. 電源投入後に数回強制電源断を行い、自動的に WinRE を起動させる（またはインストールメディアから［コンピューターを修復する］を選択）
2. ［トラブルシューティング］>［詳細オプション］>［更新プログラムのアンインストール］を開く
3. 「最新の品質更新のアンインストール」を選択し、直近の累積更新を削除

GUI のアンインストールでうまくいかない場合や、自動化したい場合は、オフライン DISM で該当パッケージを除去する方法が有効です。

dism /image:D:\ /get-packages | findstr KB5062553
dism /image:D:\ /remove-package /PackageName:<上で列挙されたPackageName>

ここで D:\ は、WinRE から見たシステムボリュームのドライブ文字に置き換えてください（USB や回復環境のドライブが先に割り当てられている場合は E:\ などになることもあります）。

WSUS / Intune / WUfB などで問題の更新をブロックする

再び同じ更新が配信されると元の木阿弥なので、更新の配布を抑止する設定が必須です。

• WSUS / Configuration Manager
  • 該当 KB（KB5062553, KB5064489, KB5063878 など）を「拒否（Decline）」に設定
  • 配布グループ／コレクションから対象 KB を除外
• Windows Update for Business / グループポリシー
  • 「品質更新の延期」「一時停止」を利用し、問題のないビルドに一時固定
  • めったに変えない基幹サーバー用リングは、セキュリティリスクを踏まえつつも数週間〜1か月程度遅延させる運用を検討
• WSUS など集中管理がない環境（スタンドアロン）
  • PSWindowsUpdate モジュールを用いて特定 KB を「非表示」にする暫定策もある

Install-Module PSWindowsUpdate
Hide-WindowsUpdate -KBArticleID 'KB5062553' -HideStatus:$true

ただし、非表示にしても新しいロールアップに KB5062553 の修正が取り込まれる形で再登場する可能性があるため、ビルド番号での管理（例：26100.4349 に固定する）を併用することをおすすめします。

一時的に「問題の出ていないビルド」で運用を継続する

実務的には、以下のような方針が現実的です。

• 安定報告の多い KB5060842（26100.4349） など「問題が出ていない」ことを確認済みのビルドにロールバック
• 今後の更新は、検証環境で 48〜72 時間程度の観察を行ってから段階的に本番に展開
• OOB 更新 KB5072359（26100.7178） など IRQL_NOT_LESS_OR_EQUAL 修正を含むとされるビルドも、まずは検証環境で BSOD が再発しないかを確認する

恒久対策・原因切り分けのためにやっておきたいこと

まずは「メモリダンプが確実に残る」状態を作る

IRQL_NOT_LESS_OR_EQUAL は、無効な IRQL レベルでのメモリアクセスが検出された際にカーネルが発行するバグチェックです。原因特定には クラッシュダンプ が必須ですが、多くの事例で「完全メモリダンプが出力されない」という報告もあります。

原因解析やベンダー問い合わせを見据え、次のポイントを確認しておきましょう。

• システムドライブ（通常は C:）にページファイルが存在し、サイズが「自動管理」になっているか
• ［システムの詳細設定］>［起動と回復］で、デバッグ情報の書き込みが「カーネルメモリダンプ」または「完全メモリダンプ」になっているか
• 「システムエラー」欄の「自動的に再起動する」のチェックを外し、ブルースクリーンの画面内容を確認できるようにする

設定値の確認は PowerShell でも可能です。

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl" |
  Select-Object CrashDumpEnabled, AlwaysKeepMemoryDump

ダンプが出ない場合は、ブート中にクラッシュしてページファイルがまだ利用できない、あるいは ストレージドライバーやフィルタードライバーが巻き込まれている 可能性も疑う必要があります。

Wof.sys（Windows Overlay Filter）やストレージ周辺の確認

複数の報告では、Wof.sys（Windows Overlay Filter）がスタックトレースやバグチェックメッセージに登場しており、圧縮イメージや CompactOS、WIM ベースの展開といった機構との関連が示唆されています。

次のような観点で点検しておくとよいでしょう。

• C:\Windows\System32\drivers\wof.sys のファイルバージョンと署名日時を確認し、問題のない他環境と比較する
• CompactOS や NTFS 圧縮、WIM ベースのインストールイメージなど、WOF ドライバーが積極的に利用される構成かどうかを確認する
• RAID コントローラー、NVMe ドライブ、NIC、チップセットなどのドライバーを、サーバーベンダーが推奨する 最新版かつ安定版 に統一する

特に HPE / Supermicro / GIGABYTE のサーバーでは、ストレージファームウェアやドライバーの組み合わせ次第で微妙なタイミング差が生まれ、カーネルのバグを顕在化させている可能性も考えられます。

ブートモード（Legacy BIOS / UEFI）の切り分け

一部の検証では、Legacy BIOS モード でクリーンインストールした Windows Server 2025 に 7〜8 月の CU を適用した結果、同様に IRQL_NOT_LESS_OR_EQUAL が再現したという報告があります。

ただし、実際の本番サーバーで「MBR -> GPT 変換」「Legacy -> UEFI 切り替え」を行うのはリスクが高く、ダウンタイムも大きくなります。現実的には：

• まずは検証用サーバーやラボ環境で、UEFI モード・最新ファームウェア・最新ドライバー構成における再現有無を確認
• 新規調達サーバーは、原則 UEFI + Secure Boot 有効 を標準とし、Legacy BIOS は避ける設計に移行

といった「今後の標準構成の見直し」に活かすのが無難です。

ファームウェア・マイクロコードのアップデート

Reddit などでは、BIOS/ファームウェアの更新と Secure Boot の有効化で症状が軽減したという報告も出ています。

少なくとも次のポイントは押さえておきましょう。

• HPE ProLiant であれば Service Pack for ProLiant（SPP） を用いて BIOS / iLO / ストレージ / NIC ファームウェアを一括更新
• Supermicro や GIGABYTE サーバーでも、最新の BIOS と BMC ファームウェアを適用し、リリースノートにカーネルや EPYC 対応に関する修正がないか確認
• AMD EPYC のマイクロコード更新が OS に正しく取り込まれているか（BIOS 更新で同梱されるケースが多い）
• Secure Boot／TPM をサポートしている場合、ベンダー推奨構成に合わせて有効化（ただしアプリとの互換性は要確認）

なお、今回の問題はあくまで「Windows 側の更新と特定ハードウェアの組み合わせで顕在化するバグチェック」と見られており、ファームウェア更新のみで完全に解決するとは限りません。あくまで「再現条件を絞り込み、後続の修正アップデートの成功率を上げるための前提作業」と捉えるのが良いでしょう。

Microsoft へのフィードバック・サポート依頼

同様の事象は Microsoft Q&A、Tech Community、各種ブログ・掲示板で既に共有されていますが、自社環境での再現条件とダンプを添えて公式サポートに投げることで、修正の優先度を上げやすくなります。

• Feedback Hub から「Windows Server 2025」「更新プログラム」「ブルースクリーン」カテゴリで報告
• 法人サポート契約がある場合は、SR（Service Request）を起票し、クラッシュダンプと構成情報（systeminfo, msinfo32）を添付
• 同じハードウェア系列を大量導入している場合は、ハードウェアベンダー経由で Microsoft にエスカレーションしてもらうのも有効

IRQL_NOT_LESS_OR_EQUAL の技術的な意味と今回の見立て

IRQL_NOT_LESS_OR_EQUAL とは何か

IRQL_NOT_LESS_OR_EQUAL (0x0000000A) は、Windows カーネルが「現在の割り込みレベル（IRQL）ではアクセスしてはならないメモリ領域に読み書きしようとした」と判断したときに発生するバグチェックです。

典型的な原因としては次のようなものがあります。

• バグを含むカーネルモードドライバー（ストレージ、ネットワーク、フィルター、セキュリティ製品など）
• メモリの物理的な不良（ビットエラー）
• マイクロコードやチップセットとの相性による不整合
• OS 本体（ntoskrnl.exe）のバグ

今回のケースでは、メモリテストやドライバー更新、BIOS 更新を行っても解消しないという報告が多く、品質更新（KB5062553 以降）に含まれるカーネル／ドライバーの変更と、特定ハードウェア構成の組み合わせで IRQL レベル違反が発生している可能性が高いと考えられます。

さらに一部報告では、Wof.sys（Windows Overlay Filter）と ntoskrnl.exe が同じスタックに現れることから、圧縮イメージ／ファイルシステム／ストレージ I/O の層で不整合が起きているシナリオも想定されます。ただし、現時点で Microsoft から公式に「原因は Wof.sys と特定された」というアナウンスは出ていません。

OOB 更新 KB5072359 の位置づけ

2025 年 11 月の OOB 更新 KB5072359（26100.7178） には、「Windows が停止し IRQL_NOT_LESS_OR_EQUAL エラーが発生する問題を修正する」という記述があり、少なくとも IRQL_NOT_LESS_OR_EQUAL を伴うクラッシュの一部は修正されたと見られます。

しかし、ここでいう IRQL_NOT_LESS_OR_EQUAL が、AMD EPYC + HPE/Supermicro/GIGABYTE の物理サーバーで報告されている問題と完全に一致するかどうかは明示されておらず、また「Wof.sys」「Legacy BIOS」といったキーワードも記載されていません。

そのため実務的には、次のようなスタンスが妥当です。

• KB5072359 以降のビルドでは、IRQL_NOT_LESS_OR_EQUAL に関する何らかの修正が入っているとみなしつつも、自社のハードウェア構成で再現しないことを事前検証で確認する
• 検証で問題が出なければ、「KB5062553 問題からの退避先」として KB5072359 以降へのアップデートを検討
• 検証で再現するようであれば、Microsoft サポートに「KB5072359 適用後も再現する」ことを伝え、追加の修正を待つ

運用設計の見直しポイント

検証環境での先行展開と観察期間の確保

今回のような「特定ハードウェアでのみ顕在化する OS バグ」は、ベンダー側も事前検出が難しいのが実情です。そのため、パッチ適用フローを次のように見直す価値があります。

• リング 0（検証環境）：小規模なテスト環境に最新 CU を当て、48〜72 時間 程度動作を観察
• リング 1（非基幹本番）：ファイルサーバーや開発環境など、ダウンタイム許容度が比較的高い本番機に段階展開
• リング 2（基幹サーバー）：AD DS、業務 DB、VDI ホストなどは、リング 1 の安定を確認後に展開

特に Windows Server 2025 のような新しいメジャーリリースでは、数か月間は「慎重寄り」のリング設計に振っておくのが安全です。

更新リングごとの「自動ロールバック」手順を文書化する

今回ご紹介した WinRE / DISM によるロールバック手順は、緊急時に参照できるよう 運用 Runbook として明文化しておくことをおすすめします。

• WinRE への入室方法（各ベンダーサーバーのリモートコンソールからの操作手順）
• 回復環境でのキーボード・マウス利用可否（USB か PS/2 か、UEFI のキーボードエミュレーション設定など）
• オフライン DISM でのパッケージ列挙と /remove-package 手順
• Hyper-V やその他仮想化プラットフォーム上の VM で同様操作を行う際の注意点

また、2025 年 10 月の更新では WinRE で USB キーボード／マウスが効かなくなる既知の問題も発生しており、OOB 更新で修正されています。こうした「回復環境そのものに影響する更新」もあるため、事前に WinRE の挙動確認をしておくことも重要です。

監視・ログ収集の強化

IRQL_NOT_LESS_OR_EQUAL のようなカーネルクラッシュは、イベントログ上では以下のような痕跡として現れます。

• システムログ：イベント ID 41（Kernel-Power） – 予期せぬ再起動
• システムログ：イベント ID 1001（BugCheck） – バグチェックコードとパラメーターが記録

これらを監視ツール（System Center, Zabbix, Nagios, Datadog, Azure Monitor など）に取り込み、短時間に複数台で同じバグチェックが発生したら即座にアラートを上げるようにしておくと、「ある日突然、全 DL325 が落ちていた」といった事態を避けやすくなります。

ハードウェア／ファームウェアの「基線」をそろえる

今回のような問題が起きると、つい「どのサーバーだけ問題が出ているか？」に目が向きがちですが、ファームウェアやドライバーのバージョンがばらばらな環境だと切り分けが非常に難しくなります。

• 同一モデルのサーバーは、可能な限り 同一 SPP / BIOS / ファームウェアレベル に揃える
• ファームウェア更新の履歴を CMDB や資産管理ツールでトラッキングする
• Windows Update と OEM 提供ドライバーアップデートの適用ポリシーを明確化する

こうした「標準構成」ができていれば、「このロットだけ再現する」「このロットだけ再現しない」といった比較が取りやすくなり、ベンダーとの共同調査も進めやすくなります。

よくある質問と運用上の Q&A

Q. KB5062553 をアンインストールしたままでいても大丈夫？

A. 長期放置は推奨されません。KB5062553 には多くのセキュリティ修正が含まれており、そのまま 7 月以降の更新をすべて止めてしまうと、脆弱性が未対策の状態が続きます。

• 短期的には「業務停止を防ぐ」ことを優先し、安定ビルドに戻す判断は妥当
• 中長期的には、IRQL_NOT_LESS_OR_EQUAL を修正するビルド（KB5072359 以降）や今後の CU を検証環境で確認し、早期にキャッチアップする必要があります

Q. KB5072359 を入れれば AMD EPYC 環境の BSOD は完全に直る？

A. 公式ドキュメントには IRQL_NOT_LESS_OR_EQUAL を修正するという記述がありますが、AMD EPYC + 特定プラットフォームの組み合わせに言及しているわけではありません。そのため：

• まず検証環境（同一ハードウェア構成）に KB5072359 を適用し、強めの負荷テストやバックアップジョブなどを走らせて数日間観察
• 再現しないことを確認できたら、リング 1 → リング 2 と段階展開
• 検証中に再現した場合は、Microsoft サポートに「KB5072359 適用済みでも再現」としてエスカレーション

といった慎重なステップが必要です。

Q. メモリダンプがどうしても取れないときは？

A. 以下のようなポイントも併せて確認してください。

• ストレージ暗号化（BitLocker）の有無：Pre-boot 認証タイミングによってはクラッシュ時の書き込みに影響し得る
• サードパーティ製のウイルス対策／EDR 製品が、ダンプファイルの作成や書き込みをブロックしていないか
• クラッシュが極めて早い（ブート直後）場合は、セーフモード（最小構成）の起動可否を確認し、セーフモードでだけ再現しないなら、追加ドライバーやサービスを疑う

Q. 新規導入の Windows Server 2025 では何に気を付ければいい？

A. 今回の問題を踏まえて、新規導入では次のような方針をおすすめします。

• インストール時点での ISO メディアも含め、リリースノートとリリースヘルスを必ず確認する
• 最初に適用する CU は、検証済みの安定ビルド（たとえば 26100.7178 以降など）を選択
• ブートモードは UEFI + Secure Boot 有効 を標準とし、Legacy BIOS はやむを得ない場合のみ
• 導入直後から監視とバックアップを整備し、ブルースクリーン発生時にすぐロールバックできる体制を取る

まとめ：当面の実務的な指針

本記事で整理した内容をまとめると、当面の実務的な指針は次のようになります。

• 現象が出ているサーバー
  • KB5062553 など問題の更新をアンインストールし、26100.4349（KB5060842）など安定ビルドにロールバック
  • WSUS / Intune / WUfB で KB5062553 系列の配信をブロック
  • メモリダンプ設定を見直し、次回クラッシュに備える
• まだ更新していないサーバー
  • 基幹系サーバーは更新リングを分割し、検証環境 → 一般サーバー → 基幹サーバーの順で段階展開
  • KB5072359 など IRQL_NOT_LESS_OR_EQUAL 修正を含むとされるビルドを検証環境で評価し、問題なければそこまで一気に引き上げる
• 長期的な対策
  • ファームウェア／ドライバー／ブートモードを含む 標準構成の整備
  • WinRE / DISM を用いた 自動ロールバック手順の Runbook 化
  • 監視・ログ収集の強化と、複数サーバーでの一斉障害検知体制の構築
  • Microsoft およびハードウェアベンダーへの継続的なフィードバック

Windows Server 2025 は、長期的に運用する前提の LTSC リリースです。今回のような初期不具合はある程度織り込んだうえで、「更新を怖がって止める」のではなく、「検証とロールバックの仕組みを前提にした安全な更新プロセス」を設計することが、結果としてセキュリティと可用性の両立につながります。

本記事が、同様の IRQL_NOT_LESS_OR_EQUAL 問題に悩む管理者の方々の判断材料になれば幸いです。