Sto cercando di ottenere il debugging della rete WinDbg sulla rete, ma perde sempre le connessioni dopo l'accesso al debugger (Debug-> Break), quindi provo a ricominciare (Debug-> Vai). Tuttavia, se non inserisco mai il debugger, sembra che la connessione sia stabile per un periodo di tempo "N". Posso persino vedere le istruzioni di stampa di debug in WinDbg mentre utilizzo il sistema di destinazione durante questo periodo di prova. Inoltre, sembra che la connessione sia buona durante l'interruzione di debug, perché posso raccogliere informazioni dal sistema di destinazione. Io uso "! Ustr srv! SrvComputerName" per ottenere il nome del computer di destinazione e restituisce il nome corretto. Qualsiasi aiuto sarebbe molto apprezzato.WinDbg perde il debug della connessione sulla rete e il blocco della macchina di destinazione
Configurazione dei sistemi: Ho seguito le istruzioni da MSDN website per configurare i sistemi di destinazione e host.
Debug: Di seguito sono riportati i miei tentativi di risolvere questo problema.
- Disabilitazione controllo di flusso, e utilizzando la modalità Half Duplex, sulla scheda di rete. Ho provato questo dopo aver letto questo post: WinDbg, host machine lose network if test machine is on the same switch
- Acquisto di nuovi adattatori di rete. Secondo this webpage, la mia scheda di rete dovrebbe supportare il debug del kernel di rete. Tuttavia, ulteriori indagini mostrano che i venditori hanno la brutta abitudine di non aggiornare i propri ID di dispositivo, quindi ho deciso di escludere questa possibilità acquistando nuovi adattatori da diversi fornitori.
- Modifica porta di rete. Ho provato una mano piena di porte di rete diverse (49152-65535) nel caso in cui uno di loro viene utilizzato per uno scopo diverso.
- Scollegare il cavo Ethernet, quindi ricollegarlo in. Una volta persa la connessione, ho provato questo sperando che ristabilisse la connessione.
- Riavvio del sistema di destinazione. La stessa ragione del # 4.
- Modifica delle porte PCIe. Sono a corto di opzioni.
- Spostato il sistema host su un altro switch di rete. Nessun cambiamento.
Osservazione:
- Wireshark dimostra che il sistema di destinazione invia una pacchetti UPD al sistema host non appena si avvia il sistema, ma il sistema host non risponde fino WinDbg è lanciato. Più interessante, il sistema di destinazione continua a inviare pacchetti UPD all'host anche dopo che il sistema di destinazione non ha risposto. Sfortunatamente, non capisco i dati dei pacchetti UPD.
- WinDbg può ristabilire costantemente la connessione con il sistema di destinazione, se riavviato. Il sistema di destinazione sembra essere bloccato nell'intervallo di debug.
Info sistema: Il sistema host esegue Windows 8.1 Pro. Il sistema di destinazione sta eseguendo una valutazione Enterprise di Windows 8.1 (8 GB di RAM).
WinDbg stampare:
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.
A questo punto WinDbg non è più reattivo, e continuare l'invio di pacchetti di dati. Anche il sistema di destinazione non risponde.
Non pubblicare soluzioni nella domanda. Puoi postare una risposta alla tua domanda, se ti va. –
È il protocollo? –
Sì, lo è. http://stackoverflow.com/help/self-answer –