Windows 11 24H2 の Hyper-V で、Windows XP の ネットワークアダプタがうまく動かなくなった件
みなさん、こんｘｘは。
いつも本ブログをご覧いただき、ありがとうございます。
今回のテーマは、タイトルの通りです（笑）
なんか、Windows 11 を、24H2 にしたところ、Hyper-V にインストールした、Windows XP の
・ネットワークアダプタが、不調になった
と言う話です。具体的には、
・Windows XP への「リモートデスクトップ」が出来なくなった
と言う現象が起きました。
この対応策は、幾らググっても出て来なかったのですが、とある方法で解決したので、記録に残しておきます。
-----
私は、必要があって Windows 11 上の Hyper-V に、
・ゲストOS に、Windows XP をインストールして
使っております。
主な使用目的は、開発環境の維持です。
で、つい先日、ホストＯＳである Windows 11 を、
・23H2 から 24H2 に、アップグレード
したのですが、どうもその後から、急に、
・Windows XP への、「リモートデスクトップ」が出来なく
なってしまいました。
※具体的には、このエラーが出る
この、
「エラーコード：0x904、拡張エラーコード：0x7」
というのは、ネットワーク系でよく出るエラーらしい。
が、コレで検索しても「有効な対処法」は、見つからなかった。
※真っ先に「ファイヤーウォールの設定を見直せ」と出るが、そもそも、
・こないだまで、ふつーに繋がってたので、そう言う問題では無い（笑）
（但し、環境によっては「Windows Update」が、ファイヤーウォールの設定を
・勝手に変えること
は、良くあることなので、一応、確認はしておいたほうが良いです。）
※余談ですが、「24H2」は、特に
・リモートデスクトップ周り
の不具合が多い気がします。これ以外にも、「描画の問題」
（リモートデスクトップで接続すると「画面描画」がオカシクなって、
「画面がゴミだらけ」になって、使えたもんじゃない。
この対策としては「FreeRDP」を使え、とか出て来るが「別の問題」もたくさんあるので、
あまりお勧めでは無いです。あと、今回の問題は「FreeRDP」使っても治りません。）
等がある。ちなみに「画面描画の問題」は、
・更新プログラム KB5052093
で、治りました（笑）
※これ治すために、色んなソフト（「FreeRDP」とか・・・）試した時間返せ > Microsoft
Hyper-V 上のOSは、Hyper-V マネージャーから、「接続」メニューで使うことも出来ますが、これだと、
・最大解像度が、1600x1200
に、制限されてしまいます。（VMWare とかだと、こういう制限が無い・・・）
なので、最近の「高解像度モニタ」では、使いにくいです。（FHDすら対応して無いのは、非常に不便）
※Windows 8 以後だと「拡張セッション」が使える（内部的には「リモートデスクトップ」らしい）のですが、
Windows XP は、「第1世代」の仮想マシンでしか使えないので、コレが出来ない。
そこで、外部から「リモートデスクトップ」で接続すると「任意の解像度」で、セッションを開くことが出来ます。
「Windows XP で４Kモニタ」とか、出来ちゃいます（笑）なんかスゴイ
-----
その前に「前提条件」を書くと、
・Windows 11 (24H2) 上の Hyper-V に、Windows XP をインストールしている
・Windows XP には、「Hyper-V統合サービス」を、導入してある
（これで、「Microsoft Hyper-V Network Adapter」が、使えるようになる。）
・Windows XP は、「Microsoft Hyper-V Network Adapter」を、使っている
（ちなみに、今回の問題は「レガシ ネットワーク アダプター 」では、起きない模様）
・Windows 11 には、更新プログラム KB5052093 を当ててある（コレが必須かどうかは不明です。）
という、かなり「ニッチな環境」かも知れません（笑）
具体的な内容です。
Windows XP ゲストのデバイスマネージャ上で、
「Microsoft Hyper-V Network Adapter」のプロパティ
を開きます。
「詳細設定」タブを開いて、「TCP Checksum Offload (IPv4)」を選択
値を、「Rx & Tx Enabled」から、
「Rx Enabled」に、変更して、ＯＫで閉じます。
※変更して閉じた時に、ネットワークが切り替わります。
ネットワーク系のアプリは、再接続（再起動）が必要かと思います。
※IPv6 を使ってる人は、「TCP Checksum Offload (IPv6)」のほうも、
同様の操作をしたほうが良いかも知れません。（私は、IPv6使ってないので未確認）
念の為、ゲストOS自体を再起動したほうが良いカモです。
-----
以上です。
これで、めでたく「リモートデスクトップが機能」するようになったと思います。
※これ見つけるまでに掛かった３日間返せ > Microsoft
※以下、戯言です。早く終わりたい人は、特に見る必要はありません。
-----
この方法を見つけたのは、
・全くの偶然
なんですが、一応、動きを見てると、
・今までは、ふつーに動いていた（24H2 にしたことしか考えられない）
・動きを見てると、「接続しようとして、『最後』で、コケてる」
・「レガシ ネットワーク アダプター 」では、起きない
（ふつーは「こっち」使うので、ググっても出て来ない（笑）だが、速度が１０倍以上は違います。
体感でわかる位。なので、諦めきれなかった（笑）
だったので、「イロイロと設定を」弄ってるうちに、偶然見つけました（笑）
技術的には、「TCP Checksum Offload」というのは、要するに、
・TCP の「チェックサムの計算」を、ＣＰＵじゃなくて「ネットワークカード」に任せる
ということなので、「物理ＮＩＣ」でないと意味無いんですが（笑）
（「仮想マシン」なので、結局み～んな「ＣＰＵ」が計算してるので）
まぁ、要は「バグ」でしょう。そのうち勝手に治ってるカモです（笑）
※運の悪いことに、この現象は、ゲストＯＳが「Windows 7」とかだと起きない（笑）なんだかなー。
まぁそもそも、「Windows XP」なんて、「とっくの昔に Obsolete」なので、まぁ、もうどうでもいいんでしょうな。
こっちは、まだ「サポート」の為に使ってますが（笑）
-----
本日は、以上です。
コメント
コメントを投稿