Diagnóstico de interbloqueos en el programa Win32

Question

¿Cuáles son los pasos y técnicas para depurar un aparente bloqueo debido a un punto muerto en un proceso de producción de Win32?Escuché que WinDbg se puede usar para este propósito, pero ¿podría brindarnos sugerencias claras sobre cómo lograrlo?

Answer 1

Este correo debería ayudarlo a comenzar con las diversas opciones. Consulte las publicaciones etiquetadas con Depuración.

Otro artículo útil sobre depuración de puntos muertos..

Answer 2

Depurar un verdadero punto muerto es realmente fácil, si tienes acceso a la fuente y a un volcado de memoria (o una sesión de depuración en vivo).

Todo lo que debe hacer es mirar los hilos y encontrar los que están esperando algún tipo de recurso compartido (por ejemplo, colgados esperando en WaitForSingleObject).En términos generales, a partir de ahí es cuestión de descubrir qué dos o más subprocesos se han bloqueado entre sí, y luego sólo hay que descubrir cuál rompió la jerarquía de bloqueo.

Si no puede determinar fácilmente qué subprocesos están bloqueados, utilice el método que se muestra en esta publicación aquí para rastrear la cadena de bloqueo para cada hilo.Cuando entras en un bucle, los hilos del bucle son los que están estancados.

Answer 3

Si es muy vago, puede instalar Application Verifier, luego agregar su módulo y seleccionar solo "bloqueos" de la prueba básica.entonces puede ejecutar su aplicación con cualquier depurador.
Si se produce un punto muerto en una sección crítica, encontrará el motivo de inmediato.

Answer 4

¿Qué idioma/IDE estás usando?

En .Net puedes ver los hilos de una aplicación:Depurar->Windows->Subprocesos o Ctrl+Alt+H

Answer 5

Depurar puntos muertos puede ser complicado.Normalmente hago algún tipo de registro y veo dónde se detiene el registro.O inicio sesión en un archivo o en la consola de depuración usando OutputDebugString().

Answer 6

Lo mejor es comenzar agregando declaraciones de registro.En general, recomendaría solo los recursos compartidos que están estancados, pero agregarlos en general podría indicar situaciones o áreas de código que no esperaba.¡El tan publicitado problema de la base de datos de stackoverflow.com en realidad resultó ser log4net!El equipo de stackoverflow nunca sospechó de log4net, y solo al examinar el registro (irónicamente) lo demostró.Inicialmente, renunciaría a cualquier herramienta complicada, por ejemplo, WinDgb, ya que usarlas no es muy intuitivo en mi humilde opinión.