{"componentChunkName":"component---src-templates-post-template-js","path":"/windows-windbg-proxmox-remotekd","result":{"data":{"markdownRemark":{"id":"9b29af17-debe-5f12-8c3e-275c818113a2","html":"

今回は、Proxmox 上の Windows 11 VM 間で WinDbg を使ったリモートカーネルデバッグが動作しなかった問題の解消方法をまとめます。

\n

最終的に、今回は以下の設定を行うことで Proxmox 上の仮想マシン間でリモートカーネルデバッグが成功するようになりました。

\n
    \n
  1. KDNET が本来使うべき NIC の busparams=b.d.f を、kdnet.exe を使用せずに bcdedit で明示的に指定する
    2. \n
\n
bcdedit /debug on\nbcdedit /dbgsettings net hostip:192.168.10.20 port:50000 key:<Key> nodhcp\nbcdedit /set \"{dbgsettings}\" busparams <確認した busparams>\n\n# 設定の確認\nbcdedit /dbgsettings
\n
    \n
  1. ターゲットマシンの起動に qm start <VMID> --force-cpu host コマンドを使用することで、デフォルトで構成されている Hyper-V Enlightenments の設定を使用せずにマシンを起動する
    2. \n
\n\n

もくじ

\n\n

環境

\n

今回の環境は以下の通りです。

\n\n

\n \n \n \n \n \n \n \n \n

\n

発生した問題と原因っぽい点

\n

ネットワーク経由でカーネルデバッグを行う と同じ手順で kdnet.exe でネットワークデバッグを構成した後にホスト側で WinDbg を待ち受けにしても、ターゲット再起動後に接続しない状態でした。

\n
windbg.exe -k net:port=50000,key=<Key>
\n

ターゲット側では kdnet.exe を実行した際に Network debugging is supported とは表示されていたものの、以下のようなエラーコード 0xC0000182 を伴うエラーも表示されました。

\n
KDNET transport initialization failed during a previous boot. Status = 0xC0000182.\nNIC hardware initialization failed.\nKDNET did not successfully receive any packets during init.\nKDNET did not successfully send any packets during init.
\n

これはどうもターゲットからのデバッグ用の通信自体が発生していないのが原因のようで、諸々調べていったところ以下の記事を見つけました。

\n

参考：libvirt的Hyper-V虚拟化或导致Windows KDNET初始化失败 - Silver

\n

この記事によると、Proxmox が使用している qemu では Windows のゲスト用に Hyper-V Enlightenments というマシンに Hyper-V 上で稼働するマシンであると認識させる機能があり、これにより実際には Hyper-V を使用していない仮想マシンでは KDNET の動作に影響がでるらしいとのことです。

\n

参考：Hyper-V Enlightenments — QEMU documentation

\n

(詳しく調べられていないのですが、どうも Hyper-V 上のマシンでは KDNET の動きが変わるらしく、実際には Hyper-V を使用していない仮想マシンでこのような動作になるとネットワークデバッグが上手く動かなくなる場合があるようです。)

\n

メモ：Proxmox で確認したこと

\n

まず以下のコマンドで、Proxmox で VM を起動する際のオプションを確認しました。

\n
qm showcmd <VMID> --pretty
\n

その結果、以下のようにいくつかの hv_ から始まるオプションが CPU フラグに含まれていることがわかりました。

\n

\n \n