WinDbg 失去网络连接调试，目标机器死机
WinDbg loses connection debugging over network, and target machine freeze
我试图让 WinDbg 通过网络调试工作，但在我闯入调试器（调试->中断）后它总是失去连接，然后尝试再次启动它（调试->运行） .但是，如果我从未闯入调试器，看起来连接在 'N' 一段时间内是稳定的。在此宽限期内，当我使用目标系统时，我什至可以在 WinDbg 中看到调试打印语句。此外，在调试中断时连接似乎很好，因为我可以从目标系统收集信息。我使用“!ustr srv!SrvComputerName”来获取目标计算机名称，它 returns 是正确的名称。任何帮助将不胜感激。
设置系统： 我按照 MSDN website 的说明设置我的目标和主机系统。
调试：以下是我尝试解决此问题的方法。
- 在网络适配器上禁用流量控制并使用半双工模式。我在读完这个 post 后尝试了这个：WinDbg, host machine lose network if test machine is on the same switch
- 购买新的网络适配器。根据this webpage，我的网络适配器应该支持网络内核调试。但是，进一步调查显示供应商有不更新设备 ID 的坏习惯，因此我决定通过从不同供应商购买新适配器来排除这种可能性。
- 正在更改网络端口。我尝试了一大堆不同的网络端口 (49152-65535)，以防其中一个被用于不同的目的。
- 拔下以太网电缆，然后重新插入。连接断开后，我尝试了此操作，希望它能重新建立连接。
- 正在重新启动目标系统。与#4 相同的原因。
- 更改 PCIe 端口。我 运行 没有选择。
- 将主机系统移动到不同的网络交换机。没有变化。
观察：
- Wireshark 显示目标系统在系统启动后立即向主机系统发送 UPD 包，但主机系统直到 WinDbg 启动后才响应。更有趣的是，即使在目标系统变得无响应后，目标系统仍会继续向主机发送 UPD 包。不幸的是，我不了解 UPD 包数据。
- 如果重新启动，WinDbg 可以始终如一地重新建立与目标系统的连接。目标系统似乎卡在调试中断中。
系统信息： 主机系统是 运行 Windows 8.1 Pro。目标系统是 运行 a Windows 8.1 Enterprise Evaluation（8GB RAM）。
WinDbg 打印出来：
Microsoft (R) Windows Debugger Version 6.3.9600.17237 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Using NET for debugging
Opened WinSock 2.0
Waiting to reconnect...
Connected to target **.**.*.*** on port ***** on local IP **.**.*.***
Connected to Windows 8 9600 x64 target at (Fri Mar 27 18:58:06.217 2015 (UTC - 7:00)), ptr64 TRUE
Kernel Debugger connection established.
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.17031.amd64fre.winblue_gdr.140221-1952
Machine Name:
Kernel base = 0xfffff801`00e70000 PsLoadedModuleList = 0xfffff801`0113a2d0
Debug session time: Fri Mar 27 18:58:06.918 2015 (UTC - 7:00)
System Uptime: 0 days 0:47:15.869
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
* *
* You are seeing this message because you pressed either *
* CTRL+C (if you run console kernel debugger) or, *
* CTRL+BREAK (if you run GUI kernel debugger), *
* on your debugger machine's keyboard. *
* *
* THIS IS NOT A BUG OR A SYSTEM CRASH *
* *
* If you did not intend to break into the debugger, press the "g" key, then *
* press the "Enter" key now. This message might immediately reappear. If it *
* does, press "g" and "Enter" again. *
* *
*******************************************************************************
nt!DbgBreakPointWithStatus:
fffff801`00fcab90 cc int 3
0: kd> g
... Retry sending the same data packet for 64 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.
... Retry sending the same data packet for 128 times.
... Retry sending the same data packet for 192 times.
此时WinDbg不再有响应，继续发送数据包。目标系统也无响应。
我终于通过切换主机系统解决了这个问题。一开始我以为是目标系统的问题，因为MSDN只是把网卡调试要求放在了目标系统上。似乎对主机系统也有要求。
新主机系统：桌面（与目标系统相同）
- OS: Windows 8.1 企业评估 x64
- 网卡：VEN_10EC&DEV_8168
以前的主机系统：笔记本电脑
- OS: Windows 8.1 Pro x64
- 网卡：VEN_8086&DEV_1502
注意：我真的不知道根本原因。两个 NIC 都在 Supported Ethernet NICs 列表中，我使用了 WDK 附带的相同 WinDbg 版本，并且所有系统都在同一个交换机上。
我遇到了类似的问题，并通过在主机上使用 USB 转以太网适配器而不是内置 NIC 卡解决了这个问题。
我也遇到了这个问题，发现当我尝试强制关闭 VMWare OS 时，windbg 连接似乎在 VMWare OS 实际关闭之前恢复。经过几次尝试，我发现了一个奇怪的解决方案：
当主机和VMWare 客户机之间的windbg 连接丢失时，尝试单击"shutdown VMWare Guest"，但不要真正确认。你可能会发现 windbg 连接恢复了！然后，取消关机。
很奇怪，好像是VMWare自己屏蔽了网络调试连接丢失。但至少这是一个值得尝试的解决方法。
我尝试过的另一种有时可行的解决方法是在任务管理器中终止 windbg，然后重新 运行 windbg 并重新连接到 VMWare 客户机。并且可能需要等待几秒到几分钟才能重新连接。
顺便说一句，我的以太网卡是 Intel Ethernet Connection I218-V。
我在 VMware 中找到了适合我的更简单的解决方案，
问题出在 vmware - NAT 连接超时 30 秒。
该值是可配置的。
去编辑 -> 虚拟网络编辑器 -> 更改设置（uac 提示） -> select 列表中的 NAT -> NAT 设置 -> UDP 超时。
最大值是 32767，默认值（对我来说）是 30 秒。
彻底解决了我的问题。
主机有问题。如果您不想更改主机并继续在其上进行调试，您可能想尝试使用串行端口。它提供了更好的性能。查看以下 link 以设置通过 com 端口调试虚拟机：
我试图让 WinDbg 通过网络调试工作，但在我闯入调试器（调试->中断）后它总是失去连接，然后尝试再次启动它（调试->运行） .但是，如果我从未闯入调试器，看起来连接在 'N' 一段时间内是稳定的。在此宽限期内，当我使用目标系统时，我什至可以在 WinDbg 中看到调试打印语句。此外，在调试中断时连接似乎很好，因为我可以从目标系统收集信息。我使用“!ustr srv!SrvComputerName”来获取目标计算机名称，它 returns 是正确的名称。任何帮助将不胜感激。
设置系统： 我按照 MSDN website 的说明设置我的目标和主机系统。
调试：以下是我尝试解决此问题的方法。
- 在网络适配器上禁用流量控制并使用半双工模式。我在读完这个 post 后尝试了这个：WinDbg, host machine lose network if test machine is on the same switch
- 购买新的网络适配器。根据this webpage，我的网络适配器应该支持网络内核调试。但是，进一步调查显示供应商有不更新设备 ID 的坏习惯，因此我决定通过从不同供应商购买新适配器来排除这种可能性。
- 正在更改网络端口。我尝试了一大堆不同的网络端口 (49152-65535)，以防其中一个被用于不同的目的。
- 拔下以太网电缆，然后重新插入。连接断开后，我尝试了此操作，希望它能重新建立连接。
- 正在重新启动目标系统。与#4 相同的原因。
- 更改 PCIe 端口。我 运行 没有选择。
- 将主机系统移动到不同的网络交换机。没有变化。
观察：
- Wireshark 显示目标系统在系统启动后立即向主机系统发送 UPD 包，但主机系统直到 WinDbg 启动后才响应。更有趣的是，即使在目标系统变得无响应后，目标系统仍会继续向主机发送 UPD 包。不幸的是，我不了解 UPD 包数据。
- 如果重新启动，WinDbg 可以始终如一地重新建立与目标系统的连接。目标系统似乎卡在调试中断中。
系统信息： 主机系统是 运行 Windows 8.1 Pro。目标系统是 运行 a Windows 8.1 Enterprise Evaluation（8GB RAM）。
WinDbg 打印出来：
Microsoft (R) Windows Debugger Version 6.3.9600.17237 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Using NET for debugging
Opened WinSock 2.0
Waiting to reconnect...
Connected to target **.**.*.*** on port ***** on local IP **.**.*.***
Connected to Windows 8 9600 x64 target at (Fri Mar 27 18:58:06.217 2015 (UTC - 7:00)), ptr64 TRUE
Kernel Debugger connection established.
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.17031.amd64fre.winblue_gdr.140221-1952
Machine Name:
Kernel base = 0xfffff801`00e70000 PsLoadedModuleList = 0xfffff801`0113a2d0
Debug session time: Fri Mar 27 18:58:06.918 2015 (UTC - 7:00)
System Uptime: 0 days 0:47:15.869
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
* *
* You are seeing this message because you pressed either *
* CTRL+C (if you run console kernel debugger) or, *
* CTRL+BREAK (if you run GUI kernel debugger), *
* on your debugger machine's keyboard. *
* *
* THIS IS NOT A BUG OR A SYSTEM CRASH *
* *
* If you did not intend to break into the debugger, press the "g" key, then *
* press the "Enter" key now. This message might immediately reappear. If it *
* does, press "g" and "Enter" again. *
* *
*******************************************************************************
nt!DbgBreakPointWithStatus:
fffff801`00fcab90 cc int 3
0: kd> g
... Retry sending the same data packet for 64 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.
... Retry sending the same data packet for 128 times.
... Retry sending the same data packet for 192 times.
此时WinDbg不再有响应，继续发送数据包。目标系统也无响应。
我终于通过切换主机系统解决了这个问题。一开始我以为是目标系统的问题，因为MSDN只是把网卡调试要求放在了目标系统上。似乎对主机系统也有要求。
新主机系统：桌面（与目标系统相同）
- OS: Windows 8.1 企业评估 x64
- 网卡：VEN_10EC&DEV_8168
以前的主机系统：笔记本电脑
- OS: Windows 8.1 Pro x64
- 网卡：VEN_8086&DEV_1502
注意：我真的不知道根本原因。两个 NIC 都在 Supported Ethernet NICs 列表中，我使用了 WDK 附带的相同 WinDbg 版本，并且所有系统都在同一个交换机上。
我遇到了类似的问题，并通过在主机上使用 USB 转以太网适配器而不是内置 NIC 卡解决了这个问题。
我也遇到了这个问题，发现当我尝试强制关闭 VMWare OS 时，windbg 连接似乎在 VMWare OS 实际关闭之前恢复。经过几次尝试，我发现了一个奇怪的解决方案：
当主机和VMWare 客户机之间的windbg 连接丢失时，尝试单击"shutdown VMWare Guest"，但不要真正确认。你可能会发现 windbg 连接恢复了！然后，取消关机。
很奇怪，好像是VMWare自己屏蔽了网络调试连接丢失。但至少这是一个值得尝试的解决方法。
我尝试过的另一种有时可行的解决方法是在任务管理器中终止 windbg，然后重新 运行 windbg 并重新连接到 VMWare 客户机。并且可能需要等待几秒到几分钟才能重新连接。
顺便说一句，我的以太网卡是 Intel Ethernet Connection I218-V。
我在 VMware 中找到了适合我的更简单的解决方案， 问题出在 vmware - NAT 连接超时 30 秒。 该值是可配置的。 去编辑 -> 虚拟网络编辑器 -> 更改设置（uac 提示） -> select 列表中的 NAT -> NAT 设置 -> UDP 超时。 最大值是 32767，默认值（对我来说）是 30 秒。 彻底解决了我的问题。
主机有问题。如果您不想更改主机并继续在其上进行调试，您可能想尝试使用串行端口。它提供了更好的性能。查看以下 link 以设置通过 com 端口调试虚拟机：