Comment résoudre les problèmes de rapports d'erreur .NET 2.0 dans le journal des événements?

https://stackoverflow.com/questions/814560

03-07-2019
|

Question

Je travaille sur un produit open source appelé EVEMon , écrit en C # et ciblant la plate-forme .NET 2.0, I avoir un utilisateur qui souffre d'un crash .NET étrange que nous n'avons pas pu résoudre.

Event Type: Error
Event Source: .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID: 5000
Date: 4/29/2009
Time: 10:58:10 PM
User: N/A
Computer: removed this
Description:
EventType clr20r3, P1 evemon.exe, P2 1.2.7.1301, P3 49ea37c8, P4
system.windows.forms, P5 2.0.0.0, P6 4889dee7, P7 6cd3, P8 18, P9
system.argumentexception, P10 NIL.

Data:
//hex representation of the above Description

L’application elle-même se bloque sans affichage d’une erreur (malgré une interface utilisateur de gestion des erreurs), les messages ci-dessus ont été copiés à partir du journal des événements Windows. L'utilisateur final a réinstallé .NET et mis à jour vers les dernières versions. Les fichiers .PDB sont distribués avec chaque version du programme afin de faciliter le débogage et les tests. L’utilisateur présentant le problème en question dispose de l’ensemble complet de fichiers PDB pour la version correcte de EVEMon.

Existe-t-il une technique spécifique, éprouvée et éprouvée pour analyser et diagnostiquer ce type d’accident? et si oui, quels outils et technologies sont disponibles pour aider au débogage?

Merci spécial

Je voudrais remercier tout particulièrement Steffen Opel et souligner que sa réponse sans répondre directement à la question que je posais, a résolu le problème plus important que posait avec ma base de code le manque d'un composant important dans la gestion des erreurs globales.

La solution

C’est comme cela que je réglerais le problème pour un utilisateur final victime d’un crash.

Téléchargez et installez les outils de débogage pour Windows à l'adresse http: // www. .microsoft.com / whdc / devtools / debugging / default.mspx
Une fois les outils installés (ils finissent par aller dans C: \ Program Files \ par défaut), ouvrez une fenêtre de ligne de commande.
Allez dans le répertoire qui contient adplus (par exemple, "Outils de débogage C: \ Program Files pour Windows (x86)").
Exécutez la commande suivante. Ceci démarrera l'application et joindra adplus.

adplus -crash -o C: \ debug \ -FullOnFirst -sc C: \ chemin \ vers \ votre \ app.exe

Après la création du vidage sur incident

Une fois l’application en panne, démarrez WinDbg et chargez le fichier .dmp créé dans C: \ debug. (Fichier - > Ouvrir Crash Dump)

Exécutez ces commandes pour voir la trace de la pile et, espérons-le, trouver le problème.

Pour charger SOS pour le débogage

Avant .NET 4.0

.loadby sos mscorwks

.NET 4.0

.loadby sos clr

Pour voir la trace de la pile

!clrstack

Pour voir une trace de pile plus utile

!clrstack –p

Pour fouiller à l'intérieur d'un objet..peut-être voir la cause de l'exception

!do <address>

Par exemple, il s'agit du résultat d'une application qui a provoqué une exception d'altération aléatoire de manière aléatoire. WinDbg a indiqué que le chemin référencé était incorrect.

0:009> !do 017f2b7c    
Name: System.String    
MethodTable: 790fd8c4    
EEClass: 790fd824    
Size: 124(0x7c) bytes    
 (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)    
String: \\server\path\not_here.txt
Fields:    
      MT    Field   Offset                 Type VT     Attr    Value Name    
79102290  4000096        4         System.Int32  1 instance       54 m_arrayLength    
79102290  4000097        8         System.Int32  1 instance       53 m_stringLength    
790ff328  4000098        c          System.Char  1 instance       5c m_firstChar    
790fd8c4  4000099       10        System.String  0   shared   static Empty    
    >> Domain:Value  00161df8:790d884c <<    
7912dd40  400009a       14        System.Char[]  0   shared   static WhitespaceChars    
    >> Domain:Value  00161df8:014113e8 <<

Autres conseils

L'exploration de votre code source (trunk) indique que la gestion de vos exceptions non gérées semble être incomplète pour les applications Windows Forms:

Vous devez gérer les deux exceptions de threads non UI et exceptions de thread UI:

