WinDbg traci połączenie debugowanie przez sieć i docelowego zatrzymania maszyny

Question

Próbuję uzyskać debugowanie WinDbg przez sieć do pracy, ale zawsze traci połączenia po włamać się do debuggera (Debug-> Break), a następnie spróbuj uruchom go ponownie (Debuguj-> Idź). Jeśli jednak nigdy nie włamie się do debuggera, wygląda na to, że połączenie jest stabilne przez okres "N". Mogę nawet zobaczyć instrukcje debugowania w WinDbg, ponieważ korzystam z systemu docelowego podczas tego okresu prolongaty. Co więcej, wygląda na to, że połączenie jest dobre podczas przerwy w debugowaniu, ponieważ mogę zbierać informacje z systemu docelowego. Używam "! Ustr srv! SrvComputerName", aby uzyskać nazwę komputera docelowego, i zwraca poprawną nazwę. Każda pomoc byłaby bardzo cenna.

Konfigurowanie systemów: Wykonałem instrukcje od MSDN website, aby skonfigurować system docelowy i system hosta.

Debugowanie: Poniżej znajdują się moje próby rozwiązania tego problemu.

1. Wyłączenie sterowania przepływem, a w trybie half duplex, na adapterze sieciowym. Próbowałem tego po przeczytaniu tego posta: WinDbg, host machine lose network if test machine is on the same switch
2. Kupowanie nowych adapterów sieciowych. Zgodnie z this webpage moja karta sieciowa powinna obsługiwać debugowanie jądra sieci. Jednak dalsze dochodzenie pokazuje, że sprzedawcy mają zły zwyczaj nie aktualizować swoich identyfikatorów urządzeń, więc postanowiłem wykluczyć tę możliwość, kupując nowe karty od różnych dostawców.
3. Zmiana portu sieciowego. Wypróbowałem strony pełne różnych portów sieciowych (49152-65535) na wypadek, gdyby jeden z nich był używany do innego celu.
4. Odłączanie kabla Ethernet, a następnie podłącz go ponownie do urządzenia. Po utracie połączenia próbowałem mieć nadzieję, że przywróci ono połączenie.
5. Ponowne uruchomienie systemu docelowego. Ten sam powód, co w punkcie # 4.
6. Zmiana portów PCIe. Kończą mi się opcje.
7. Przeniesiono system hosta do innego przełącznika sieciowego. Bez zmiany.

Obserwacja:

1. Wireshark pokazuje, że docelowy system wysyła do pakietów UPD do systemu hosta, jak tylko system zostanie uruchomiony, ale system hosta nie reaguje aż WinDbg jest uruchomiona. Co ciekawsze, system docelowy nadal wysyła pakiety UPD do hosta nawet po tym, jak system docelowy przestał reagować. Niestety, nie rozumiem danych pakietów UPD.
2. Program WinDbg może ponownie nawiązać połączenie z systemem docelowym po ponownym uruchomieniu. System docelowy wydaje się utknąć w przerwie debugowania.

Informacje o systemie: System hosta obsługuje system Windows 8.1 Pro. System docelowy uruchamia system Windows 8.1 Enterprise Evaluation (8 GB pamięci RAM).

WinDbg wydrukować:

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. 

W tym momencie nie jest już WinDbg czułe i kontynuować wysyłanie pakietów danych. System docelowy również nie reaguje.

Answer 1

końcu rozwiązać ten problem przez włączenie do systemu hosta. Na początku myślałem, że problemem jest system docelowy, ponieważ tylko MSDN umieścił wymaganie debugowania NIC w systemie docelowym. Wydaje się, że mogą istnieć wymagania stawiane również systemowi hosta.

Nowy system host: pulpitu (identyczny jak kierować System)

• OS: Windows 8.1 Enterprise ocena 64
• NIC: VEN_10EC & DEV_8168

Poprzedni system hosta: Laptop

• OS: Windows 8.1 Pro 64
• NIC: VEN_8086 & DEV_1502

UWAGA: Ja naprawdę nie wiem przyczynę. Obie karty NIC znajdują się na liście Supported Ethernet NICs, użyłem tej samej wersji WinDbg, która została dostarczona z WDK, a wszystkie systemy są na tym samym przełączniku.

Answer 2

miałem podobny problem i rozwiązać go za pomocą USB adapter Ethernet w komputerze hosta zamiast we wbudowanej karty sieciowej.

Answer 3

Poznałem również ten problem, i okazało się, że przy próbie wymuszenia zamknięcia VMWare OS, połączenie windbg wydaje odzyskać przed VMWare OS jest właściwie zamknięty. Po kilku próbach znalazłem dziwne rozwiązanie:

Gdy połączenie windbg między hostem a gościem VMWare zostało utracone, spróbuj kliknąć "zamknij gościa VMWare", ale NIE potwierdzaj. I może się okazać, że połączenie windbg odzyskuje! Następnie anuluj zamknięcie.

To bardzo dziwne, zdaje sobie VMWare zablokowane połączenia sieciowego debugowania utracone. Ale przynajmniej warto obejść ten problem.

Innym obejście Próbowałem, który czasami działa, zabija windbg w menedżerze zadań, a następnie ponownie uruchomić WinDbg i podłączyć do VMWare gościa. I może potrzebować czekać od sekund do minut, aż się połączy.

btw, moja karta Ethernet Połączenie Ethernet jest Intel I218-V.