Tarefas de depuração x64, do log de crash à correção testada

O que o StatusRivet faz

• Arquivosread_file, write_file, append_file, edit_file, delete_file, make_dir, move_file, copy_file, list_dir, grep e glob funcionam dentro da pasta de trabalho do chat, e um contador mostra os arquivos criados, editados e lidos.
• Shellexecuta builds, linters, testes e o modo de linha de comando do seu depurador no Windows, no WSL ou via SSH para um servidor que você possui; o sucesso é avaliado pelo código de saída real, e comandos perigosos são bloqueados.
• Webweb_search encontra páginas e http_get lê uma única página de documentação oficial, por exemplo, para consultar o significado de um código de exceção antes de agir.
• Capturas de tela e imagenso ocr lê texto de uma captura de tela salva, como uma caixa de diálogo de erro, e o gen_image salva arquivos de imagem reais.
• Orquestraçãotask executa sub-agentes em paralelo, run_on_model envia uma etapa crítica para um modelo maior, e skill mantém playbooks reutilizáveis, incluindo controle de versão.
• Modos de aprovaçãoAuto-run age imediatamente, Ask first pausa antes de ações que alteram algo, e Plan only escreve um plano e não executa nada.
• Cronexecuta um prompt em um agendamento, por exemplo, uma execução de teste em uma máquina de laboratório, e o resultado aparece no chat como qualquer outra ação, com os mesmos cartões e a mesma saída.
• Modelosum provedor de IA na nuvem por meio de um endpoint de API padrão, um modelo no seu PC ou o modelo integrado; o botão Test verifica um endpoint e mostra seu tempo de resposta e janela de contexto.

Quatro tarefas de depuração, passo a passo

Ler uma stack de chamadas de crash

Tarefa: seu aplicativo próprio crashed em uma máquina de teste e você tem uma stack de chamadas que seu depurador x64 salvou como texto. read_file carrega stack.txt, e grep procura o código de exceção no log, por exemplo 0xC0000005 para uma violação de acesso. O agente então lista os frames principais da thread falha e abre o arquivo de código-fonte que corresponde ao primeiro frame. Cada ação aparece no chat como um cartão, e você pode expandir um cartão para ler a saída completa. Se um boot bsod deixar uma entrada de erro 41 no log de eventos, o dump escrito em torno desse tempo, se houver, contém o estado necessário. Comece pelo topo. Leia os frames você mesmo, porque o agente trabalha a partir de saída de texto, então aceite ou rejeite o diff proposto no modo Ask first.

Corrigir um estouro de pilha

Tarefa: o log mostra 0xC00000FD, o código de exceção para estouro de pilha, e você quer a função que recursou. grep pesquisa seu código-fonte pelo nome da função dos frames superiores, e read_file abre para que o agente possa ver como a recursão termina. edit_file propõe um diff mínimo, por exemplo, uma condição de parada ausente, e mostra exatamente quais linhas mudam. Shell então executa seu comando de build e seu comando de teste, e cada cartão relata o código de saída real. Um bsod com um código de parada de gerenciamento de memória é uma falha diferente, mas o método é o mesmo: encontre a exceção, leia a stack, teste uma alteração por vez. Mantenha cada alteração pequena. Revise o diff e o resultado do teste antes de manter qualquer coisa, e execute o teste mais uma vez após a edição final.

Verificar a configuração de depuração JIT

Tarefa: antes de confiar em um depurador no momento do crash, verifique o valor da depuração JIT em uma máquina de teste. JIT significa just-in-time: o Windows inicia um depurador automaticamente quando um aplicativo crasha, e é uma configuração do sistema. Shell executa o comando que você dá a ele para ler o valor atual, e write_file salva esse valor em settings-before.txt, para que o valor antigo seja gravado. Altere apenas em uma máquina de teste, nunca no seu PC diário, e restaure o valor salvo depois. No modo Ask first, o agente pausa antes de cada ação que altera algo, para que você aprove a alteração e a restauração separadamente. Anote o valor. Leia o arquivo salvo antes de começar, e leia-o novamente antes de restaurar o valor.

Depurar um driver em um alvo de laboratório

Tarefa: um driver que você escreveu crasha um alvo de teste e você precisa da função falha. Trabalho em nível de kernel normalmente precisa de duas máquinas ou uma máquina virtual, uma executando o depurador e outra como alvo de teste, vinculadas por uma conexão de depuração, e o alvo permanece em um laboratório. Shell executa comandos via SSH em uma máquina de laboratório que você possui, read_file lê o texto que o depurador salvou, e grep faz match do nome do módulo contra seu código-fonte. Em um computador novo, uma violação de dpc watchdog bsod pode vir de um driver que você está escrevendo, então a stack da thread travada é a primeira coisa a ser lida. Mantenha-o em um laboratório. Você revisa cada descoberta antes de alterar uma linha, e executa o teste no alvo novamente depois.