Een remote Windows-debuggersessie koppelt een debugger op de ene machine aan een programma op de andere via het netwerk, en dit hoort thuis tussen je eigen labmachines. Symbolen komen eerst. Noem de ene machine de host en de andere het target. Bouw het programma met debugsymbolen en bewaar de bijpassende PDB voor die exacte build, want een niet-bijpassende PDB geeft verkeerde functienamen en een stack zonder symbolen toont alleen adressen. Installeer StatusRivet op de host, waar je werkt, en houd het target voor het te testen programma en verder niets. Noteer elke instelling die je op de ene of andere machine wijzigt, zodat je deze daarna kunt herstellen. Reproduceer de crash met de kleinste invoer die je kunt vinden, omdat een kort geval een korte stack oplevert en een makkelijker verschil. Controleer of de host en het target elkaar kunnen bereiken voordat je de agent iets laat doen, omdat een mislukte verbinding eruitziet als een mislukte debugger.
Kies de map met je broncode en buildbestanden als de werkmap van de chat, omdat de bestandsinstrumenten alleen binnen die map lezen en bewerken. Zet de opgeslagen stack en notities daar ook neer, zodat het hele geval op één plek staat en de agent alles kan lezen.
Ask first pauzeert voordat acties worden uitgevoerd die iets wijzigen, zodat je elke actie kunt lezen voordat deze wordt uitgevoerd. Gebruik Plan only wanneer je de stappen eerst wilt zien en niets wilt uitvoeren. Een plan overleeft een herstart, dus je kunt er later weer naar terugkeren.
Noem het programma, de host- en targetmachine en het symptoom, en zeg dat de machines van jou zijn. Geef de verbindinggegevens uit je eigen labnotities en raad niet over een enkele. Noem welke build op het target draait en welke PDB erbij hoort.
Lees het verschil, bouw opnieuw met je buildopdracht en voer je testopdracht opnieuw uit op het target. Bewaar de notities van wat er is gewijzigd bij de checklist, en bewaar de oude dump als de nieuwe test nog steeds faalt, zodat de volgende poging begint vanuit bewijs en niet vanuit geheugen.
attach your debugger to the targetgekoppeldsave the dump on the targetopgeslagenwrite the call stack to stack.txtopgeslagenstack.txtgelezen0xC0000005 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 changedEen platte tekstcontrolelijst voor één debugsessie tussen twee labmachines. Het behandelt het bouwen met symbolen, koppelen, reproduceren van de crash met de kleinste invoer, het opslaan van een dump en een call stack, het lezen van de bovenste frames, en eindigt met een testrun na de fix, met notities van wat er is gewijzigd. Kopieer deze naar je projectmap en pas deze aan op je eigen lab. Kopieer en bewerk.
Taak: koppel vanaf de hostmachine aan je eigen programma dat op het labtarget draait. Koppel eerst. Open de projectmap in StatusRivet, schakel over naar Ask first en beschrijf de opstelling. Shell voert de command-line-modus van je debugger uit met de verbindinggegevens die je geeft, en de kaart toont of het koppelen is gelukt via de echte exitcode. De agent verzint geen verbindinginstellingen, dus haal de host, het target en de poort uit je eigen labnotities. Remote debugging is alleen voor je eigen labmachines, nooit voor een computer die je niet bezit. Lees de kaart voordat je naar de volgende stap gaat. Als het koppelen is mislukt, moet er niets anders meer draaien, en los je eerst de verbinding op, en vraag je het daarna opnieuw. De kaart bewaart ook de exacte opdracht, zodat je deze later kunt herhalen.
Taak: nadat je de crash op het target hebt gereproduceerd met de kleinste invoer, sla het bewijsmateriaal op. Sla beide bestanden op. Shell vraagt je debugger om een crashdump te schrijven en de call stack van de foutieve thread op te slaan in een tekstbestand, en de kaarten tonen beide resultaten. Een Windows JIT-debuggervermelding op het target start een debugger automatisch wanneer een applicatie crasht. Dit is een systeeminstelling, dus wijzig deze alleen op een testmachine, noteer de vorige waarde en herstel deze daarna. Om de oorzaak van een systeemcrash uit een minidump te vinden, begin je met de opgeslagen call stack. Je keurt elke stap goed in Ask first-modus, en je bewaart beide bestanden met de checklist voor de volgende persoon die het geval leest. Noem de bestanden naar de build, zodat niemand ze verwisselt.
Taak: koppel het bovenste frame aan je code. Begin met symbolen. read_file opent stack.txt, grep doorzoekt het project op de functienaam en op de uitzonderingscode, zoals 0xC0000005 voor een access violation, en read_file opent het bronbestand op die regel. Met de bijpassende PDB toont de stack functienamen, bronbestanden en regelnummers, terwijl je zonder PDB alleen adressen ziet. Een bevriezende machine die eindigt in een BSOD met een kernel security check failure is een geval voor precies deze routine: dump, stack, bron. Lees het bewijsmateriaal zelf voordat de agent iets bewerkt, omdat de agent werkt vanuit tekst en niet door het programma kan stappen. Gebruik voor stappen je eigen debugger en vertel de agent wat je zag.
Taak: zet de bevinding om in een wijziging. edit_file stelt een minimale diff voor, bijvoorbeeld een ontbrekende null-check of een verkeerde index, en in Ask first-modus pauzeert de agent zodat je de gewijzigde regels kunt lezen. Shell voert vervolgens je buildopdracht uit, met symbolen, en je testopdracht, en de kaarten rapporteren de echte exitcodes. Een kernel mode heap corruption BSOD in een driver die je hebt geschreven kan lang na de slechte write verschijnen, dus controleer de buffers die eerder zijn geschreven in de stack, niet alleen het laatste frame. Een onverwachte store exception BSOD op je labtarget wordt op dezelfde manier afgehandeld. Accepteer de diff pas nadat de test slaagt, en noteer wat er is gewijzigd. Test voordat je accepteert. Als de test nog steeds faalt, bewaar je de nieuwe stack en begin je de lus opnieuw vanaf de tweede stap.
