Une session de débogage Windows distant attache un débogueur sur une machine à un programme sur une autre via un réseau, et cela se fait exclusivement entre vos propres machines de labo. Les symboles arrivent en premier. Nommez une machine hôte et l'autre cible. Compilez le programme avec les symboles de débogage et conservez le PDB correspondant à cette compilation exacte, car un PDB inexact donne des noms de fonctions erronés et une pile sans symboles n'affiche que des adresses. Installez StatusRivet sur l'hôte, là où vous travaillez, et gardez la cible dédiée au programme testé sans autre distraction. Notez tout paramètre modifié sur l'une ou l'autre machine afin de pouvoir le restaurer par la suite. Reproduisez le plantage avec le plus petit cas d'entrée possible, car un cas court produit une pile courte et un diff plus facile à comparer. Vérifiez que l'hôte et la cible se voient mutuellement avant de demander à l'agent d'agir, car une connexion échouée ressemble à un débogueur défaillant.
Choisissez le dossier contenant vos sources et fichiers de build comme dossier de travail du chat, car les outils de fichiers lisent et modifient uniquement à l'intérieur. Placez-y aussi la pile sauvegardée et les notes, afin que tout le cas soit regroupé en un seul endroit et que l'agent puisse tout lire.
Ask first met en pause avant les actions qui modifient quelque chose, afin que vous puissiez lire chacune avant son exécution. Utilisez Plan only lorsque vous souhaitez voir les étapes d'abord et ne rien exécuter. Un plan survit à un redémarrage, vous pouvez donc y revenir plus tard.
Nommez le programme, la machine hôte et la cible, ainsi que le symptôme, et précisez que les machines vous appartiennent. Fournissez les détails de connexion tirés de vos propres notes de labo et ne devinez aucun paramètre. Indiquez quelle build est exécutée sur la cible et quel PDB lui correspond.
Lisez le diff, recompilez avec votre commande de build et relancez votre commande de test sur la cible. Conservez les notes des modifications avec la liste de contrôle, et gardez l'ancien dump si le nouveau test échoue toujours, afin que la prochaine tentative parte des preuves et non de la mémoire.
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 changedUne liste de contrôle en texte brut pour une session de débogage entre deux machines de labo. Elle couvre la compilation avec symboles, l'attachement, la reproduction du plantage avec le plus petit cas, la sauvegarde d'un dump et d'une pile d'appels, la lecture des frames supérieures, et se termine par un test après la correction, avec les notes des modifications. Copiez-la dans votre dossier de projet et modifiez-la pour correspondre à votre labo. Copiez-la et modifiez-la.
Tâche : attachez depuis la machine hôte à votre propre programme s'exécutant sur la cible de labo. Attachez d'abord. Ouvrez le dossier du projet dans StatusRivet, passez en mode Ask first et décrivez la configuration. Shell exécute le mode ligne de commande de votre débogueur avec les détails de connexion que vous lui fournissez, et la carte indique s'il s'est attaché via le code de sortie réel. L'agent n'invente pas les paramètres de connexion, donc prenez l'hôte, la cible et le port depuis vos propres notes de labo. Le débogage distant est réservé à vos propres machines de labo, jamais pour un ordinateur que vous ne possédez pas. Lisez la carte avant l'étape suivante. Si l'attachement a échoué, rien d'autre ne devrait s'exécuter, et vous corrigez la connexion d'abord, puis redemandez. La carte conserve aussi la commande exacte, afin que vous puissiez la répéter plus tard.
Tâche : après avoir reproduit le plantage sur la cible avec le plus petit cas, sauvegardez les preuves. Sauvegardez les deux fichiers. Shell demande à votre débogueur d'écrire un dump de plantage et de sauvegarder la pile d'appels du thread fautif dans un fichier texte, et les cartes montrent les deux résultats. Une entrée du débogueur JIT Windows sur la cible lance un débogueur automatiquement lorsqu'une application plante. Il s'agit d'un paramètre système, modifiez-le uniquement sur une machine de test, notez la valeur précédente et restaurez-la par la suite. Pour trouver la cause d'un plantage système à partir d'un minidump, partez de la pile d'appels sauvegardée. Vous approuvez chaque étape en mode Ask first, et vous conservez les deux fichiers avec la liste de contrôle pour la prochaine personne qui lira le cas. Nommez les fichiers selon la build pour éviter toute confusion.
Tâche : reliez la frame supérieure à votre code. Commencez par les symboles. read_file ouvre stack.txt, grep recherche le nom de la fonction et le code d'exception dans le projet, comme 0xC0000005 pour une violation d'accès, et read_file ouvre le fichier source à cette ligne. Avec le PDB correspondant, la pile affiche les noms de fonctions, les fichiers source et les numéros de ligne, tandis que sans elle, vous ne voyez que des adresses. Une machine gelée qui se termine par un bsod avec un échec de vérification de sécurité du noyau est un cas pour exactement cette routine : dump, pile, source. Lisez les preuves vous-même avant que l'agent ne modifie quoi que ce soit, car l'agent travaille à partir de texte et ne peut pas faire de pas à pas dans le programme pour vous. Pour les pas à pas, utilisez votre propre débogueur et indiquez à l'agent ce que vous avez vu.
Tâche : transformez la découverte en modification. edit_file propose un diff minimal, par exemple une vérification null manquante ou un index incorrect, et en mode Ask first, l'agent met en pause afin que vous puissiez lire les lignes modifiées. Shell exécute ensuite votre commande de build, avec les symboles, et votre commande de test, et les cartes rapportent les codes de sortie réels. Une corruption de heap en mode noyau causant un bsod dans un pilote que vous avez écrit peut apparaître longtemps après l'écriture incorrecte, vérifiez donc les tampons écrits plus tôt dans la pile, pas seulement la dernière frame. Une exception de magasin inattendue causant un bsod sur votre cible de labo est gérée de la même manière. Acceptez le diff uniquement après que le test passe, et notez ce qui a changé. Testez avant d'accepter. Si le test échoue toujours, conservez la nouvelle pile et recommencez la boucle à partir de la deuxième étape.
