chien de garde de rapport d'incident pour quand mes application se bloque sur la machine d'un client

Question

Je travaille avec une application peu fiable (Qt / windows) écrit en partie pour nous par un tiers (juste essayer de passer le blâme là-bas). Leur dernière version est plus stable. Sorte de. Nous recevons moins de rapports d'accidents, mais nous recevons beaucoup de rapports de juste suspendus et ne jamais revenir. Les circonstances sont variées, et avec le peu d'informations que nous pouvons recueillir, nous n'avons pas été en mesure de reproduire les problèmes.

Donc, idéalement, je voudrais créer une sorte de chien de garde qui constate que l'application est verrouillé, et propose d'envoyer un rapport d'erreur à nous. Bonne idée, mais il y a des problèmes:

• Comment le chien de garde connaît le processus a accroché? On peut supposer que nous instrumentons l'application à dire périodiquement « tout ok » pour le chien de garde, mais où allons-nous mettre que de telle sorte qu'il est guarenteed arriver assez souvent, mais il est peu probable d'être sur un chemin de code que l'application se termine quand il est verrouillé.

• Quelles sont les informations si le rapport de surveillance lorsqu'un accident se produit? Windows a un api de débogage décent, donc je suis sûr que toutes les données intéressantes est accessible, mais je ne suis pas sûr de ce que serait utile pour traquer les problèmes.

Answer 1

Vous voulez une combinaison d'un minidump (utilisation DrWatson pour créer ces si vous ne voulez pas ajouter votre propre code de génération minidump) et Userdump pour déclencher une création minidump sur un coup.

La chose au sujet de la détection automatique d'un coup est que son difficile de décider quand somethings accroché et quand son juste lent ou bloqué par IO attente. Personnellement, je préfère permettre à l'utilisateur de planter l'application délibérément quand ils pensent le pendu. En plus d'être beaucoup plus facile (mes applications ne tendent pas à accrocher souvent, voire pas du tout :)), il les aide aussi à « faire partie de la solution ». Ils aiment ça.

Tout d'abord, consultez le Bugslayer article concernant crashdumps et symboles, qui a aussi d'excellents renseignements au sujet de ce qui se passe avec ces choses.

En second lieu, obtenir userdump qui vous permet de créer des décharges, et pour sa mise en place pour générer des décharges

Lorsque vous avez la décharge, ouvrez-le dans WinDBG, et vous serez en mesure d'inspecter l'ensemble de l'état du programme - y compris les fils et callstacks, registres, la mémoire et les paramètres aux fonctions. Je pense que vous serez particulièrement intéressés à utiliser le « ~ * kp » commande à Windbg pour obtenir le callstack de tous les fils, et la « commande! serrures » pour afficher tous les objets de verrouillage. Je pense que vous constaterez que le blocage sera dû à un blocage des objets de synchronisation, ce qui sera difficile à traquer que toutes les discussions ont tendance à attendre un appel WaitForSingleObject, mais regardez plus bas les callstacks pour voir les fils d'application (plutôt que les discussions « cadres » comme les notifications d'arrière-plan et les routines de réseau). Une fois que vous les avez PRECISEE, vous pouvez voir ce que les appels ont été faits, peut-être ajouter une instrumentation de l'exploitation forestière à l'application pour essayer de vous donner plus d'informations prêt pour la prochaine fois, il échoue.

Bonne chance.

Ps. Google Quick m'a rappelé ceci: Débogage des interblocages. (CDB est la ligne de commande équivalent de windbg)

Answer 2

Vous pouvez utiliser ADPlus à partir des outils de débogage de Microsoft pour Windows pour identifier les blocages. Elle attachera à votre processus et créer une décharge (mini ou plein) lorsque le processus se bloque ou se bloque.

WinDbg est portable et ne doit pas être installé (vous ne devez configurer les symboles, cependant). Vous pouvez créer une installation spéciale qui lancera votre application en utilisant un lot, qui sera également exécuter ADPlus après le démarrage de votre application (ADPlus est un outil de ligne de commande, vous devriez donc être en mesure de trouver un moyen d'intégrer une certaine façon).

BTW, si vous trouvez un moyen de reconnaître le blocage interne et sont capables de bloquer le processus, vous pouvez vous inscrire avec Windows Error Reporting de telle sorte que la décharge de l'accident sera envoyé (si l'utilisateur le permettent).

Answer 3

Je pense que d'une application séparée pour faire le watchdogging est susceptible de produire plus de problèmes qu'elle en résout. Je vous suggère qu'au lieu, vous devez d'abord créer des gestionnaires pour générer minidumps lorsque les accidents d'applications, puis ajouter un fil de chien de garde à l'application, ce qui va se planter VOLONTAIREMENT si l'application se éteint les rails. L'avantage au fil de chien de garde (contre une autre application) est qu'il devrait être plus facile pour le chien de garde de savoir avec certitude que l'application a déraillé.

Une fois que vous avez les minidumps, vous pouvez fouiner pour découvrir l'état de l'application quand il meurt. Cela devrait vous donner assez d'indices pour comprendre le problème, ou du moins où regarder à côté.

Il y a quelques trucs à CodeProject sur le minidumps , ce qui pourrait être utile exemple. MSDN a plus d'informations sur eux.

Answer 4

Ne vous embêtez pas avec un chien de garde. Abonnez-vous à l'erreur de Windows de Microsoft Reproting (winqual.microsoft.com). Ils recueillent les stacktraces pour vous. En fait, il est fort probable qu'ils le font déjà aujourd'hui; ils ne les partagent pas avant de vous inscrire.