Instrucciones de depuración
Actualización: noviembre 2007
Las instrucciones siguientes proporcionan varias técnicas para depurar código.
Se requiere
Obtenga información sobre cómo utilizar las herramientas de depuración.
Debe entender y dominar las herramientas de depuración. Para obtener más información, vea Depurar en Visual Studio.
Conozca dónde se almacenan los símbolos.
Es preciso guardar símbolos para cada producto en los servidores de símbolos. Lo único que se necesita es saber dónde encontrar estos servidores. Para obtener más información, vea "How to Use the Microsoft Symbol Server" en MSDN Library.
Estudie y resuelva los errores que provocan caídas de los procesos.
Para los usuarios, una aplicación que deja de responder (se cae) es tan grave como un bloqueo. En ambos casos, los usuarios pierden su trabajo y deben volver a empezar. Sin embargo, se consideraba que las caídas eran más difíciles de estudiar y resolver. Esto ya no sucede en un elevado porcentaje de caídas de procesos Utilice las herramientas y técnicas más recientes para resolver estos problemas. Para obtener más información, vea "How to Troubleshoot Program Faults with Dr. Watson" en MSDN Library.
Sepa cómo depurar un minivolcado.
La mayoría de los evaluadores y clientes provocarán bloqueos en el código sin la ventaja de disponer de un depurador asociado. Si no se puede reproducir con facilidad a problema, lo único que tendrá a su disposición es un minivolcado. Aprender a depurar utilizando un minivolcado es esencial. Para obtener más información, vea "Minidump Files" en MSDN Library.
Conozca cómo recuperar una pila dañada.
Recuperar una pila dañada es complejo, pero fundamental, porque existe gran cantidad de errores reales que tienen pilas que parecen incomprensibles. Para obtener más información, vea "Troubleshooting Common Problems with Applications: Debugging in the Real World" en MSDN Library.
Se debe evitar
Suponer que las pruebas encontrarán todos los errores.
Una prueba nunca puede encontrar todos los errores. No es posible. El código es demasiado complejo. Aunque las pruebas encontrasen todos los errores, nunca tendría tiempo para corregirlos todos. Lo correcto es diseñar el producto para evitar que éste contenga errores desde el principio. De este modo se evita el problema de corregirlos después. Debe asumir la responsabilidad por la calidad de su código. El equipo de pruebas se limita a comprobar la calidad de su código. No dependa de los evaluadores para que solucionen lo que se ha hecho mal.
Se recomienda
Aprenda a depurar aplicaciones multiproceso.
Al introducir subprocesos en un programa se pueden provocar nuevos errores. Todo lo que se hace en un entorno de un solo subproceso para ayudar a mejorar la depuración de las aplicaciones cobra mayor importancia a medida que aumenta el número de subprocesos. Por ejemplo, es posible que el error no se detecte siempre en el punto donde se produce. Con frecuencia se detecta después, posiblemente en otro subproceso. En estas situaciones, no es posible siquiera retroceder por la pila de llamadas para encontrar el problema, puesto que el error se encuentra en otro subproceso y, por consiguiente, en otra pila. Si toma todas las medidas activas posibles contribuirá a mejorar el proceso de depuración en general.
Aprenda a realizar depuraciones remotas.
La depuración remota tiene lugar cuando se desea depurar un problema que se produce en otro equipo mientras se trabaja en el propio. Con frecuencia, los desarrolladores recurren a esta técnica cuando un segmento de código se ejecuta correctamente en su propio equipo pero provoca bloqueos en otro sistema. Puede ser conveniente depurarlo remotamente en el otro sistema, sin tener que sentarse delante del otro equipo. Para obtener más información, vea Instalación de la depuración remota.
Aprenda a depurar en servidores activos.
Los procedimientos de depuración son diferentes cuando se intenta depurar el código en un servidor activo mientras los clientes teniendo acceso a él. Esto resulta cada vez más frecuente, a medida que se escribe cada vez más código para el Web. Para obtener más información, vea "Troubleshooting Common Problems with Applications: Debugging in the Real World" en MSDN Library.
Marque como comentarios todas las correcciones de errores.
Cuando corrija un error, incluya en el código el número de versión, el identificador del error y su alias. Si alguien examina después el código y tiene alguna duda sobre la corrección, podrá ponerse en contacto para obtener información.
Revise todas las correcciones de errores.
Debe revisar todas las correcciones del código. Consiga que al menos una persona examine el código, una revisión entre compañeros.
Compruebe las correcciones de errores sutiles antes de proteger el código.
Evite corregir dos veces el mismo error. Utilice una generación para comprobar que la corrección es correcta, sobre todo para los errores sutiles.
Utilice un documento de lanzamiento de prueba para informar de todas las correcciones de errores.
Coordínese con el equipo de pruebas documentando todas las correcciones de errores en un documento de lanzamiento de prueba y enviándolo al equipo de pruebas en un mensaje de correo electrónico.
Utilice el servidor de símbolos para indizar y almacenar los símbolos del producto.
Al permitir que el servidor de símbolos indice y almacene los símbolos del producto, facilita y agiliza la depuración desde cualquier sistema, incluso desde los sistemas del cliente.
No se recomienda
Corregir los errores de otras personas sin informarlas de ello.
Es una práctica magnífica investigar e intentar corregir los errores de otras personas. Se consigue conocer mejor el código y se respalda el trabajo de los demás. Lo único que no se debe hacer es proteger la corrección sin comunicarle la corrección al propietario del código.
Resolver un error como "No reproducible" sin probar la misma versión en el mismo entorno.
Debe deshacer hasta la versión del producto donde se encontró el error. No dé por hecho que si la interrupción no se produce en la versión actual del producto, significa que se ha corregido el error. Podría no ser verdad. El código podría haber cambiado de modo que ahora el error quede oculto. Si investiga un error hasta que lo ve producirse, podría encontrar realmente la causa original del problema y solucionarla de modo que no se vuelva a producir ese error en ningún equipo.
Vea también
Conceptos
Instrucciones para escribir código seguro