O sesiune de debugger Windows la distanță atașează un debugger de pe o mașină la un program de pe alta, prin rețea, și este destinată exclusiv mașinilor tale de laborator. Simbolurile vin primele. Numește o mașină gazdă și una țintă. Compilă programul cu simboluri de depanare și păstrează fișierul PDB care corespunde exact acelei compilări, deoarece un PDB incorect returnează nume de funcții greșite, iar un stack fără simboluri afișează doar adrese. Instalează StatusRivet pe gazdă, unde lucrezi, și rezervă ținta doar pentru programul de testat. Notează orice setare modificată pe oricare dintre mașini, astfel încât să o poți restaura ulterior. Reproduce defectul cu cel mai mic input posibil, deoarece un caz scurt produce un stack scurt și o diferență mai ușor de analizat. Verifică că gazda și ținta se pot conecta reciproc înainte să ceri agentului să facă ceva, deoarece o conexiune eșuată seamănă cu un debugger eșuat.
Alege folderul cu sursele și fișierele de compilare ca folder de lucru al chat-ului, deoarece instrumentele de fișiere citesc și editează doar în interiorul lui. Pune și stack-ul salvat și notele acolo, astfel încât întregul caz să fie într-un singur loc și agentul să poată citi totul.
Ask first întrerupe execuția înainte de acțiunile care modifică ceva, astfel încât să poți citi fiecare înainte să ruleze. Folosește Plan only când vrei să vezi pașii mai întâi și să nu rulezi nimic. Un plan supraviețuiește unei reporniri, astfel încât să te poți întoarce la el mai târziu.
Numește programul, mașina gazdă, mașina țintă și simptomul, și spune că mașinile îți aparțin. Oferă detaliile de conexiune din notele tale de laborator și nu ghici niciuna dintre ele. Specifică ce versiune rulează pe țintă și cărui PDB îi aparține.
Citește diferența, recompilă cu comanda ta de compilare și rulează din nou comanda de test pe țintă. Păstrează notele despre ce s-a schimbat împreună cu lista de verificare și păstrează dump-ul vechi dacă noul test eșuează încă, astfel încât încercarea următoare să înceapă din dovezi și nu din memorie.
attach your debugger to the targetatașatsave the dump on the targetsalvatwrite the call stack to stack.txtsalvatstack.txtcitit0xC0000005 stack.txt1 potrivire# 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 changedO listă de verificare în text simplu pentru o sesiune de depanare între două mașini de laborator. Acoperă compilarea cu simboluri, atașarea, reproducerea defectului cu cel mai mic input, salvarea unui dump și a unui stack de apeluri, citirea cadrelor superioare și se încheie cu un rulaj de test după remediere, cu note despre ce s-a schimbat. Copiaz-o în folderul proiectului și editeaz-o pentru a se potrivi cu laboratorul tău. Copiaz-o și editeaz-o.
Sarcină: atașează de pe mașina gazdă la programul tău care rulează pe ținta de laborator. Atașează mai întâi. Deschide folderul proiectului în StatusRivet, comută la Ask first și descrie configurația. Shell execută modul linie de comandă al debuggerului tău cu detaliile de conexiune pe care i le dai, iar cardul arată dacă s-a atașat prin codul de ieșire real. Agentul nu inventează setări de conexiune, așa că preia gazda, ținta și portul din notele tale de laborator. Depanarea la distanță este pentru mașinile tale de laborator doar, niciodată pentru un calculator pe care nu îl deții. Citește cardul înainte de următorul pas. Dacă atașarea a eșuat, nu ar trebui să ruleze nimic altceva, și repari conexiunea mai întâi, apoi ceri din nou. Cardul păstrează și comanda exactă, astfel încât să o poți repeta mai târziu.
Sarcină: după ce ai reproducut defectul pe țintă cu cel mai mic input, salvează dovezile. Salvează ambele fișiere. Shell cere debuggerului tău să scrie un crash dump și să salveze stack-ul de apeluri al firului care a cauzat eroarea într-un fișier text, iar cardurile arată ambele rezultate. Un entry de debugger JIT Windows pe țintă pornește automat un debugger când o aplicație se defectează. Aceasta este o setare de sistem, așa că modific-o doar pe o mașină de test, notează valoarea anterioară și restaureaz-o ulterior. Pentru a găsi cauza unui crash de sistem dintr-un minidump, începe de la stack-ul de apeluri salvat. Aprobă fiecare pas în modul Ask first și păstrează ambele fișiere cu lista de verificare pentru următoarea persoană care citește cazul. Numește fișierele după versiunea de compilare, astfel încât nimeni să nu le confunde.
Sarcină: conectează cadrul superior la codul tău. Începe cu simbolurile. read_file deschide stack.txt, grep caută în proiect numele funcției și codul de excepție, cum ar fi 0xC0000005 pentru o violare de acces, iar read_file deschide fișierul sursă la acea linie. Cu PDB-ul corespunzător, stack-ul afișează nume de funcții, fișiere sursă și numere de linie, în timp ce fără el vezi doar adrese. O mașină blocată care se termină într-un BSOD cu o eroare de verificare a securității kernel este un caz exact pentru această rutină: dump, stack, sursă. Citește dovezile singur înainte ca agentul să editeze ceva, deoarece agentul lucrează din text și nu poate pași prin program pentru tine. Pentru pași, folosește debuggerul tău și spune agentului ce ai văzut.
Sarcină: transformă constatarea într-o modificare. edit_file propune o diferență minimă, de exemplu o verificare null lipsă sau un index greșit, și în modul Ask first agentul se oprește astfel încât să poți citi liniile modificate. Shell rulează apoi comanda ta de compilare, cu simboluri, și comanda ta de test, iar cardurile raportează codurile de ieșire reale. O eroare de corupție a heap-ului în modul kernel într-un driver pe care l-ai scris poate apărea mult după scrierea greșită, așa că verifică buffer-ele scrise mai devreme în stack, nu doar ultimul cadru. Un BSOD de excepție de stocare neașteptată pe ținta ta de laborator se gestionează în același mod. Acceptă diferența doar după ce testul trece și notează ce s-a schimbat. Testează înainte de a accepta. Dacă testul eșuează încă, păstrează noul stack și începe din nou bucla de la al doilea pas.
