我正试图通过网络进行WinDbg调试，但在我闯入调试器（Debug->break），然后尝试重新启动它（Debug->Go）后，它总是会失去连接。但是，如果我从未中断调试器，那么在"N"段时间内，连接看起来是稳定的。在这个宽限期内，当我使用目标系统时，我甚至可以在WinDbg中看到调试打印语句。此外，在调试中断时，连接似乎很好，因为我可以从目标系统收集信息。我使用"！ustr-srv！SrvComputerName"获取目标计算机名称，它会返回正确的名称。任何帮助都将不胜感激。
设置系统：我按照MSDN网站上的说明设置了目标和主机系统。
调试：以下是我解决此问题的尝试。
- 在网络适配器上禁用流量控制并使用半双工模式。我在阅读这篇文章后尝试了这个：WinDbg，如果测试机在同一个交换机上，主机就会失去网络
- 购买新的网络适配器。根据这个网页，我的网络适配器应该支持网络内核调试。然而，进一步的调查显示，供应商有一个不更新设备ID的坏习惯，所以我决定从不同的供应商那里购买新的适配器来排除这种可能性
- 更改网络端口。我试过一手不同的网络端口（49152-65535），以防其中一个用于不同的目的
- 拔下以太网电缆的插头，然后将其插回。一旦失去了连接，我尝试了这个，希望它能重新建立连接
- 正在重新启动目标系统。原因与#4相同
- 更改PCIe端口。我没有选择了
- 已将主机系统移动到其他网络交换机。没有变化
观察：
- Wireshark显示，一旦系统启动，目标系统就会向主机系统发送UPD包，但主机系统直到WinDbg启动后才会做出响应。更有趣的是，即使在目标系统变得没有响应之后，目标系统也会继续向主机发送UPD包。不幸的是，我不了解UPD包的数据
- 如果重新启动，WinDbg可以始终重新建立与目标系统的连接。目标系统似乎陷入了调试中断
系统信息：主机系统正在运行Windows 8.1 Pro。目标系统正在运行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不再响应，并继续发送数据包。目标系统也没有响应。
我找到了一个在VMware中适用的更简单的解决方案，问题出在vmware中——NAT连接超时30秒。此值是可配置的。转到编辑->虚拟网络编辑器->更改设置（uac提示）->在列表中选择NAT->NAT设置->UDP超时。最大值是32767，默认值（对我来说）是30秒。它完全解决了我的问题。
我最终通过切换主机系统解决了这个问题。一开始，我认为目标系统是问题所在，因为MSDN只对目标系统提出了NIC调试要求。看来主机系统也可能存在一些要求。
新主机系统：桌面（与目标系统相同）
- 操作系统：Windows 8.1 Enterprise Evaluation x64
- NIC：VEN_10EC&DEV_8168
以前的主机系统：笔记本电脑
- 操作系统：Windows 8.1 Pro x64
- NIC：VEN_8086&DEV_1502
注意：我真的不知道根本原因。两个NIC都在支持的以太网NIC列表中，我使用了WDK附带的相同WinDbg版本，并且所有系统都在同一个交换机上。
我遇到了类似的问题，并通过在主机上使用USB到以太网适配器而不是内置NIC卡来解决。
我也遇到了这个问题，发现当我试图强制关闭VMWare操作系统时，windbg连接似乎在VMWare OS实际关闭之前恢复。经过几次尝试，我发现了一个奇怪的解决方案：
当主机和VMWare来宾之间的windbg连接丢失时，尝试单击"关闭VMWare guest"，但不要真正确认。你可能会发现windbg连接恢复了！然后，取消关机。
这很奇怪，似乎VMWare本身屏蔽了网络调试连接丢失。但至少这是一个值得尝试的变通方法。
我尝试过的另一种变通方法有时也能奏效，就是在任务管理器中杀死windbg，然后重新运行windbg并重新连接到VMWare来宾。并且可能需要等待几秒钟到几分钟，直到它重新连接。
顺便说一句，我的以太网卡是Intel以太网连接I218-V。
问题出在主机上。如果您不想更改主机并继续对其进行调试，您可能需要尝试使用串行端口。这样可以提供更好的性能。查看以下链接以通过com端口设置虚拟机调试：
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/attaching-to-a-virtual-machine--kernel-mode-?redirectedfrom=MSDN