Eine Remote-Debugger-Sitzung verbindet einen Debugger auf einem Rechner mit einem Programm auf einem anderen über das Netzwerk und gehört nur in Ihre eigenen Lab-Rechner. Symbole kommen zuerst. Nennen Sie einen Rechner Host und den anderen Target. Erstellen Sie das Programm mit Debug-Symbolen und bewahren Sie die passende PDB für diesen genauen Build auf, da eine falsche PDB falsche Funktionsnamen liefert und ein Stack ohne Symbole nur Adressen zeigt. Installieren Sie StatusRivet auf dem Host, wo Sie arbeiten, und halten Sie das Target auf das zu testende Programm beschränkt. Notieren Sie sich alle Änderungen an den Einstellungen beider Rechner, damit Sie sie später wiederherstellen können. Reproduzieren Sie den Absturz mit der kleinstmöglichen Eingabe, denn ein kurzer Fall erzeugt einen kurzen Stack und einen einfacheren Diff. Stellen Sie sicher, dass Host und Target sich erreichen können, bevor Sie den Agenten etwas tun lassen, denn eine fehlgeschlagene Verbindung sieht aus wie ein fehlgeschlagener Debugger.
Wählen Sie den Ordner mit Ihrem Quellcode und Ihren Build-Dateien als Arbeitsordner des Chats, denn die Datei-Tools lesen und bearbeiten nur innerhalb dieses Ordners. Legen Sie auch den gespeicherten Stack und die Notizen dort ab, damit der gesamte Fall an einem Ort liegt und der Agent alles lesen kann.
Ask first pausiert vor Aktionen, die etwas verändern, damit Sie jede lesen können, bevor sie ausgeführt wird. Nutzen Sie Plan only, wenn Sie zuerst die Schritte sehen und nichts ausführen möchten. Ein Plan überlebt einen Neustart, sodass Sie später daran anknüpfen können.
Nennen Sie das Programm, den Host und den Target-Rechner sowie das Symptom, und sagen Sie, dass die Rechner Ihnen gehören. Geben Sie die Verbindungsdetails aus Ihren Lab-Notizen an und raten Sie nicht. Nennen Sie den Build, der auf dem Target läuft, und die dazugehörige PDB.
Lesen Sie den Diff, erstellen Sie mit Ihrem Build-Befehl neu und führen Sie Ihren Testbefehl auf dem Target erneut aus. Führen Sie die Notizen zu den Änderungen mit der Checkliste, und bewahren Sie den alten Dump auf, falls der neue Test ebenfalls fehlschlägt, damit der nächste Versuch auf Evidenz und nicht auf Erinnerung aufbaut.
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 changedEine Checkliste im Klartext für eine Debugging-Sitzung zwischen zwei Lab-Rechnern. Sie deckt das Erstellen mit Symbolen, das Attachen, das Reproduzieren des Absturzes mit der kleinstmöglichen Eingabe, das Speichern eines Dumps und eines Call Stacks, das Lesen der Top-Frames und einen Testlauf nach dem Fix ab, mit Notizen zu den Änderungen. Kopieren Sie sie in Ihren Projektordner und passen Sie sie an Ihr Lab an. Kopieren und bearbeiten.
Aufgabe: Vom Host-Rechner an Ihr eigenes Programm attachen, das auf dem Lab-Target läuft. Attachen Sie zuerst. Öffnen Sie den Projektordner in StatusRivet, schalten Sie auf Ask first und beschreiben Sie die Einrichtung. Shell führt den Befehlszeilenmodus Ihres Debuggers mit den von Ihnen angegebenen Verbindungsdetails aus, und die Karte zeigt, ob der Attach über den echten Exit-Code gelangt ist. Der Agent erfindet keine Verbindungseinstellungen, also nehmen Sie Host, Target und Port aus Ihren Lab-Notizen. Remote-Debugging ist nur für Ihre eigenen Lab-Rechner gedacht, nie für einen Computer, den Sie nicht besitzen. Lesen Sie die Karte, bevor Sie zum nächsten Schritt übergehen. Wenn das Attach fehlgeschlagen ist, sollte nichts anderes laufen, und Sie beheben zuerst die Verbindung, dann fragen Sie erneut. Die Karte speichert auch den genauen Befehl, damit Sie ihn später wiederholen können.
Aufgabe: Nachdem Sie den Absturz auf dem Target mit der kleinstmöglichen Eingabe reproduziert haben, speichern Sie die Evidenz. Speichern Sie beide Dateien. Shell bittet Ihren Debugger, einen Crash-Dump zu schreiben und den Call Stack des fehlerhaften Threads in eine Textdatei zu speichern, und die Karten zeigen beide Ergebnisse. Ein Windows-JIT-Debugger-Eintrag auf dem Target startet automatisch einen Debugger, wenn eine Anwendung abstürzt. Das ist eine Systemeinstellung, also ändern Sie sie nur auf einer Testmaschine, notieren Sie den vorherigen Wert und stellen Sie ihn danach wieder her. Um die Ursache eines Systemabsturzes aus einem Minidump zu finden, beginnen Sie mit dem gespeicherten Call Stack. Sie genehmigen jeden Schritt im Ask first-Modus, und Sie behalten beide Dateien mit der Checkliste für die nächste Person, die den Fall liest. Benennen Sie die Dateien nach dem Build, damit niemand sie verwechselt.
Aufgabe: Den Top-Frame mit Ihrem Code verbinden. Beginnen Sie mit den Symbolen. read_file öffnet stack.txt, grep sucht im Projekt nach dem Funktionsnamen und dem Ausnahmecode, z. B. 0xC0000005 für eine Access Violation, und read_file öffnet die Quelldatei an dieser Zeile. Mit der passenden PDB zeigt der Stack Funktionsnamen, Quelldateien und Zeilennummern, ohne ihn sehen Sie nur Adressen. Ein einfrierender Rechner, der mit einem BSOD mit einem Kernel Security Check Failure endet, ist ein Fall genau für diese Routine: Dump, Stack, Source. Lesen Sie die Evidenz selbst, bevor der Agent etwas bearbeitet, denn der Agent arbeitet nur mit Text und kann nicht durch das Programm schrittweise gehen. Für das schrittweise Durchgehen nutzen Sie Ihren eigenen Debugger und sagen Sie dem Agenten, was Sie gesehen haben.
Aufgabe: Die Erkenntnis in eine Änderung umwandeln. edit_file schlägt einen minimalen Diff vor, z. B. eine fehlende Nullprüfung oder einen falschen Index, und im Ask first-Modus pausiert der Agent, damit Sie die geänderten Zeilen lesen können. Shell führt dann Ihren Build-Befehl, mit Symbolen, und Ihren Testbefehl aus, und die Karten melden die echten Exit-Codes. Ein Kernel-Mode-Heap-Corruption-BSOD in einem von Ihnen geschriebenen Treiber kann lange nach dem falschen Schreibzugriff auftreten, also prüfen Sie die früher geschriebenen Puffer im Stack, nicht nur den letzten Frame. Eine unerwartete Store Exception BSOD auf Ihrem Lab-Target wird auf die gleiche Weise behandelt. Akzeptieren Sie den Diff erst nach einem erfolgreichen Test, und notieren Sie sich, was sich geändert hat. Testen Sie vor der Annahme. Wenn der Test weiterhin fehlschlägt, behalten Sie den neuen Stack und beginnen Sie den Loop erneut ab dem zweiten Schritt.