Pour les versions antérieures, vous devez implémenter un gestionnaire d'exceptions non géré CLR via AppDomain.CurrentDomain.UnhandledException , qui est déjà en place.
Pour ces derniers, vous devez implémenter un gestionnaire d'exceptions non géré Windows Forms via Application.ThreadException , qui semble manquer; cela pourrait effectivement donner exactement les problèmes auxquels vous êtes témoin. Pour un exemple d'implémentation, voir la documentation MSDN sur Application.ThreadException. Evénement .

Veuillez noter que pour le moment, vous supprimez explicitement la capture des exceptions Windows Forms non gérées via Application.SetUnhandledExceptionMode (UnhandledExceptionMode.ThrowException) , vous devrez le remplacer par UnhandledExceptionMode.CatchException pour activer le routage vers votre gestionnaire pour Application.ThreadException , comme suggéré déjà correctement par Jehof.

Quel système d’exploitation l’utilisateur utilise-t-il (Windows XP, Windows Vista, etc.)?

Si Windows Vista tente de désactiver la fonctionnalité "Problème avec les rapports et solutions", (Panneau de configuration - > Rapports et solutions aux problèmes - > Modifier les paramètres - > Paramètres avancés - > Désactiver pour mes programmes, signaler les problèmes)

Ou essayez de définir

  Application.SetUnhandledExceptionMode( UnhandledExceptionMode.CatchException );

Ceci routera toujours les exceptions vers le gestionnaire ThreadException.

En résumé: il existe une exception non gérée dans l'application.

Si vous avez accès à la machine (via un accès à distance, etc.), essayez d'installer Visual Studio Express et de démarrer l'application. Vous devriez voir une boîte de dialogue offrant la possibilité de déboguer l’application avec une nouvelle instance de Visual Studio.

Il se peut également que quelque chose empêche l’initialisation correcte de Windows Forms. Des messages de forum suggérant que des problèmes de police peuvent être à l'origine du problème sont à l'origine du problème. Assurez-vous que les utilisateurs ont installé les polices requises par votre application, ainsi que les valeurs par défaut habituelles telles que MS SansSerif, Arial, Tahoma, Times, etc.

Et à défaut ... essayez de sacrifier un poulet au-dessus du PC. Travaille un charme à chaque fois!

Nous avons eu des problèmes avec les exceptions dans Thread-Code. Si vous créez un nouveau thread et oubliez de gérer une exception dans la méthode du thread, l’application "s'arrête" - pas de message d'erreur, rien, mais seulement une entrée dans le journal des événements. Pas même quand UnhandledExceptionHandler est déclenché.

Peut-être que quelque chose comme ceci est la cause?

... si vous êtes capable de contacter cet utilisateur souffrant, voici un

Idée: enregistrez les étapes de pré-exécution

Au lieu de créer un raccourci vers votre programme.exe , créez un raccourci vers programme.bat , ce qui

echo "Pre-start" > stage.txt
start program.exe

La première ligne de Program.cs sera donc

File.WriteAllLines("stage.txt", "Program execution started.");

Dans le gestionnaire de AppDomain.UnhandledException , la première ligne sera

File.WriteAllLines("stage.txt", "Unhandled exception has been caught.");

Assurez-vous également que le gestionnaire n'alloue pas de mémoire ni de ressources & # 8212; pré-allouez-les au démarrage des programmes. Le gestionnaire ne déclenche que l'écriture dans le journal.

Commentaires

Il est très probable que le stage.txt (envoyé par l'utilisateur) contiendra "Pre-start". Cela se produit lorsqu'une exception est générée dans un fichier tiers .dll & # 8212; avant même que votre programme ait commencé.

Dans ce cas, vous aurez besoin d'un programme de vérification simple, qui ne référencera pas les assemblages que vous program.exe , mais Assembly.Load (...) eux.

P.S.

stage.txt doit être placé quelque part sous% APPDATA%, pas dans Program Files.

J'ai trouvé un cas intéressant sur Server 2003 et autre discussion intéressante .

Vous devriez obtenir une trace plus détaillée de la pile en envoyant le fichier .pdb de cette version particulière à l'utilisateur (à placer à côté du .exe ) et en ayant reproduisent le crash.

Vous devez gérer AppDomain.UnhandledException dans le code.

Il y a question similaire posée. Voir aussi les apparentés.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow