Windows Server 2022/2025 を VMware ESXi 7 上で運用していると、2025 年 7 月の Windows Update 適用後から「アイドル時にだけ固まる」「ホスト側では CPU 使用率が 20% 前後で張り付く」といった不可解なフリーズに悩まされるケースがあります。本記事では、実際の事例をもとに、原因となった VC++ 再頒布可能パッケージと VMware Tools の不整合、その恒久対処方法までを詳しく解説します。
障害が発生した環境と前提条件
まず、今回フリーズが発生した具体的な環境と前提条件を整理します。自分の環境とどこが近いか、比較しながら読んでください。
仮想基盤・ハードウェア構成
| 項目 | 内容 |
|---|---|
| ハイパーバイザー | VMware ESXi 7.0 U3 系 |
| 物理サーバー | Dell PowerEdge R540 |
| ゲスト OS | Windows Server（表記は 2025、実ビルドは 20348.3932 / 21H2 系） |
| 仮想 NIC | VMXNET3 |
| VMware Tools | バージョン 11.1.0 |
| vCPU | 24 vCPU |
| メモリ | 64 GB |
| その他 | WSL（Windows Subsystem for Linux）を利用 |
ここで重要なのは、タイトルやコンソール上の表示が「Windows Server 2025」であっても、20348.3932 というビルド番号は Windows Server 2022（21H2）系に属するという点です。情報を調べるときは製品名ではなく、必ずビルド番号と OS バージョンを確認しましょう。
問題が発生したタイミング
トラブルは、2025 年 7 月 10 日前後に配信された Windows 更新プログラムを適用した直後から発生しました。
- 2025 年 7 月 10 日前後の更新（例：KB5062553、KB5056579）
- 2025 年 7 月 11 日の更新（例：KB5054979）
これらの更新を適用する前は、同じ ESXi 7 上で問題なく稼働していた Windows Server 2022/2025 VM が、アップデートと再起動後、しばらく運用しているうちに突如フリーズするようになりました。
実際に発生していた症状
フリーズと言っても「ブルースクリーン」ではなく、あくまで OS が固まるだけ、という厄介なタイプの障害です。具体的には以下のような症状が出ました。
- ユーザー操作がないアイドル状態で、突然 VM が固まる
- RDP も vSphere コンソールも無反応になり、Ctrl+Alt+Del も効かない
- ESXi 側のモニタリングでは、該当 VM の CPU 使用率が約 21% 付近で張り付き、ほとんど上下しない
- VM の「リセット」や「サスペンド → レジューム」で一時的に復帰するが、しばらくすると再び固まる
- レジューム後に、ゲスト OS 内で VMXNET3 の NIC を無効化すると操作可能になることが多い
| 観測ポイント | 状態 | 補足コメント |
|---|---|---|
| ゲスト OS 画面 | 完全フリーズ（マウス・キーボード無反応） | RDP / コンソールどちらからも操作できない |
| ESXi ホストの CPU グラフ | 該当 VM の CPU が約 21% で固定 | 高負荷というより「一定値で固まっている」印象 |
| 電源操作 | リセット / サスペンド → レジュームで復帰 | 一時的に直るが、時間が経つと再発 |
| 仮想 NIC | NIC 無効化で操作できるようになるケースあり | ネットワーク周りの問題を疑いたくなる状況 |
このように外観だけを見ると、「VMXNET3 ドライバーのバグ」「2025 年 7 月の Windows Update の不具合」と考えたくなりますが、最終的な原因は別のところにありました。
結論：VC++ 再頒布可能パッケージの不整合が VMware Tools を壊していた
詳細な調査の結果、根本原因は次のように整理できました。
- Windows Update 適用の前後で、Node.js v22 などのソフトウェアが追加インストールされていた
- Node.js v22 のインストーラーは、Microsoft Visual C++ 2015–2022 再頒布可能パッケージ（VC++ Redist）を同梱している
- これが既存の VC++ と競合し、一部の VC++ ランタイムモジュールが「壊れた」または「不整合なバージョン」になった
- VC++ ランタイムに依存している VMware Tools が正常に動作できなくなり、VMXNET3 を含む仮想デバイス制御が中途半端な状態に陥った
- 結果として、アイドル時にのみフリーズしたり、ESXi 側から見ると CPU 使用率が 21% 付近で張り付き続けるという現象が発生した
つまり、問題の主因はWindows Update そのものではなく、更新やアプリ追加の過程で破損・競合した VC++ 再頒布可能パッケージが VMware Tools を不全化させていたことだったわけです。
なぜ「アイドル状態」で固まりやすかったのか
今回の障害では、「負荷をかけている最中」ではなく「アイドル状態」に入ったタイミングでフリーズすることが多く見られました。その背景には、次のような要因が考えられます。
- アイドル時に走るバックグラウンド処理（自動更新、インデックス、WSL 関連タスクなど）が、壊れた VMware Tools と食い違ったタイミングで実行される
- 省電力機能（CPU C-State、CPU パーキング、NIC の省電力）が、異常なドライバー状態と組み合わさってハングを引き起こす
- 負荷がかかっている間は常に動作し続けるため問題が表面化しにくく、アイドルへの遷移時にだけ「おかしな状態遷移」が起こる
VC++ ランタイムが壊れたことで VMware Tools のプロセスが正しく振る舞えず、そこに各種バックグラウンド処理や省電力制御が重なった結果、アイドル状態でだけフリーズするというやっかいな症状として現れた、という構図です。
恒久対策の全体像
実際に効果があった恒久対策は、次の 2 点です。
- Microsoft Visual C++ 再頒布可能パッケージ（VC++ Redist）の整合性を回復する
- VMware Tools を Repair（必要に応じて再インストール）する
単に Windows Update をロールバックしたり、NIC を差し替えるだけでは根本解決になりません。VC++ と VMware Tools をセットで「きれいな状態」に戻すことが重要です。
作業前にやっておきたいこと
- 対象 VM のスナップショット取得
- 可能であれば OS バックアップも取得
- 再起動を含む作業になるため、メンテナンス時間帯を確保
手順 1：VC++ 再頒布可能パッケージの確認と整理
まずは、VC++ 再頒布可能パッケージの状態を確認し、競合していそうなものを整理します。
インストール済み VC++ の確認
- [設定] → [アプリ] → [インストールされているアプリ]（または [アプリと機能]）を開く
- 検索ボックスに
Visual C++と入力し、「Microsoft Visual C++ 2015–2022 再頒布可能パッケージ」を絞り込む
| 種類 | 表示名の例 | 備考 |
|---|---|---|
| x64 版 | Microsoft Visual C++ 2015–2022 Redistributable (x64) | 64bit アプリやシステムコンポーネントが利用 |
| x86 版 | Microsoft Visual C++ 2015–2022 Redistributable (x86) | 32bit アプリケーションで利用 |
| アプリ同梱版 | インストーラー経由で追加された VC++ | Node.js や各種ミドルウェアが同梱していることが多い |
Node.js v22 などのインストーラーは、VC++ 再頒布可能パッケージを同梱していることがあり、既存の VC++ とバージョンがぶつかると、ランタイムの DLL 群が中途半端な状態になってしまいます。その結果、VMware Tools のような VC++ 依存コンポーネントが不安定になります。
競合していそうな VC++ の整理方針
- 明らかに古いバージョン、特定のアプリにしか使っていないと分かる VC++ はアンインストールを検討する
- アンインストールするたびに「何を消したか」をメモし、万一の復旧に備える
- 最終的には Microsoft 公式配布の最新版 VC++ で上書き・修復する
公式配布の VC++ 再頒布可能パッケージは、コマンドラインから Repair を実行することも可能です。たとえば x64 版であれば次のように実行します。
vc_redist.x64.exe /repair /quiet /norestart
32bit アプリを多用している環境では、x86 版（vc_redist.x86.exe）も同様に Repair すると安心です。
手順 2：VMware Tools の Repair / 再インストール
VC++ の整合性を整えたら、次は VMware Tools 本体を Repair して、VMXNET3 などのドライバーを入れ直します。
基本的な Repair の流れ
- vSphere Client で対象 VM を右クリックし、[ゲスト OS] → [VMware Tools のインストール/アップグレード] を選択
- ゲスト OS 側でインストーラーが起動したら、「Repair」を選択して進める
- インストール完了後、OS を再起動する
Repair で改善しない場合は、次のようにクリーンインストールを検討します。
- 一度 VMware Tools をアンインストールする
- ESXi 7.0 U3 でサポートされる最新安定版の VMware Tools をインストールする
- 再起動後、デバイスマネージャーで VMXNET3 や SCSI コントローラーに「！」マークがないことを確認する
作業後の確認ポイント
- VM をアイドル状態のまま数時間放置し、フリーズが再現しないか
- ESXi 側で該当 VM の CPU 使用率を監視し、0～数 % 程度で揺らいでいるか（21% 固定になっていないか）
- イベントビューアーの Application / System ログに VMware Tools や vmxnet3 のエラーが出ていないか
- WSL や常駐アプリの起動・終了時に不自然な引っかかりがないか
すぐには直せない場合の一時回避策・切り分け
本番サーバーでいきなりアンインストールや大規模修復ができない場合、以下のような一時回避・切り分けも有効です。
VMXNET3 のオフロード機能を一時的に無効化
VMXNET3 の高度なオフロード機能と、不安定なドライバー状態が組み合わさると、フリーズや異常なパフォーマンスにつながることがあります。切り分けとして、以下の機能を一時的に無効化してみましょう。
| 機能名 | 概要 | トラブルシュート時の推奨設定 |
|---|---|---|
| Large Send Offload (LSO) | 大きなパケットを NIC 側で分割して送信する機能 | 「無効」に設定し、様子を見る |
| Receive Side Coalescing (RSC) | 受信パケットをまとめて処理する機能 | 一時的に「無効」にして再現性を確認 |
| Receive Side Scaling (RSS) | 複数 CPU コアに受信処理を分散する機能 | 問題発生時に無効化し、変化があるかチェック |
また、仮想 NIC を複数枚アタッチしている環境では、一度 1 枚だけのシンプルな構成にしてみるのも有効です。「NIC を無効化すると復帰する」という挙動があるなら、ネットワーク周りの問題に絞り込めるため、構成を簡素化してから一つずつ機能を戻していくのが効果的です。
CPU スケジューリングと vCPU 数の見直し
今回のケースでは VC++ と VMware Tools が主犯でしたが、ESXi 環境では vCPU 数の過剰割り当てが別のトラブルを誘発することもよくあります。合わせて次の点もチェックしておきましょう。
esxtopで RDY（CPU Ready）や CSTP（Co-Stop）を確認し、CPU スケジューリング遅延が大きくなっていないか- 24 vCPU が本当に必要か、実際の負荷を見ながら 8～16 vCPU 程度に削減してもよいサーバーではないか検討する
- 他の重い VM とリソースを奪い合っていないか、予約・シェア設定を確認する
電源プランと WSL / バックグラウンド処理の影響確認
Windows Server 側の電源プランが省電力寄りだと、CPU クロックやデバイスの省電力制御が活発になり、不安定なドライバーと組み合わさってハングを誘発する場合があります。
- 電源プランを一時的に [高パフォーマンス] に変更して挙動を確認する
- WSL やログ収集エージェント、監視ツールなどのバックグラウンド処理を一時停止し、再現性に変化がないかを見る
再発防止のために見直すべきポイント
同様の「Windows Server 2022/2025 が ESXi 7 上でフリーズする」トラブルを繰り返さないために、次のような運用・設計面の見直しもおすすめです。
VMware Tools と仮想ハードウェア互換性の管理
- ESXi 7 がサポートする範囲で、VMware Tools は常に最新の安定版を利用する
- 仮想ハードウェアの互換性レベルも、ホストに合ったバージョンにそろえる
- 本番適用前にテスト用 VM を用意し、Tools のアップデートやハードウェアバージョンの更新を検証する
BIOS / iDRAC / ESXi ホストのパッチ適用
古い BIOS やマイクロコード、ESXi の未適用パッチが、デバイスドライバーと悪い組み合わせを起こすこともあります。
- Dell PowerEdge R540 の場合は、Dell のサポートサイトで最新の BIOS / iDRAC / ファームウェアバンドルを確認
- ESXi 7.0 U3 自体も、最新のパッチレベルまで引き上げることを検討
- 更新後は、ハードウェア互換性ガイド（HCL）に問題がないか必ず確認する
Windows Update の段階適用と問題 KB の一時除外
Windows Update が「直接の犯人」でない場合でも、更新をきっかけに latent な問題が顕在化することはよくあります。リスクを抑えるために、次のような運用が有効です。
- 検証用の Windows Server VM を用意し、まずそこに最新の累積更新を適用して数日間様子を見る
- 問題がなければ、本番環境へ段階的に適用する
- 特定の KB 適用後にだけフリーズが再現するなら、その KB は一時的に除外し、修正版や情報公開を待つ
ミドルウェア導入時の VC++ 依存関係に注意
Node.js、アプリケーションサーバー、監視エージェントなど、多くのソフトウェアが「VC++ 再頒布可能パッケージ」に依存しています。導入時には次の点を意識すると安全です。
- インストーラーが VC++ を同梱していないかセットアップ画面を確認する
- 既存の VC++ を上書きしたり、古いバージョンを追加しないか事前に把握する
- サーバー標準イメージに、公式配布の VC++ 最新版をあらかじめ組み込んでおき、個別アプリ任せにしない
「Windows Server 2025」と「2022」のビルド番号の落とし穴
今回のケースのように、タイトルやメニュー上では「Windows Server 2025」と表示されていても、ビルド番号が 20348.xxx であれば実態は Windows Server 2022 系です。この認識違いは、情報検索やトラブルシューティングで混乱を招きます。
| ビルド番号の例 | 系統 | 備考 |
|---|---|---|
| 20348.xxx | Windows Server 2022（21H2） | 今回の事例は 20348.3932 |
| 19xxx.xxx | Windows Server 2019 系 | Windows 10 1809 ベース |
ビルド番号は以下のような方法で確認できます。
- Win+R →
winver実行 - コマンドプロンプトや PowerShell で
systeminfoを実行
「Windows Server 2025 フリーズ」「ESXi 7 フリーズ」といったキーワードで検索しても、実際に参考にすべき情報は「Windows Server 2022 + ESXi 7 + VMware Tools + VC++ 再頒布可能パッケージ」に関する記事であることが多いため、ビルド番号から系統を判断するクセを付けておくと効率的です。
監視と自動チェックで早期検知する
この手のトラブルは、「なんとなく重い」「たまに固まる」といった曖昧な症状のまま放置されがちです。監視や自動チェックを仕込んでおくことで、早めに異常を検知しやすくなります。
VMware Tools サービス状態の監視
Windows 側では、VMware Tools サービス（通常は VMTools）が停止していないかを定期的にチェックするだけでも効果があります。たとえば次のような PowerShell コマンドで状態を確認できます。
Get-Service -Name VMTools | Select-Object Status, Name
監視ツールからこのコマンドを一定間隔で実行し、「停止」や「一時停止」状態を検知したらアラートを飛ばすようにしておけば、Tools の異常を早期に把握できます。
イベントログとホスト側メトリクスを組み合わせる
- ゲスト OS 側：イベントビューアーの Application/System ログで VMware 関連のエラー・警告を確認する
- ESXi ホスト側：特定 VM の CPU 使用率が長時間同じ値（例：21% 前後）で張り付いていないか監視する
- 「ログ上は静かだが、ホスト側 CPU が不自然に固定されている」という状況は、今回のような Tools / ドライバー系トラブルの典型パターン
まとめ
ESXi 7 上の Windows Server 2022/2025 VM が、2025 年 7 月の Windows Update 適用後からアイドル時にのみフリーズし、ホスト側 CPU が約 21% で張り付く――という一見不可解な現象の裏には、VC++ 再頒布可能パッケージの破損・競合によって VMware Tools が不全化したというシンプルな原因が隠れていました。
Node.js v22 などが同梱する VC++ が既存のランタイムと競合し、VMware Tools が必要とするコンポーネントが壊れたことで、VMXNET3 をはじめとした仮想デバイス制御が中途半端な状態になり、その結果として「アイドル時フリーズ」「CPU 使用率 21% 固定」といった症状が現れた、と整理できます。
根本的な対処としては、
- Microsoft Visual C++ 再頒布可能パッケージの整合性を回復する
- VMware Tools を Repair または再インストールする
- ネットワークオフロード機能の無効化や NIC 構成の簡素化で切り分ける
- BIOS / iDRAC / ESXi / Windows Update / ミドルウェアを計画的に更新し、必ず検証環境を経由させる
といった手順を踏むことで、恒久的な解消が期待できます。
同じように「Windows Server 2022/2025 が ESXi 7 上でフリーズする」「VMware Tools を入れ直しても直らない」といった悩みを抱えている場合は、単に Windows Update を疑うだけでなく、VC++ 再頒布可能パッケージと VMware Tools の状態を必ずチェックしてみてください。意外なところに真犯人が潜んでいるかもしれません。
コメント