Débogage de la production .NET

Question

J'ai une application Windows en production depuis un certain temps et je l'ai configurée pour nous envoyer des rapports d'erreurs lorsqu'elle génère des exceptions. La plupart d'entre eux sont assez descriptifs et m'aident à trouver le problème très rapidement (j'utilise le bloc MS Exception Application).

À quelques occasions, j'ai des rapports qui sont des problèmes que je ne peux pas reproduire, et qui semblent ne se produire que sur quelques machines clientes.

Je n'ai pas d'accès physique à ces machines clientes, quelles sont les stratégies que je peux utiliser pour le débogage? Serait-il préférable de créer une trace dans le code, ou y a-t-il d'autres alternatives?

Merci. Editer: J'aurais dû être plus clair: Les rapports d'erreur que je reçois ont la trace de la pile, mais comme c'est le code de production, il n'indique pas la ligne exacte qui a causé l'exception, juste la méthode dans laquelle il a été jeté.

Answer 1

Une option consiste à générer un fichier de vidage (mini-) aussi proche que possible du point où l'exception est levée. Ce article parle de la façon de le faire à partir du code managé.

Vous pouvez ensuite charger le fichier de sauvegarde dans Visual Studio ou WinDbg et l'examiner à l'aide de SOS

Answer 2

Je l'utilise toujours module de Jeff pour les exceptions non gérées, me envoyer un email avec stacktrace etc.

Answer 3

je fais usage du journal des événements. Jetez un coup d'oeil ici:

http://support.microsoft.com/kb/307024

Answer 4

Vous êtes sur la bonne voie. Vous devez créer un module de suivi qui enregistre localement les actions/exceptions.

Vous pouvez alors avoir un bouton ou une option de menu sur lequel l'utilisateur peut cliquer pour soit vous envoyer automatiquement cette information par email au moment où le problème se produit, soit avoir la possibilité de récupérer le fichier pour le transférer à vous de toute autre manière.

Vous pouvez même intégrer un code de diagnostic pour exécuter une vérification d'intégrité sur le système et vous envoyer un rapport (peut-être exécute-t-il tous vos tests unitaires pour voir s'ils fonctionnent sur ce système).

Answer 5

intelligent Inspect de Gurock Software est venu à plusieurs reprises à portée de main pour moi. Il est très facile de mettre dans une application .NET et vous donne un contrôle extrêmement puissant lors de l'analyse des fichiers journaux. Il dispose de niveaux de journalisation qui vous permettent de désactiver certaines fonctionnalités, sauf dans certains cas, afin de ne pas perdre de performances.

Ils ont même un logiciel serveur auquel votre logiciel peut se connecter pour enregistrer les journaux lorsque vous n'avez pas un accès complet aux machines. Par exemple, vous pouvez avoir un serveur fonctionnant sur www.yourdomain.com. Votre logiciel aurait une option de configuration pour activer le débogage. Smart Inspect serait configuré pour envoyer les données du journal à votre serveur (et éventuellement à un fichier local) afin que vous puissiez obtenir la journalisation en direct, peu importe où le logiciel est exécuté. Smart Inspect est très facile à configurer et possède de nombreuses fonctionnalités que vous pouvez utiliser pour vous aider. Je l'ai utilisé pour déboguer des applications de serveur multithread à fort impact à la volée sans détruire les machines. Il a tous les moyens de suivre les différents processus, threads et machines.