WinDbg通过网络失去连接调试，目标机器冻结 [英] WinDbg loses connection debugging over network, and target machine freeze
问题描述
设置系统：我按照 MSDN网站设置我的目标和主机系统。
调试：以下是我尝试解决此问题的方法。
- em>禁用流量控制，并使用半双工模式，在网络适配器上。我在阅读这篇文章后尝试过： WinDbg，如果测试机在同一个交换机上，主机将丢失网络
- 购买新的网络适配器。根据此网页我的网络适配器应该支持网络内核调试。然而，进一步的调查显示，供应商有不习惯更新其设备ID的不良习惯，所以我决定通过从不同供应商处购买新的适配器来排除这种可能性。
- 更改网络端口。我尝试了一个充满不同网络端口的手（49152-65535），以防其中一个被用于不同的目的。
- 拔下以太网电缆，然后将其插回。一旦连接丢失，我尝试这个希望它会重新建立连接。
- 重新启动目标系统。与＃4相同的原因。
- 更改PCIe端口。我没有选择。
- 将主机系统移动到其他网络交换机。没有变化。
观察：
- Wireshark显示目标系统在系统启动后立即向主机系统发送UPD软件包，但主机系统在启动WinDbg之前不会响应。更有趣的是，即使在目标系统无响应之后，目标系统也会继续发送UPD包。不幸的是，我不明白UPD包数据。
- 如果重新启动，WinDbg可以始终重新建立与目标系统的连接。目标系统似乎陷入了调试中断。
系统信息：主机系统正在运行Windows 8.1专业版目标系统正在运行Windows 8.1企业评估（8GB RAM）。
WinDbg打印出来：
Microsoft（R）Windows Debugger版本6.3.9600.17237 AMD64
版权所有（c）Microsoft Corporation。版权所有。
使用NET调试
打开的WinSock 2.0
等待重新连接...
连接到目标**。**。*。***在端口* ****在本地IP **。**。*。***
连接到Windows 8 9600 x64目标在（Fri Mar 27 18：58：06.217 2015（UTC - 7:00）），ptr64 TRUE
建立内核调试器连接。
*************符号路径验证摘要**************
响应时间（ms）位置
Deferred srv * C：\Symbols * http：//msdl.microsoft.com/download/symbols
符号搜索路径为：srv * C：\Symbols * http：//msdl.microsoft。 com / download / symbols
可执行搜索路径是：
Windows 8内核版本9600 MP（4 procs）Free x64
产品：WinNt，suite：TerminalServer SingleUserTS
内置于：9600.17031 .amd64fre.winblue_gdr.140221-1952
机器名称：
内核基数= 0xfffff801`00e70000 PsLoadedModuleList = 0xfffff801`0113a2d0
调试会话时间：Fri Mar 27 18：58：06.918 2015（UTC - 7:00）
系统正常运行时间：0天0：47：15.869
中断指令异常 - 代码80000003（第一次机会）
************** ************************************** ***************
* *
*你是因为您按*
* CTRL + C（如果您运行控制台内核调试器）或*
* CTRL + BREAK（如果您运行GUI内核调试器），*
*在你的调试器的键盘上。 *
* *
*这不是一个BUG或一个系统崩溃*
* *
*如果您不打算进入调试器，请按g键，然后*
*现在按Enter键。此消息可能会立即重新出现。如果*
*确实，再次按g和Enter。 *
* *
***************************************** ****************************************
nt！DbgBreakPointWithStatus：
fffff801`00fcab90 cc int 3
0：kd> g
...重试发送相同的数据包64次。
主机内核调试器和目标Windows之间的传输连接似乎丢失了。
请尝试与目标重新同步，回收主机调试器，或重新启动目标Windows。
...重试发送相同的数据包128次。
...重试发送相同的数据包192次。
此时，WinDbg不再响应，并继续发送数据包。目标系统也是无响应的。
我终于通过切换主机系统解决了这个问题。一开始，我认为目标系统是问题，因为 MSDN 仅将NIC调试要求放在目标系统上。
新的主机系统：桌面（与目标系统相同）
- 操作系统：Windows 8.1企业评估x64
- NIC：VEN_10EC& DEV_8168
以前的主机系统：笔记本电脑
- ：Windows 8.1 Pro x64
- NIC：VEN_8086& DEV_1502
注意：真的知道根本原因。两个NIC都位于支持的以太网NIC 列表中，我使用与WDK相同的WinDbg版本，所有系统都在同一个交换机上。
I'm trying to get WinDbg debugging over the network to work, but it always loses connections after I break into the debugger (Debug->Break), and then try to start it again (Debug->Go). However, if I never break into the debugger, it looks like the connection is stable for an 'N' period of time. I can even see debug print statements in WinDbg as I use the target system during this grace period. Moreover, It seems like the connection is good while in debug break, because I can gather information from the target system. I use "!ustr srv!SrvComputerName" to get the target computer name, and it returns the correct name. Any help would be much appreciated.
Setting up the systems: I followed instructions from MSDN website to setup my target and host systems.
Debugging: Below are my attempts to resolve this issue.
- Disabling Flow Control, and using Half Duplex mode, on the network adapter. I tried this after reading this post: WinDbg, host machine lose network if test machine is on the same switch
- Buying new network adapters. According to this webpage, my network adapter should support network kernel debugging. However, further investigation shows that vendors have a bad habit of not updating their device IDs, so I decided to rule out this possibility by buying new adapters from different vendors.
- Changing network port. I've tried a hand full of different network ports (49152-65535) just in case one of them is being used for a different purpose.
- Unplugging the Ethernet cable, and then plug it back in. Once the connection has been lost, I tried this hoping it would re-establish connection.
- Rebooting the target system. Same reason as #4.
- Changing PCIe ports. I'm running out of options.
- Moved host system to a different network switch. No change.
Observation:
- Wireshark shows that the target system sends a UPD packages to the host system as soon as the system boots up, but the host system does not respond until WinDbg is launched. More interestingly, the target system continue sending UPD packages to host even after the target system has become unresponsive. Unfortunately, I don't understand the UPD packages data.
- WinDbg can consistently re-establish connection with target system, if restarted. The target system seems to be stuck in debug break.
System Info: The host system is running Windows 8.1 Pro. The target system is running a Windows 8.1 Enterprise Evaluation (8GB of RAM).
WinDbg print out:
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.
At this point WinDbg is no longer responsive, and continue sending data packets. The target system is also non-responsive.
I finally solved this problem by switching the host system. In the beginning, I thought the target system was the problem, because MSDN only put the NIC debug requirement on the target system. It appears that there might be requirements placed the host system as well.
New host system: Desktop (Identical to target system)
- OS: Windows 8.1 Enterprise Evaluation x64
- NIC: VEN_10EC&DEV_8168
Previous host system: Laptop
- OS: Windows 8.1 Pro x64
- NIC: VEN_8086&DEV_1502
NOTE: I don't really know the root cause. Both NICs are on the Supported Ethernet NICs list, I used the same WinDbg version that came with the WDK, and all systems are on the same switch.
这篇关于WinDbg通过网络失去连接调试，目标机器冻结的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
