Una sessione di debug remoto Windows collega un debugger su una macchina a un programma su un'altra tramite rete ed è riservata alle tue macchine di laboratorio. I simboli vengono prima. Chiamare una macchina host e l'altra target. Compila il programma con i simboli di debug e conserva il PDB corrispondente a quella specifica build, perché un PDB non corrispondente fornisce nomi di funzione errati e una stack senza simboli mostra solo indirizzi. Installa StatusRivet sull'host, dove lavori, e mantieni il target dedicato al programma in test e nient'altro. Annota qualsiasi impostazione che modifichi su entrambe le macchine in modo da poterla ripristinare in seguito. Riproduci il crash con il minimo input possibile, perché un caso breve produce una stack corta e un diff più facile. Verifica che l'host e il target possano raggiungere se stessi prima di chiedere all'agente di fare qualsiasi cosa, poiché un fallimento del collegamento sembra un fallimento del debugger.
Scegli la cartella con il tuo codice sorgente e i file di build come cartella di lavoro della chat, perché gli strumenti file leggono e modificano solo al suo interno. Metti anche la stack salvata e le note lì, così tutto il caso si trova in un unico posto e l'agente può leggerlo tutto.
Ask first mette in pausa prima delle azioni che modificano qualcosa, così puoi leggere ciascuna prima che venga eseguita. Usa Plan only quando vuoi vedere i passaggi prima e non eseguire nulla. Un piano sopravvive a un riavvio, così puoi tornarci più tardi.
Nomina il programma, la macchina host e la macchina target e il sintomo, e dì che le macchine sono tue. Fornisci i dettagli di connessione dalle tue note del laboratorio e non indovinare nessuno di essi. Dì quale build è in esecuzione sul target e a quale PDB appartiene.
Leggi il diff, ricompila con il tuo comando di build ed esegui di nuovo il tuo comando di test sul target. Tieni le note di cosa è cambiato con la checklist, e mantieni il vecchio dump se il nuovo test fallisce ancora, così il prossimo tentativo parte da evidenze e non dalla memoria.
attach your debugger to the targetattachedsave the dump on the targetsavedwrite the call stack to stack.txtsavedstack.txtread0xC0000005 stack.txt1 match# 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 changedUna checklist in testo semplice per una sessione di debug tra due macchine di laboratorio. Copre la compilazione con simboli, l'attach, la riproduzione del crash con il minimo input, il salvataggio di un dump e una call stack, la lettura dei frame superiori e termina con un'esecuzione di test dopo la correzione, con note di cosa è cambiato. Copiala nella cartella del progetto e modificala in base al tuo laboratorio. Copiala e modificala.
Attività: attach dalla macchina host al tuo programma in esecuzione sul target di laboratorio. Attach prima. Apri la cartella del progetto in StatusRivet, passa a Ask first e descrivi la configurazione. Shell esegue la modalità a riga di comando del tuo debugger con i dettagli di connessione che gli fornisci, e la scheda mostra se ha attaccato tramite il codice di uscita reale. L'agente non inventa le impostazioni di connessione, quindi prendi l'host, il target e la porta dalle tue note del laboratorio. Il debug remoto è solo per le tue macchine di laboratorio, mai per un computer che non possiedi. Leggi la scheda prima del passaggio successivo. Se l'attach è fallito, non dovrebbe eseguire nient'altro, e risolvi prima la connessione, poi chiedi di nuovo. La scheda mantiene anche il comando esatto, così puoi ripeterlo più tardi.
Attività: dopo aver riprodotto il crash sul target con il minimo input, salva le evidenze. Salva entrambi i file. Shell chiede al tuo debugger di scrivere un dump di crash e di salvare la call stack del thread che ha causato il crash in un file di testo, e le schede mostrano entrambi i risultati. Un'entry del debugger jit di windows sul target avvia un debugger automaticamente quando un'applicazione crasha. Questa è un'impostazione di sistema, quindi modificala solo su una macchina di test, annota il valore precedente e ripristinalo dopo. Per trovare la causa di un crash di sistema da un minidump, parti dalla call stack salvata. Approvi ogni passaggio in modalità Ask first, e mantieni entrambi i file con la checklist per la prossima persona che legge il caso. Nomina i file in base alla build così nessuno li confonde.
Attività: collega il frame superiore al tuo codice. Inizia con i simboli. read_file apre stack.txt, grep cerca il progetto per il nome della funzione e per il codice di eccezione, come 0xC0000005 per una violazione di accesso, e read_file apre il file di codice sorgente a quella riga. Con il PDB corrispondente la stack mostra nomi di funzione, file di codice sorgente e numeri di riga, mentre senza la vedi solo gli indirizzi. Una macchina bloccata che termina in un bsod con un controllo di sicurezza del kernel è un caso per esattamente questa routine: dump, stack, codice sorgente. Leggi le evidenze da solo prima che l'agente modifichi qualcosa, perché l'agente lavora da testo e non può eseguire il passo passo del programma per te. Per il passo passo, usa il tuo debugger e dì all'agente cosa hai visto.
Attività: trasforma il risultato in una modifica. edit_file propone un diff minimo, ad esempio un controllo null mancante o un indice errato, e in modalità Ask first l'agente mette in pausa così puoi leggere le righe modificate. Shell esegue poi il tuo comando di build, con i simboli, e il tuo comando di test, e le schede riportano i codici di uscita reali. Una corruzione del heap in modalità kernel bsod in un driver che hai scritto può apparire molto tempo dopo la scrittura errata, quindi controlla i buffer scritti prima nella stack, non solo l'ultimo frame. Un'eccezione di archiviazione imprevista bsod sul tuo target di laboratorio viene gestita allo stesso modo. Accetta il diff solo dopo che il test passa, e annota cosa è cambiato. Testa prima di accettare. Se il test fallisce ancora, mantieni la nuova stack e ricomincia il ciclo dal secondo passaggio.
