Estou tentando fazer com que a depuração do WinDbg pela rede funcione, mas ela sempre perde conexões depois que eu entro no depurador (Debug-> Break) e, em seguida, tente iniciá-lo novamente (Debug-> Go). No entanto, se eu nunca entrar no depurador, parece que a conexão é estável por um período 'N'. Eu posso até ver instruções de depuração de impressão no WinDbg enquanto uso o sistema de destino durante esse período de cortesia. Além disso, parece que a conexão é boa durante a quebra de depuração, porque eu posso coletar informações do sistema de destino. Eu uso "! Ustr srv! SrvComputerName" para obter o nome do computador de destino e ele retorna o nome correto. Qualquer ajuda seria muito apreciada.

Configurando os sistemas: Eu segui as instruções deSite da MSDN para configurar meus sistemas de destino e host.

Depuração: Abaixo estão minhas tentativas para resolver esse problema.

Desabilitando o Controle de Fluxo e usando o modo Half Duplex no adaptador de rede. Eu tentei isso depois de ler este post:WinDbg, máquina host perde a rede se a máquina de teste estiver no mesmo switchComprando novos adaptadores de rede. De acordo comesta página, meu adaptador de rede deve suportar a depuração do kernel de rede. No entanto, uma investigação mais aprofundada mostra que os fornecedores têm o mau hábito de não atualizar seus IDs de dispositivo, então decidi descartar essa possibilidade comprando novos adaptadores de diferentes fornecedores.Alterando a porta de rede. Tentei uma mão cheia de portas de rede diferentes (49152-65535), apenas no caso de uma delas estar sendo usada para uma finalidade diferente.Desconectando o cabo Ethernet e conecte-o novamente. Depois que a conexão foi perdida, tentei isso esperando que restabelecesse a conexão.Reiniciando o sistema de destino. Mesmo motivo que o nº 4.Alterando portas PCIe. Estou ficando sem opções.Movido o sistema host para um comutador de rede diferente. Nenhuma mudança.

Observação:

O Wireshark mostra que o sistema de destino envia pacotes UPD para o sistema host assim que o sistema é inicializado, mas o sistema host não responde até que o WinDbg seja iniciado. Mais interessante, o sistema de destino continua enviando pacotes UPD para o host, mesmo depois que o sistema de destino não responde. Infelizmente, não entendo os dados dos pacotes UPD.O WinDbg pode restabelecer consistentemente a conexão com o sistema de destino, se reiniciado. O sistema de destino parece estar preso na quebra de depuração.

Informação do sistema: O sistema host está executando o Windows 8.1 Pro. O sistema de destino está executando uma Avaliação Empresarial do Windows 8.1 (8 GB de RAM).

Impressão do 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.

Nesse ponto, o WinDbg não responde mais e continua enviando pacotes de dados. O sistema de destino também não responde.