Опитвам се да накарам WinDbg отстраняването на грешки по мрежата да работи, но винаги губи връзки, след като пробия в дебъгера (Debug->Break), и след това се опитам да го стартирам отново (Debug->Go). Въпреки това, ако никога не проникна в програмата за отстраняване на грешки, изглежда, че връзката е стабилна за „N“ период от време. Мога дори да видя изрази за печат за отстраняване на грешки в WinDbg, докато използвам целевата система по време на този гратисен период. Освен това изглежда, че връзката е добра, докато сте в прекъсване на отстраняването на грешки, защото мога да събера информация от целевата система. Използвам "!ustr srv!SrvComputerName", за да получа името на целевия компютър и той връща правилното име. Всяка помощ ще бъде много ценена.
Настройване на системите: Следвах инструкциите от уебсайт на MSDN за настройка на моите целеви и хост системи.
Отстраняване на грешки: По-долу са моите опити за разрешаване на този проблем.
- Деактивиране на контрола на потока и използване на полудуплексен режим на мрежовия адаптер. Опитах това, след като прочетох тази публикация: WinDbg, хост машината губи мрежа, ако тестовата машина е на същия комутатор
- Закупуване на нови мрежови адаптери. Според тази уеб страница, моят мрежов адаптер трябва да поддържа отстраняване на грешки в мрежовото ядро. По-нататъшното разследване обаче показва, че доставчиците имат лошия навик да не актуализират идентификаторите на своите устройства, така че реших да изключа тази възможност, като закупя нови адаптери от различни доставчици.
- Промяна на мрежовия порт. Изпробвах цяла ръка с различни мрежови портове (49152-65535) само в случай, че някой от тях се използва за различна цел.
- Изключете Ethernet кабела и след това го включете отново. След като връзката беше загубена, опитах това с надеждата, че ще възстанови връзката.
- Рестартиране на целевата система. Същата причина като #4.
- Промяна на PCIe портове. Свършват ми опциите.
- Преместена хост система към друг мрежов комутатор. Няма промяна.
Наблюдение:
- Wireshark показва, че целевата система изпраща UPD пакети към хост системата веднага щом системата се зареди, но хост системата не отговаря, докато WinDbg не бъде стартиран. По-интересното е, че целевата система продължава да изпраща UPD пакети към хост дори след като целевата система спре да реагира. За съжаление, не разбирам данните за UPD пакетите.
- WinDbg може постоянно да възстановява връзката с целевата система, ако се рестартира. Изглежда, че целевата система е блокирала в прекъсване на отстраняването на грешки.
Информация за системата: Хост системата работи с Windows 8.1 Pro. Целевата система работи с Windows 8.1 Enterprise Evaluation (8 GB 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 вече не реагира и продължава да изпраща пакети с данни. Целевата система също не реагира.
