設定 USB KDNET EEM 內核模式偵錯 (KDNET-EEM-USB)
Windows 偵錯工具支援使用乙太網路模擬模式透過 USB 纜線進行核心偵錯。本主題說明如何使用 kdnet.exe 公用程式設定 USB EEM。
執行調試程式的計算機稱為 主計算機,而偵錯的計算機稱為 目標計算機。
內核模式 USB EEM 裝置需求
需要下列專案:
在目標計算機上,Synopsys USB 3.0 控制器連線到 USB 類型 C 埠。
在主計算機上,需要外部可存取USB 3.0埠。
Windows 10 2020 年 10 月更新版 (20H2) 或更新版本
您可以針對下列項目設定 KDNET-EEM-USB 傳輸:
- PCI 偵錯裝置。 這些偵錯裝置是使用 dbgsettings::busparams=seg.bus.dev.fun 來設定。
- ACPI-DBG2 數據表偵錯裝置。 這些偵錯裝置是使用 dbgsettings::busparams=1|2|3 來設定,其中 1|2|3 指向包含偵錯裝置組態的特定 ACPI DBG2-Table 陣組專案。
纜線需求
- 需要標準 USB 3.0 類型 C 到類型 A 纜線,才能將主機類型 A 連接到目標類型 C 連接埠。
二進位傳輸檔案
x64 的二進位檔kd_0C_8086.dll,以及ARM的kd_8003_5143.dll可用來支援 KDNET-EEM-USB 調試程式傳輸。
確認目標上提供支援的USB控制器
在目標計算機上,啟動 裝置管理員。
確認 已列出 Synopsys USB 3.0 雙重角色控制器 。
當有多個埠可用時,判斷偵錯埠
識別出支援偵錯的埠之後,下一個步驟是找出與該埠相關聯的實體USB連接器。
例如,在 Surface Pro X 上,使用兩個 USB C 埠的下半部用於 KDNET EEM 偵錯。
使用kdnet.exe確認裝置支援並檢視 busparams 值
Intel / AMD 64 裝置
BCDEDIT 偵錯選項會儲存在開機設定資料 (BCD) 存放區中。 如需詳細資訊,請參閱 BCDEdit /debug。
ARM 裝置
ARM 裝置會使用 ACPI DBG2 資料表來設定調試程式,其中 busparams 指向 DBG2 資料表專案。 若要指定將使用的偵錯埠,則會使用busparm。 通常只會使用第一個busparam,視裝置而定,它是0或1。 一般而言,裝置不會使用busparams=0,因為0 DBG2資料表專案通常會保留給序列裝置 COM。 如需 ACPI DBG2 資料表的詳細資訊,請參閱 Microsoft偵錯埠資料表 2 (DBG2) 。
使用kdnet.exe設定 KDNET EEM USB
使用 kdnet.exe 公用程式來顯示支援 KDNET-EEM-USB 傳輸偵錯之控制器的參數資訊。
確認 Windows 偵錯工具已安裝在主機和目標系統上。 如需下載及安裝調試程式工具的資訊,請參閱 Windows 的偵錯工具。
找出kdnet.exe公用程式。 根據預設,檔案位於這裡。
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
在目標電腦上,以系統管理員身分開啟命令提示字元視窗。 輸入此命令以確認目標計算機具有支援的網路適配器,並檢視busparams值。
C:\KDNET>kdnet.exe Network debugging is not supported on any of the NICs in this machine. KDNET supports NICs from Intel, Broadcom, Realtek, Atheros, Emulex, Mellanox and Cisco. Network debugging is supported on the following USB controllers: busparams=1, Device-mode USB controller with Vendor ID: 5143 (Default) busparams=2, Device-mode USB controller with Vendor ID: 5143 busparams=3, Device-mode USB controller with Vendor ID: 5143 busparams=4, Device-mode USB controller with Vendor ID: 5143 This Microsoft hypervisor supports using KDNET in guest VMs.
當來自 kdnet.exe 的輸出指出支援的 USB 控制器具有總線參數值為 1 的可用時,我們可以繼續。
設定目標電腦
依照下列步驟,使用 kdnet.exe 公用程式在目標計算機上設定調試程序設定。
重要
使用 bcdedit 變更開機資訊之前,您可能需要暫時暫停測試計算機上的 Windows 安全性功能,例如 BitLocker 和安全開機。 使用 BCDEdit 更新開機資訊後,您可以重新啟用 BitLock 和安全開機。 適當地管理測試計算機,當安全性功能停用時。
使用如下所示的命令來設定、busparams 值、主機系統的IP位址和埠,併產生唯一的連線密鑰。 所有 USB EMM 連線都會使用 169.254.255.255 IP 位址。
針對您使用的每個目標/主機組,在建議的 50000-50039 範圍內,挑選唯一的埠位址。 範例中會顯示 50005。
C:\>kdnet.exe 169.254.255.255 50005
Enabling network debugging on Intel(R) 82577LM Gigabit Network Connection.
Key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p
將傳回的金鑰複製到記事本.txt檔案。 在顯示的範例中,產生的索引鍵值為:
2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p
使用 BCDEdit 命令來檢查參數是否如預期般。 如需詳細資訊,請參閱 BCDEdit /dbgsettings
C:\>bcdedit /dbgsettings
busparams 1
key 2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p
debugtype NET
hostip 169.254.255.255
port 50005
dhcp No
The operation completed successfully.
停用主機上的防火牆
在主機上,停用調試程式的防火牆。
將 WinDbg 連線到目標以進行核心偵錯
在主計算機上,開啟 WinDbg。 在 [檔案] 功能表上,選擇 [核心偵錯]。 在 [核心偵錯] 對話框中,開啟 [ Net ] 索引卷標。貼上您稍早在記事本.txt檔案中儲存的埠號碼和密鑰。 選取 [確定]。
您也可以開啟 [命令提示字元] 視窗並輸入下列命令來啟動 WinDbg 工作階段,其中 是您上面選取的埠,而 是上述kdnet.exe傳回的索引鍵。 貼上您稍早在記事本中儲存至的密鑰,.txt檔案。
windbg -k -d net:port=<YourDebugPort>,key=<YourKey>
重新啟動目標計算機
調試程式連線之後,請重新啟動目標計算機。 重新啟動計算機的方法之一,是從系統管理員的命令提示字元使用 shutdown -r -t 0
命令。
目標電腦重新啟動之後,調試程式應該會自動連線。
疑難排解
疑難解答目標
確認 Windows KDNET-USB-EMM 網路適配器出現在 Windows 裝置管理員 中的網路適配器底下。
裝置屬性會顯示控制器保留供 Windows 核心調試程式使用時。
針對主機進行疑難解答
確認 Windows KDNET-USB-EMM 網路適配器出現在 Windows 裝置管理員 中的網路適配器底下。
在主機上會顯示使用USB類型 A 埠的 KDNET-EEM 連線。
Intel PCI - 在調試程式控制台視窗上重試訊息,且無法闖入目標 - SkipPciProbeDebugDevice
如果您在 KDNET 調試程式控制台中遇到下列訊息,則無法起始目標中的中斷,或遇到特定命令的問題(例如 kdfiles),這可能是因為 KDNET 收到序列外 Ping 封包。
... Retry sending the same data packet for 128 times.
The transport connection between host kernel debugger and target Windows seems lost.
please try resync with target, recycle the host debugger, or reboot the target Windows.
此問題可能會發生,因為pci.sys驅動程式無法正確探查偵錯裝置。 若要消除錯誤,請在系統管理員命令提示字元的 TARGET 裝置上建立下列登錄專案。
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\SERVICES\kdnet /v SkipPciProbeDebugDevice /t REG_DWORD /d 1 /f
然後重新啟動目標計算機。
shutdown /r /t 0
裝置重新啟動之後,錯誤應該會消失,而且命令應該如預期般運作。