Una sesión de depuración remota en Windows adjunta un depurador en una máquina a un programa en otra a través de la red, y pertenece exclusivamente a tus propias máquinas de laboratorio. Los símbolos son lo primero. Nombra una máquina como host y la otra como target. Compila el programa con símbolos de depuración y conserva el PDB coincidente para esa compilación exacta, porque un PDB incorrecto da nombres de función erróneos y una pila sin símbolos solo muestra direcciones. Instala StatusRivet en el host, donde trabajas, y mantén el target solo para el programa bajo prueba. Anota cualquier configuración que cambies en cualquiera de las máquinas para poder restaurarla después. Reproduce el fallo con la entrada más pequeña que encuentres, porque un caso corto produce una pila corta y una comparación más fácil. Verifica que el host y el target se puedan alcanzar antes de pedirle al agente que haga algo, ya que una conexión fallida parece un depurador fallido.
Elige la carpeta con tu código fuente y archivos de compilación como la carpeta de trabajo del chat, porque las herramientas de archivos solo leen y editan dentro de ella. Guarda también la pila y las notas allí, para que todo el caso esté en un solo lugar y el agente pueda leerlo todo.
Ask first hace una pausa antes de las acciones que cambian algo, para que puedas leer cada una antes de que se ejecute. Usa Plan only cuando quieras ver los pasos primero y no ejecutar nada. Un plan sobrevive a un reinicio, así que puedes volver a él más tarde.
Nombra el programa, la máquina host y la máquina target y el síntoma, y di que las máquinas son tuyas. Da los detalles de conexión de tus propias notas de laboratorio y no adivines ninguno. Di qué compilación se está ejecutando en el target y a qué PDB pertenece.
Lee la diferencia, recompila con tu comando de compilación y ejecuta tu comando de prueba de nuevo en el target. Guarda las notas de lo que cambió con la lista de verificación, y conserva el volcado antiguo si la nueva prueba sigue fallando, para que el siguiente intento comience desde la evidencia y no desde la memoria.
attach your debugger to the targetadjuntadosave the dump on the targetguardadowrite the call stack to stack.txtguardadostack.txtleído0xC0000005 stack.txt1 coincidencia# 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 changedUna lista de verificación en texto plano para una sesión de depuración entre dos máquinas de laboratorio. Cubre la compilación con símbolos, la adjunción, la reproducción del fallo con la entrada más pequeña, el guardado de un volcado y una pila de llamadas, la lectura de los marcos superiores, y termina con una ejecución de prueba después de la corrección, con notas de lo que cambió. Cópiala en la carpeta de tu proyecto y edítala para que coincida con tu propio laboratorio. Cópiala y edítala.
Tarea: adjúntate desde la máquina host a tu propio programa que se ejecuta en el target del laboratorio. Adjúntate primero. Abre la carpeta del proyecto en StatusRivet, cambia a Ask first y describe la configuración. Shell ejecuta el modo de línea de comandos de tu depurador con los detalles de conexión que le des, y la tarjeta muestra si se adjuntó a través del código de salida real. El agente no inventa configuraciones de conexión, así que toma el host, el target y el puerto de tus propias notas de laboratorio. La depuración remota es solo para tus máquinas de laboratorio, nunca para una computadora que no poseas. Lee la tarjeta antes del siguiente paso. Si la adjunción falló, no debería ejecutarse nada más, y corriges la conexión primero, luego vuelves a preguntar. La tarjeta también conserva el comando exacto, para que puedas repetirlo más tarde.
Tarea: después de reproducir el fallo en el target con la entrada más pequeña, guarda la evidencia. Guarda ambos archivos. Shell le pide a tu depurador que escriba un volcado de fallo y que guarde la pila de llamadas del hilo que falló en un archivo de texto, y las tarjetas muestran ambos resultados. Una entrada del depurador JIT de Windows en el target inicia un depurador automáticamente cuando una aplicación falla. Esa es una configuración del sistema, así que cámbiala solo en una máquina de prueba, anota el valor anterior y restáuralo después. Para encontrar la causa de un fallo del sistema desde un minidump, comienza desde la pila de llamadas guardada. Apruebas cada paso en modo Ask first, y conservas ambos archivos con la lista de verificación para la siguiente persona que lea el caso. Nombra los archivos según la compilación para que nadie los confunda.
Tarea: conecta el marco superior con tu código. Comienza con los símbolos. read_file abre stack.txt, grep busca en el proyecto el nombre de la función y el código de excepción, como 0xC0000005 para una violación de acceso, y read_file abre el archivo de código fuente en esa línea. Con el PDB coincidente, la pila muestra nombres de funciones, archivos de código fuente y números de línea, mientras que sin ella solo ves direcciones. Una máquina congelada que termina en un bsod con una verificación de seguridad del kernel es un caso para exactamente esta rutina: volcado, pila, código fuente. Lee la evidencia tú mismo antes de que el agente edite algo, porque el agente trabaja con texto y no puede hacer paso a paso el programa por ti. Para hacer paso a paso, usa tu propio depurador y dile al agente lo que viste.
Tarea: convierte el hallazgo en un cambio. edit_file propone una diferencia mínima, por ejemplo, una comprobación de nulo faltante o un índice incorrecto, y en modo Ask first el agente hace una pausa para que puedas leer las líneas cambiadas. Shell luego ejecuta tu comando de compilación, con símbolos, y tu comando de prueba, y las tarjetas informan los códigos de salida reales. Una corrupción de heap en modo kernel que causa un bsod en un controlador que escribiste puede aparecer mucho después de la escritura incorrecta, así que verifica los buffers escritos anteriormente en la pila, no solo el último marco. Una excepción de almacenamiento inesperada que causa un bsod en tu target de laboratorio se maneja de la misma manera. Acepta la diferencia solo después de que la prueba pase, y anota lo que cambió. Prueba antes de aceptar. Si la prueba sigue fallando, conserva la nueva pila y comienza el bucle de nuevo desde el segundo paso.
