WinDbg теряет отладку соединения по сети и зависание целевой машины
Я пытаюсь заставить 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 ГБ ОЗУ).
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 больше не отвечает и продолжает отправлять пакеты данных. Целевая система также не отвечает.
3 ответа
Я наконец решил эту проблему, переключив хост-систему. Вначале я думал, что проблема связана с целевой системой, потому что MSDN только ставит требование отладки NIC в целевой системе. Похоже, что могут быть требования к хост-системе.
Новая хост-система: Desktop (идентична целевой системе)
- ОС: Windows 8.1 Enterprise Evaluation x64
- NIC: VEN_10EC & DEV_8168
Предыдущая хост-система: ноутбук
- ОС: Windows 8.1 Pro x64
- NIC: VEN_8086 и DEV_1502
ПРИМЕЧАНИЕ: я действительно не знаю причину. Оба сетевых адаптера находятся в списке поддерживаемых сетевых адаптеров Ethernet, я использовал одну и ту же версию WinDbg, поставляемую с WDK, и все системы находятся на одном коммутаторе.
Я нашел более простое решение, которое работало для меня в VMware. Проблема в vmware - таймаут для соединения NAT составляет 30 секунд. Это значение настраивается. Перейти к редактированию -> редактор виртуальной сети -> изменить настройки (приглашение UAC) -> выбрать NAT в списке -> настройки NAT -> тайм-аут UDP. Максимальное значение 32767, по умолчанию (для меня) было 30 секунд. Это полностью решило мою проблему.
У меня была похожая проблема, и я решил ее, используя адаптер USB-Ethernet на хост-машине вместо встроенной сетевой карты.
Я также столкнулся с этой проблемой и обнаружил, что когда я пытаюсь принудительно завершить работу ОС VMWare, кажется, что соединение windbg восстанавливается до того, как ОС VMWare фактически закрывается. После нескольких попыток я нашел странное решение:
Когда соединение windbg между хостом и гостем VMWare потеряно, попробуйте нажать "выключить гостя VMWare", но на самом деле НЕ подтвердите. И вы можете обнаружить, что связь windbg восстанавливается! Затем отмените выключение.
Это очень странно, кажется, сама VMWare заблокировала потерянное соединение для отладки сети. Но по крайней мере это обходной путь, который стоит попробовать.
Еще один обходной путь, который я пробовал, который иногда срабатывает, - убить windbg в диспетчере задач, перезапустить windbg и повторно подключиться к гостю VMWare. И, возможно, потребуется подождать секунд до минут, пока он не подключится
Кстати, моя сетевая карта - Intel Ethernet Connection I218-V.
Проблема с хостом. Если вы не хотите менять свой хост и продолжать отладку на нем, вы можете попробовать использовать последовательный порт. Это дает лучшую производительность. Взгляните на следующую ссылку для настройки отладки виртуальной машины через com-порт: