Quelles informations capturez-vous lorsque votre logiciel tombe en panne sur le terrain?

Question

Je travaille sur la réécriture de mon processus de traitement des erreurs inattendues, et je voudrais demander à la communauté:

Quelles informations saisissez-vous à la fois automatique, et manuellement, lorsque le logiciel que vous avez écrit des accidents?

En ce moment, je capture quelques éléments, dont certains sont:

automatique:

1. Nom de l'application qui est écrasé
2. version de l'application qui se est écrasé
3. Trace de la pile
4. Version du système d'exploitation
5. RAM utilisée par les appli cation
6. Nombre de processeurs
7. Capture d'écran: (uniquement sur les applications non publiques)
8. Nom d'utilisateur et les informations de contact (à partir d'Active Directory)

Manuel:

1. Dans quel contexte se trouve l'utilisateur (c'est-à-dire: quelle entreprise, numéro d'appel du support technique, numéro RA, etc ...)
2. l'utilisateur s'attend à se produire? (Réponse typique: « Ne pas tomber en panne »)
3. Procédure pour reproduire

Quels autres éléments d'information ne vous capturez qui vous aide à découvrir la véritable cause d'un problème d'applications, en particulier étant donné que la plupart des utilisateurs simplement purée. le clavier lorsqu'on lui a demandé de vous dire ce qui est arrivé

pour mémoire j'utilise C#, WPF et la version .NET 4, mais je ne veux pas nécessairement me limiter à ceux

connexes:.. What to: Collect Information When Software Crashes

En relation: What should be included in the state-of-the-art error and exception handling strategy?

Answer 1

(Ceci est un peu de Windows/.NET spécifique, mais c'est-ce que vous avez spécifié dans la question, et je pense que cela est très utile d'information dans ce contexte.)

À moins que votre application est strictement monothread, vous voulez un fichier de vidage (qui vous donnera la pile pour tous les threads, au minimum), pas seulement une trace de pile pour le thread qui lève l'exception.

La génération d'une image de vidage pas trop grande et disposant de suffisamment d'informations pour vous fournir des traces de pile gérées utiles est un peu compliquée, mais il existe un utilitaire très utile appelé clrdump qui gérera certains détails du gorier.Clrdump est principalement un wrapper pour DbgHelp.dll de Microsoft. Vous pouvez utiliser directement DbgHelp - voir this question - mais vous obtiendrez un "full minidump" qui sera aussi grand que l'espace d'adressage virtuel de votre application, ce qui peut être assez important. Clrdump fait un bon travail de création d'un petit vidage avec juste les traces de la pile et suffisamment d'informations pour que SOS puisse les lire.

Answer 2

LA Transtar conserve également un journal de clés qui n'est sauvegardé que pour les défaillances. Ce journal contient l'entrée et une trace du programme en cours. Le journal est réinitialisé au début de chaque nouvelle transaction.

Answer 3

Vous ne mentionnez pas la journalisation des processus (comme syslog sous Linux, Event Viewer pour Windows?). Depuis que j'ai aussi un fond d'administration sys j'apprécie vraiment les programmes avec une facilité de journalisation. Encore mieux si le niveau de verbosité peut être sélectionné.

Il est bon pour vous d'en savoir plus sur l'environnement, et il est bon pour vos utilisateurs s'ils doivent effectuer un certain type de travail d'intégration avec d'autres outils.

Si vos utilisateurs sont plus techniques, vous pouvez leur demander de définir la verbosité de journalisation au maximum et de reproduire à nouveau l'erreur.

Answer 4

Fondamentalement, il n'y a pas de règle d'or que vous devez suivre et implémenter dans chaque application. En fonction de votre application métier et de votre scénario, différentes choses sont les plus appropriées à inclure dans la collecte d'informations lorsqu'une erreur se produit.

Ceux que vous avez mentionnés sont OK, mais voici un peu plus ce qui est bon pour être connecté:

• paramètres d'entrée pour les opérations critiques et complexes
• cadre de votre programme - certains objets avec des algorithmes lourds - la plupart des classes possédant risque
• l'état dans lequel est votre programme

exemple: le flux de votre programme est comme un automate d'état et vous avez 5 États un d vous avez atteint l'état 3.

• si vous avez une application qui est client-serveur, recueillir les deux journaux - de fournisseur et côté consommation

  vidage de la mémoire

• est généralement pas une bonne idée - le faire uniquement lorsque vous avez besoin de comprendre des problèmes dans des frameworks ou des JVM (par exemple) dont vous n'avez aucun contrôle. OutOfMemoryError par exemple

Answer 5

Je ne vois pas dans votre liste les informations les plus importantes (quand on parle de niveau dotnet/java de code).
Type d'exception, message et trace.
Vous pouvez utiliser du code simple, pour intercepter toute exception, et "écrire dans le journal"/"envoyer directement à l'e-mail".

Answer 6

Et maintenant du camp de paranoïa :(

Tenir compte ce que l'industrie des targets logiciels. Rassembler toutes les informations relatives à l'utilisateur (même nom de répertoire actif) ou le réseau peut obtenir votre application blackboulé et porte potentiellement la responsabilité. C.-à-Que Si votre base de données de bogues est compromise et que cette information est utilisée pour pénétrer dans le réseau d'une banque ou d'un laboratoire gouvernemental, le rapport de bogue contenant leurs IP sera-t-il remarqué?Par exemple, si vous avez besoin de collecter des données spécifiques au réseau pour diagnostiquer les problèmes réseau, pensez à ce que votre application remplace tout nom de système ou toute adresse IP par des espaces réservés avant que les données ne vous soient renvoyées. (emailSrvr1, bankAcctNumSrv, devient srvr1 et srvr2) Il est plus difficile de localiser les problèmes, mais cela peut en valoir la peine. Ceci capture toujours l'information qui pourrait vous causer des ennuis, mais peut aider.

Je travaille depuis quelques années avec des entreprises haut de gamme et des administrations publiques, ce qui me permet de prendre en compte mon point de vue, mais il est probablement utile d'examiner ce que vous collectez et comment il est stocké.