2010-07-23 15 views
1

J'ai une application Windows Forms (.NET 4) qui fonctionne bien sur ma machine de développement, mais se bloque sur deux autres machines de test. Je peux charger le minidump qu'il crée dans VS2010. Choisir "Déboguer avec Mixte" conduit à apparemment sans fin (j'ai tué environ 20 minutes) l'abus du processeur par Visual Studio. Lorsque je "Débogage avec natif uniquement", il ne peut pas trouver la source (même si j'ai reflété la source dans le même dossier que sur la machine de test)Comment puis-je voir le code C# qui a provoqué une crashdump à clr.dll?

Il dit simplement:

exception non gérée à 0x793f5b8c dans YourWinApp .exe.hdmp: 0xc0000409: 0xc0000409.

Et puis me montre

Appel emplacement de pile: clr.dll 793f5b8c()

Comment puis-je savoir ce qui cause crash de l'application! Est-ce que je peux prendre un crashdump complet pendant que la boîte de dialogue "Notify Microsoft" est affichée, et est-ce que cela aiderait?

Répondre

5

Le débogage de Minidump était supposé être majorly amélioré dans VS2010. Je n'ai pas encore vu beaucoup de preuves à ce sujet, le débogage en mode mixte a l'air aussi bizarre qu'avant quand j'ai fait quelques tests rapides. Ne me croyez pas sur parole. Native-only ne va cependant jamais vous montrer une pile d'appels gérés.

face à ce à la source. Ecrivez un gestionnaire d'événements pour AppDomain.CurrentDomain.UnhandledException et enregistrez-le dans votre méthode Main(). Laissez-le afficher la valeur de e.ExceptionObject.ToString() dans, disons, une boîte de message. Cela vous obtient la trace de pile gérée de l'exception. Alors que cette boîte de message est affichée, vous pouvez également aligner le minidump, devrait vous rapprocher de l'emplacement de l'accident.

L'exception particulière que vous obtenez est cependant définitivement pointant vers le code C/C++ natif. Un débordement de tampon qui corrompt la pile. Assurez-vous de disposer des fichiers .pdb pour tout code natif utilisé par votre application. Et configurez le serveur de symboles Microsoft pour obtenir une bonne trace de pile native de la minidump. Edit: le fait que vous n'obteniez pas UnhandledException élevé pointe définitivement vers la vérification de l'intégrité de la pile dans le CRT. Il a été conçu pour ne pas déclenche une exception, mais résilier immédiatement le programme. Comportement nécessaire parce que la pile est compromise, le code ne peut pas supposer qu'il peut être déroulé en toute sécurité. Compte tenu de l'emplacement de l'accident, il est probable que cette vérification soit effectuée dans le code CLR. Je sais que cela n'a pas été fait dans les versions précédentes de CLR, mais cela pourrait être différent dans la version CLR incluse avec .NET 4.0

Cela rendra très difficile l'obtention d'une trace de pile gérée. Il y a beaucoup, vous pouvez l'ingénierie inverse de la trace de la pile non géré, aussi longtemps que vous configurez le serveur de symboles afin que vous obtiendrez des noms d'identification des cadres de pile CLR. Publiez cette trace de pile dans votre question si vous voulez de l'aide pour l'interpréter. Un bug dans le code CLR n'est pas improbable btw, vous pouvez envisager d'appeler le support Microsoft. Ils auront cependant besoin d'un repro cohérent. Ils peuvent faire avec cette trace de pile importante si le repro est difficile à trouver. Configurez le serveur de symboles pour obtenir une bonne trace de pile non gérée. Facile dans VS2010: Outils + Options, Débogage, Symboles, cochez "Microsoft Symbol Servers".

+0

Je ne peux pas coller le code dans ce commentaire parce qu'il est trop petit, donc je l'ai mis ici: http://pastebin.com/WPvB05NV J'ai essayé de suivre votre suggestion pour enregistrer un gestionnaire pour l'exception UnhandledException, mais l'exception se produit toujours sans déclencher l'événement. –

+1

Désolé, j'ai oublié de réaliser: une erreur de dépassement de capacité de la pile met immédiatement fin au programme, elle ne génère pas d'exception. Je suis assez sûr que ces contrôles n'étaient pas présents dans CLR 2.0 mais cela pourrait être différent pour CLR 4.0. Rugueux, vous pourriez avoir besoin de l'aide de Microsoft Support. Obtenir un repro cohérent est essentiel. –

0

Vous configurez procdump pour obtenir plein vidage de la mémoire si l'application a exception non gérée, que vous pouvez déboguer dans VS ou Windbg

Et le minidump dispose d'informations appelez-pile comme des seaux watson, voici un de CLR équipe et je l'ai écrit au sujet de la same

Une brève explication sur les informations du godet watson que vous voyez dans l'observateur d'événements pour exception non gérée

  1. de ExeFileName
  2. Assemblée Exe Version
  3. Assemblée Exe Timestamp
  4. Nom complet
  5. Faulting Version Assemblée
  6. horodatage d'assemblage Faulting
  7. méthode d'assemblage Faulting def
  8. méthode Faulting instruction IL qui a provoqué l'exception
  9. Type d'exception