Estoy tratando de hacer que la depuración de WinDbg a través de la red funcione, pero siempre pierde conexiones después de entrar en el depurador (Debug-> Break), y luego trato de iniciarlo nuevamente (Debug-> Go). Sin embargo, si nunca interrumpo el depurador, parece que la conexión es estable por un período de tiempo 'N'. Incluso puedo ver las declaraciones de impresión de depuración en WinDbg mientras uso el sistema de destino durante este período de gracia. Además, parece que la conexión es buena durante la pausa de depuración, porque puedo recopilar información del sistema de destino. Utilizo "! Ustr srv! SrvComputerName" para obtener el nombre del equipo de destino, y devuelve el nombre correcto. Cualquier ayuda sería muy apreciada.

Configuración de los sistemas: Seguí las instrucciones deSitio web de MSDN para configurar mi objetivo y los sistemas host.

Depuración A continuación están mis intentos de resolver este problema.

Desactivar el control de flujo y usar el modo Half Duplex en el adaptador de red. Intenté esto después de leer esta publicación:WinDbg, la máquina host pierde la red si la máquina de prueba está en el mismo conmutadorComprar nuevos adaptadores de red. De acuerdo aesta pagina web, mi adaptador de red debe admitir la depuración del núcleo de la red. Sin embargo, una investigación adicional muestra que los proveedores tienen la mala costumbre de no actualizar sus ID de dispositivo, por lo que decidí descartar esta posibilidad comprando nuevos adaptadores de diferentes proveedores.Cambio de puerto de red. He probado un montón de puertos de red diferentes (49152-65535) en caso de que uno de ellos se esté utilizando para un propósito diferente.Desenchufe el cable Ethernet y luego vuelva a enchufarlo. Una vez que se ha perdido la conexión, intenté esto con la esperanza de que restablecería la conexión.Reiniciar el sistema de destino. El mismo motivo que el n. ° 4.Cambio de puertos PCIe. Me estoy quedando sin opciones.Se trasladó el sistema host a un conmutador de red diferente.. Ningún cambio.

Observación:

Wireshark muestra que el sistema de destino envía paquetes UPD al sistema host tan pronto como se inicia el sistema, pero el sistema host no responde hasta que se inicia WinDbg. Más interesante aún, el sistema objetivo continúa enviando paquetes UPD al host incluso después de que el sistema objetivo no responde. Desafortunadamente, no entiendo los datos de los paquetes UPD.WinDbg puede restablecer constantemente la conexión con el sistema de destino, si se reinicia. El sistema de destino parece estar atascado en la pausa de depuración.

Información del sistema: El sistema host ejecuta Windows 8.1 Pro. El sistema de destino ejecuta una evaluación empresarial de Windows 8.1 (8 GB de RAM).

WinDbg imprime:

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.

En este punto, WinDbg ya no responde y continúa enviando paquetes de datos. El sistema de destino tampoco responde.