Debugging WinDbg在网络上失去连接调试,目标计算机冻结
我正在尝试通过网络进行WinDbg调试,但在我进入调试器(调试->中断),然后再次尝试启动它(调试->转到)后,它总是会失去连接。但是,如果我从未闯入调试器,则连接在“N”段时间内看起来是稳定的。在这个宽限期内使用目标系统时,我甚至可以在WinDbg中看到调试打印语句。此外,在调试中断时,连接似乎很好,因为我可以从目标系统收集信息。我使用“!ustr srv!SrvComputerName”获取目标计算机名,它返回正确的名称。任何帮助都将不胜感激 设置系统:我按照中的说明设置目标系统和主机系统 调试:下面是我解决此问题的尝试Debugging WinDbg在网络上失去连接调试,目标计算机冻结,debugging,windbg,kernel-mode,Debugging,Windbg,Kernel Mode,我正在尝试通过网络进行WinDbg调试,但在我进入调试器(调试->中断),然后再次尝试启动它(调试->转到)后,它总是会失去连接。但是,如果我从未闯入调试器,则连接在“N”段时间内看起来是稳定的。在这个宽限期内使用目标系统时,我甚至可以在WinDbg中看到调试打印语句。此外,在调试中断时,连接似乎很好,因为我可以从目标系统收集信息。我使用“!ustr srv!SrvComputerName”获取目标计算机名,它返回正确的名称。任何帮助都将不胜感激 设置系统:我按照中的说明设置目标系统和主机系统
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.
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不再响应,继续发送数据包。目标系统也没有响应。我最终通过切换主机系统解决了这个问题。一开始,我认为目标系统是问题所在,因为只将NIC调试需求放在目标系统上。看来,主机系统中可能也存在一些需求 新主机系统:桌面(与目标系统相同)
- 操作系统:Windows 8.1企业评估x64
- NIC:VEN_10EC和DEV_8168
- 操作系统:Windows 8.1 Pro x64
- NIC:VEN_8086和DEV_1502
注意:我不知道根本原因。这两个NIC都在列表中,我使用了WDK附带的同一个WinDbg版本,所有系统都在同一个交换机上。我遇到了类似的问题,并通过在主机上使用USB到以太网适配器而不是内置NIC卡解决了它。我也遇到了这个问题,并发现当我试图强制关闭VMWare OS时,windbg连接似乎在VMWare操作系统实际关闭之前恢复。经过几次尝试,我发现了一个奇怪的解决方案: 当主机和VMWare guest之间的windbg连接丢失时,请尝试单击“关闭VMWare guest”,但不要真正确认。您可能会发现windbg连接已恢复!然后,取消关机 很奇怪,似乎VMWare本身阻止了网络调试连接丢失。但至少这是一个值得尝试的变通方法 我尝试过的另一种解决方法(有时有效)是在task manager中杀死windbg,然后重新运行windbg并重新连接到VMWare guest。可能需要等待几秒到几分钟,直到重新连接
顺便说一句,我的以太网卡是Intel ethernet Connection I218-V。我在VMware中找到了一个更简单的解决方案, 问题出在vmware中—NAT连接有30秒超时。 此值是可配置的。 进入编辑->虚拟网络编辑器->更改设置(uac提示)->在列表中选择NAT->NAT设置->UDP超时。 最大值为32767,默认值(对于我)为30秒。
它完全解决了我的问题。问题出在主机上。如果不想更改主机并继续在其上进行调试,则可能需要尝试使用串行端口。它提供了更好的性能。查看以下链接以设置通过com端口调试虚拟机:
不要在问题中发布解决方案。如果你愿意,你可以发布你问题的答案。这是协议吗?是的,它是。你能分享一下具体的供应商和产品吗?对我来说完全一样。我的目标是Windows10x64,NIC:venu 8086和DEV_1502。当我使用Dell笔记本电脑作为带有VEN_10EC&DEV_8168的主机时,我的连接将失败,如OP中所述。当我使用另一台PC作为带有VEN_8086&DEV_100F的主机时,连接工作正常。无需更改目标(当然,更改hostip设置除外)。