de vigilancia informes de bloqueo para cuando mis cerraduras de aplicación arriba en la máquina de un cliente

Question

Estoy trabajando con un (/ ventanas Qt) aplicación poco fiable en parte por escrito para nosotros por un tercero (tratando de echarle la culpa allí). Su última versión es más estable. Algo así como. Estamos recibiendo menos informes de accidentes, sino que estamos recibiendo una gran cantidad de informes de que simplemente pasar y nunca volver. Las circunstancias son muy variados, y con la poca información que se desprende, no hemos sido capaces de reproducir los problemas.

Así que lo ideal, me gustaría crear algún tipo de organismo de control, que se da cuenta de que la aplicación se ha bloqueado, y se ofrece a enviar un informe de fallos de nuevo a nosotros. Buena idea, pero hay problemas:

• ¿Cómo sabe el organismo de control del proceso ha colgado? Es de suponer que instrumento de la aplicación que decir periódicamente "todo muy bien" para el organismo de control, pero no donde ponemos que de tal manera que se guarenteed a suceder con frecuencia suficiente, pero no es probable que sea en una ruta de código que la aplicación termina en cuando es bloqueada.

• ¿Qué información debe el informe de vigilancia cuando ocurre un accidente? Windows tiene un API de depuración decente, así que estoy seguro de que todos los datos interesantes es accesible, pero no estoy seguro de lo que sería útil para la localización de los problemas.

Answer 1

¿Quieres una combinación de un minidump (uso DrWatson para crear estos si no desea añadir su código de generación minidump) y el volcado de usuario para desencadenar una creación minidump en un colgar.

Lo que pasa con la detección automática de un bloqueo es que su difícil decidir cuándo tantos colgados y cuando su justo lento o bloqueado por IO espera. Prefiero personalmente para que el usuario se bloquee la aplicación deliberada cuando piensan en su colgado. Además de ser mucho más fácil (mis aplicaciones no tienden a pasar a menudo, en todo caso :)), sino que también les ayuda a "ser parte de la solución". A ellos les gusta eso.

En primer lugar, echa un vistazo a la clásica bugslayer artículo relativo crashdumps y símbolos, que también tiene una excelente información sobre lo que está pasando con estas cosas.

En segundo lugar, obtener volcado de usuario , que le permite crear los vertederos, y instrucciones para su puesta en marcha para generar vertederos

Cuando se tiene el vertedero, abrirlo en WinDBG, y usted será capaz de inspeccionar todo el estado del programa - incluyendo hilos y callstacks, registros, memoria y parámetros a funciones. Creo que usted estará particularmente interesado en el uso de la " ~ * kp " comando en WinDbg para conseguir la pila de llamadas de cada hilo, y el 'comando! cerraduras' para mostrar todos los objetos de bloqueo. Creo que usted encontrará que la caída será debido a un estancamiento de objetos de sincronización, que será difícil de localizar ya que todos los hilos tienden a esperar en una llamada WaitForSingleObject, pero mira más abajo en los callstacks para ver las hebras de la aplicación (en lugar que las discusiones 'marco' como notificaciones en segundo plano y rutinas de red). Una vez que los haya reducido, se puede ver lo que estaban haciendo llamadas, posiblemente, añadir un poco de instrumental de registro de la aplicación para tratar de darle más información lista para la próxima vez que se produce un error.

Buena suerte.

Sal. Google rápida me recordó esto: callejones sin salida de depuración . (CDB es la línea de comandos equivalente de windbg)

Answer 2

Puede utilizar ADPlus de herramientas de depuración de Microsoft para Windows para identificar los bloqueos. Se adjuntará a su proceso y crear un vertedero (mini o completa) cuando el proceso se bloquea o se bloquea.

WinDbg es portátil, y no tiene que ser instalado (usted tiene que configurar los símbolos, sin embargo). Puede crear una instalación especial que pondrá en marcha su aplicación usando un lote, que también lanzará ADPlus después del comienzo de la aplicación (ADPlus es una herramienta de línea de comandos, por lo que debe ser capaz de encontrar una manera de incorporar de alguna forma).

Por cierto, si usted encuentra una manera de reconocer la caída interna y es capaz de bloquear el proceso, puede registrarse en Informe de errores de Windows para que el volcado de bloqueo será enviado a usted (si el usuario lo permite).

Answer 3

Creo que una aplicación separada para hacer el watchdogging es probable que produzca más problemas de los que resuelve. Yo sugeriría que en vez, primero debe crear manejadores de generar minivolcados cuando la aplicación se bloquea, a continuación, añadir un hilo de vigilancia para la aplicación, que se colgará DELIBERADO si la aplicación se descarrila. La ventaja para el flujo watchdog (vs una aplicación diferente) es que debería ser más fácil para el perro guardián de saber con certeza que la aplicación ha ido fuera de los carriles.

Una vez que tenga los minivolcados, puede hurgar para averiguar el estado de la aplicación cuando muere. Esto debería dar suficientes pistas para averiguar el problema, o al menos dónde buscar siguiente.

Hay algunas cosas en CodeProject sobre minivolcados , lo que podría ser un útil ejemplo. MSDN tiene más información acerca de ellos.

Answer 4

No se moleste con un perro guardián. Suscribirse a Reproting de errores de Windows de Microsoft (winqual.microsoft.com). Ellos recogen los stacktraces para usted. De hecho, es muy probable que ya están haciendo así que hoy; que no comparten ellos hasta que se inscribe.