x64-debugger taken: van crashlog naar geteste fix

Wat StatusRivet doet

• Bestandenread_file, write_file, append_file, edit_file, delete_file, make_dir, move_file, copy_file, list_dir, grep en glob werken binnen de werkmap van de chat, en een teller toont het aantal bestanden dat is gemaakt, bewerkt en gelezen.
• Shellvoert builds, linters, tests en de command-line-modus van je debugger uit op Windows, in WSL of via SSH naar een server die je eigendom is; succes wordt beoordeeld op basis van de echte exitcode, en gevaarlijke commando's zijn geblokkeerd.
• Webweb_search vindt pagina's en http_get leest één officiële documentatiepagina, bijvoorbeeld om op te zoeken wat een uitzonderingscode betekent voordat je actie onderneemt.
• Screenshots en afbeeldingenocr leest tekst uit een opgeslagen screenshot, zoals een foutmelding, en gen_image slaat echte afbeeldingsbestanden op.
• Orkestratietask voert parallelle sub-agents uit, run_on_model stuurt een harde stap naar een groter model, en skill houdt herbruikbare playbooks bij, inclusief versiebeheer.
• GoedkeuringsmodiAuto-run voert direct uit, Ask first pauzeert voordat acties iets wijzigen, en Plan only schrijft een plan en voert niets uit.
• Cronvoert een prompt uit op een schema, bijvoorbeeld een testrun op een labmachine, en het resultaat verschijnt in de chat als elke andere actie, met dezelfde kaarten en dezelfde uitvoer.
• Modelleneen cloud-AI-aanbieder via een standaard API-endpoint, een model op je pc, of het ingebouwde model; de knop Test controleert een endpoint en toont de responstijd en contextvenster.

Vier debuggingstaken, stap voor stap

Een crashcallstack lezen

Taak: je eigen app is gecrashed op een testmachine en je hebt een callstack die je x64-debugger als tekst heeft opgeslagen. read_file laadt stack.txt, en grep zoekt naar de uitzonderingscode in de log, bijvoorbeeld 0xC0000005 voor een access violation. De agent somt vervolgens de bovenste frames van de foutieve thread op en opent het bronbestand dat overeenkomt met het eerste frame. Elke actie verschijnt in de chat als een kaart, en je kunt een kaart uitklappen om de volledige uitvoer te lezen. Als een boot-bsod een kernelfout 41-entry achterlaat in het gebeurtenislogboek, bevat de dump die rond die tijd is geschreven, indien aanwezig, de staat die je nodig hebt. Begin bovenaan. Lees de frames zelf, omdat de agent werkt op basis van tekstuitvoer, en accepteer of wijs de voorgestelde diff af in Ask first-modus.

Een stack overflow oplossen

Taak: de log toont 0xC00000FD, de uitzonderingscode voor een stack overflow, en je wilt de functie vinden die heeft gerecurseerd. grep doorzoekt je broncode op de functienaam uit de bovenste frames, en read_file opent deze zodat de agent kan zien hoe de recursie eindigt. edit_file stelt een minimale diff voor, bijvoorbeeld een ontbrekende stopvoorwaarde, en toont precies welke regels veranderen. Shell voert vervolgens je build-commando en je testcommando uit, en elke kaart rapporteert de echte exitcode. Een bsod met een memory management stop code is een andere fout, maar de methode is hetzelfde: vind de uitzondering, lees de stack, test één wijziging tegelijk. Houd elke wijziging klein. Beoordeel de diff en het testresultaat voordat je iets bewaart, en voer de test nog één keer uit na de laatste bewerking.

De JIT-debugginginstelling controleren

Taak: voordat je vertrouwt op een debugger tijdens een crash, controleer je de JIT-debuggingwaarde op een testmachine. JIT betekent just-in-time: Windows start automatisch een debugger wanneer een applicatie crasht, en dit is een systeeminstelling. Shell voert het commando uit dat je hem geeft om de huidige waarde te lezen, en write_file slaat die waarde op in settings-before.txt, zodat de oude waarde wordt vastgelegd. Wijzig deze alleen op een testmachine, nooit op je dagelijkse pc, en herstel de opgeslagen waarde daarna. In Ask first-modus pauzeert de agent voordat elke actie iets wijzigt, zodat je de wijziging en de herstelactie apart goedkeurt. Schrijf de waarde op. Lees het opgeslagen bestand voordat je begint, en lees het opnieuw voordat je de waarde herstelt.

Een driver debuggen op een labdoel

Taak: een driver die je hebt geschreven crasht een testdoel en je hebt de foutieve functie nodig. Werk op kernelniveau vereist normaal gesproken twee machines of een virtuele machine, één die de debugger uitvoert en één als testdoel, verbonden via een debugverbinding, en het doel blijft in een lab. Shell voert commando's uit via SSH op een labmachine die je eigendom is, read_file leest de tekst die de debugger heeft opgeslagen, en grep matcht de modusnaam tegen je broncode. Op een nieuwe computer kan een dpc watchdog violation-bsod komen van een driver die je schrijft, dus de stack van de vastgelopen thread is het eerste dat je moet lezen. Houd het in een lab. Je beoordeelt elke bevinding voordat je een regel wijzigt, en je voert de test daarna opnieuw uit op het doel.