Uma sessão de depuração remota do Windows anexa um depurador em uma máquina a um programa em outra por meio de uma rede e é destinada apenas às suas próprias máquinas de laboratório. Os símbolos vêm primeiro. Nomeie uma máquina como host e a outra como alvo. Compile o programa com símbolos de depuração e mantenha o PDB correspondente para essa compilação exata, pois um PDB incompatível gera nomes de função incorretos e uma pilha sem símbolos mostra apenas endereços. Instale o StatusRivet no host, onde você trabalha, e mantenha o alvo dedicado apenas ao programa em teste. Anote qualquer configuração alterada em qualquer uma das máquinas para que você possa restaurá-la depois. Reproduza a falha com a menor entrada possível, pois um caso curto gera uma pilha curta e uma comparação mais fácil. Verifique se o host e o alvo conseguem se comunicar antes de pedir ao agente que faça algo, já que uma falha de conexão pode ser confundida com uma falha do depurador.
Defina a pasta com seu código-fonte e arquivos de compilação como o diretório de trabalho do chat, pois as ferramentas de arquivo leem e editam apenas dentro dela. Coloque também a pilha salva e as anotações lá, para que todo o caso fique em um só lugar e o agente possa ler tudo.
Ask first pausa antes de ações que alteram algo, permitindo que você leia cada uma antes da execução. Use Plan only quando quiser ver os passos primeiro e não executar nada. Um plano sobrevive a uma reinicialização, permitindo que você o retome mais tarde.
Informe o nome do programa, as máquinas host e alvo e o sintoma, e declare que as máquinas são suas. Forneça os detalhes de conexão retirados das suas anotações de laboratório e não adivinhe nenhum deles. Informe qual compilação está sendo executada no alvo e a qual PDB ela pertence.
Leia o diff, recompile com seu comando de compilação e execute seu comando de teste novamente no alvo. Mantenha as anotações sobre o que mudou junto com a lista de verificação e conserve o dump antigo se o novo teste ainda falhar, para que a próxima tentativa parta de evidências e não da memória.
attach your debugger to the targetanexadosave the dump on the targetsalvowrite the call stack to stack.txtsalvostack.txtlido0xC0000005 stack.txt1 correspondência# Debug session checklist
1. Build the app with debug symbols and keep the PDB
2. Note the build the crash happened on
3. Start the debugger on the host machine
4. Attach to the app running on the target
5. Reproduce the crash with the smallest input
6. Save a crash dump on the target
7. Save the faulting thread's call stack to stack.txt
8. Read the exception code and the top frames
9. Match the first frame to a source line
10. Propose a minimal fix and rebuild
11. Run the test again and note what changedUma lista de verificação em texto puro para uma sessão de depuração entre duas máquinas de laboratório. Ela cobre a compilação com símbolos, anexação, reprodução da falha com a menor entrada, salvamento de um dump e uma pilha de chamadas, leitura dos quadros superiores e termina com uma execução de teste após a correção, com anotações sobre o que mudou. Copie-a para a pasta do seu projeto e edite-a para corresponder ao seu próprio laboratório. Copie e edite.
Tarefa: anexe da máquina host ao seu próprio programa executando no alvo do laboratório. Anexe primeiro. Abra a pasta do projeto no StatusRivet, mude para Ask first e descreva a configuração. Shell executa o modo de linha de comando do seu depurador com os detalhes de conexão fornecidos, e o cartão mostra se o anexo foi realizado pelo código de saída real. O agente não inventa configurações de conexão, então pegue o host, o alvo e a porta das suas próprias anotações de laboratório. A depuração remota é apenas para suas máquinas de laboratório, nunca para um computador que você não possui. Leia o cartão antes da próxima etapa. Se o anexo falhou, nada mais deve ser executado; corrija a conexão primeiro e depois peça novamente. O cartão também mantém o comando exato, para que você possa repeti-lo mais tarde.
Tarefa: após reproduzir a falha no alvo com a menor entrada, salve as evidências. Salve ambos os arquivos. Shell solicita ao seu depurador que escreva um dump de falha e salve a pilha de chamadas do thread falho em um arquivo de texto, e os cartões mostram ambos os resultados. Uma entrada do depurador JIT do Windows no alvo inicia um depurador automaticamente quando um aplicativo falha. Essa é uma configuração do sistema, então altere-a apenas em uma máquina de teste, anote o valor anterior e restaure-o depois. Para encontrar a causa de uma falha do sistema a partir de um minidump, comece pela pilha de chamadas salva. Você aprova cada etapa no modo Ask first e mantém ambos os arquivos com a lista de verificação para a próxima pessoa que ler o caso. Nomeie os arquivos de acordo com a compilação para evitar confusões.
Tarefa: conecte o quadro superior ao seu código. Comece com os símbolos. read_file abre stack.txt, grep pesquisa o projeto pelo nome da função e pelo código de exceção, como 0xC0000005 para uma violação de acesso, e read_file abre o arquivo de código-fonte nessa linha. Com o PDB correspondente, a pilha mostra nomes de função, arquivos de origem e números de linha; sem ele, você vê apenas endereços. Uma máquina congelada que termina em uma tela azul com falha de verificação de segurança do kernel é um caso exato para esta rotina: dump, pilha, código-fonte. Leia as evidências você mesmo antes que o agente edite algo, pois o agente trabalha com texto e não pode fazer step-through no programa para você. Para step-through, use seu próprio depurador e informe ao agente o que você viu.
Tarefa: transforme a descoberta em uma alteração. edit_file propõe um diff mínimo, por exemplo, uma verificação nula ausente ou um índice incorreto, e no modo Ask first o agente pausa para que você possa ler as linhas alteradas. Shell então executa seu comando de compilação, com símbolos, e seu comando de teste, e os cartões relatam os códigos de saída reais. Uma falha de corrupção de heap no modo kernel em um driver que você escreveu pode aparecer muito tempo depois da escrita incorreta, então verifique os buffers escritos anteriormente na pilha, não apenas o último quadro. Uma exceção de armazenamento inesperada no seu alvo de laboratório é tratada da mesma forma. Aceite o diff apenas após o teste passar e anote o que mudou. Teste antes de aceitar. Se o teste ainda falhar, mantenha a nova pilha e inicie o loop novamente a partir do segundo passo.
