web-dev-qa-db-fra.com

Débogage des fichiers de vidage dans Visual Studio

J'utilise Visual Studio 2010 Professional Edition et Windows Vista.

Premièrement, j'ai ce code. Comme vous pouvez le voir, cela fera planter le programme!

using System;

namespace Crash
{
    class Program
    {
        static void Main(string[] args)
        {
            string a = null;

            if (a.Length == 12)
            {
                // ^^ Crash
            }
        }
    }
}

Le programme se bloquera sur l'instruction if. Maintenant, je veux découvrir qu'il s'est écrasé sur cette instruction if.

Si je "démarre sans débogage" à partir de Visual Studio, Crash.exe se bloque. Il utilise 1 356 Ko de mémoire. J'obtiens l'option Vista de Fermer le programme/déboguer. Si je choisis Debug, je peux ouvrir une nouvelle instance de Visual Studio et cela me pointe vers une NullReferenceException sur l'instruction if. C'est bon.

Maintenant, laissez-moi supposer qu'il se bloque sur un autre ordinateur, et je les fais me donner un fichier de vidage via le Gestionnaire des tâches. C'est 54,567kb. Pourquoi si gros! C'est vaste! Quoi qu'il en soit, je suis moins intéressé par ça (légèrement)

Si j'ouvre cette décharge avec Windbg, je reçois très peu d'utilité pour mon œil inexpérimenté:

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\Richard\Desktop\Crash.DMP]
User Mini Dump File with Full Memory: Only application data is available

Symbol search path is: SRV*C:\SYMBOLS*http://msdl.Microsoft.com/download/symbols
Executable search path is: 
Windows Server 2008/Windows Vista Version 6002 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS Personal
Machine Name:
Debug session time: Sat Jan 15 11:07:36.000 2011 (UTC + 0:00)
System Uptime: 0 days 4:24:57.783
Process Uptime: 0 days 0:00:05.000
........................
eax=002afd40 ebx=77afa6b4 ecx=002afd48 edx=00000001 esi=001cdaa4 edi=00000000
eip=77bf5e74 esp=001cda5c ebp=001cdacc iopl=0         nv up ei ng nz ac pe cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000297
ntdll!KiFastSystemCallRet:
77bf5e74 c3              ret

Cependant, cela m'intéresse moins. Pour autant que je sache, j'ai besoin d'écrire des commandes pour obtenir une sortie utile, et Visual Studio est meilleur.

Je l'ouvre donc avec Visual Studio. Je peux choisir de "déboguer avec Native uniquement", mais je reçois beaucoup de choses qui signifient quelque chose pour des gens intelligents comme vous, et je ne suis pas intelligent! Je reçois ces deux écrans:

enter image description here

enter image description here

Donc, ma question:

Comment afficher Visual Studio dans mon code source?

De plus, existe-t-il un moyen d'obtenir un fichier de vidage plus petit? Il semble ridiculement gros, même après compression. Je ne comprends pas pourquoi il ne pourrait pas y en avoir un qui est juste un tout petit peu plus grand que l'empreinte du programme, et qui continue d'avoir un bon débogage, avec le code source.

c#debuggingvisual-studio-2010crash-dumps
50
niemiro

La fonctionnalité très annoncée que Visual Studio 2010 vous permet de déboguer les fichiers de vidage sur incident et de parcourir le code source géré est accompagnée d'un gotcha: cela fonctionne niquement pour les assemblys .NET 4. . Voici les étapes:

  1. Créer un fichier de vidage sur incident sur un autre ordinateur à l'aide du Gestionnaire des tâches
  2. Ouvrez la solution dans VS2010
  3. Ouvrez le fichier .DMP (Fichier-> Ouvrir ...)
  4. Cliquer sur Debug With Mixed (Cela sera visible uniquement pour .NET 4.0)
  5. Le code source s'ouvrira et vous pourrez inspecter la cause exacte et l'emplacement de l'exception

En ce qui concerne le débogage avec natif uniquement, Visual Studio n'est pas plus utile que WinDbg.

45
Darin Dimitrov

L'outil que vous utilisez ici n'a jamais été conçu pour dépanner les programmes gérés en panne. Minidumps et Windbg est ce que vous utilisez pour découvrir ce qui ne va pas avec le code écrit en C ou C++. Des outils assez importants, ce sont des langages dont les temps d'exécution ne prennent pas en charge le type de goodies que vous pouvez retirer d'un programme managé en panne. Comme une exception avec une trace de pile.

La raison pour laquelle les tailles de minidump sont si différentes est à cause du mini dans minidump. De par sa conception, il était censé capturer un petit instantané du processus. L'argument pertinent est DumpType dans fonction MiniDumpWriteDump . Il y a vraiment du code intelligent dans cette fonction qui peut déterminer quelles parties de l'état du processus n'ont pas besoin d'être enregistrées parce que vous n'êtes pas susceptible de l'utiliser dans la session de débogage. Que vous pouvez remplacer en fournissant des indicateurs de type de vidage supplémentaires. Le minidump qu'Explorer génère a tous ces drapeaux activés, vous obtenez tout le kit et caboodle.

Ce qui est en fait assez important pour un programme géré. L'heuristique utilisée par ce créateur de minidump est celle qui ne convient que pour le code non managé. Le débogage d'un vidage de programme géré ne fonctionne bien que lorsque vous incluez le tas de déchets collectés dans le vidage. Oui, ce sera une grosse décharge, mini ne s'applique plus.

Votre prochain problème est que vous obtenez l'âme de la vue de la machine à partir des données de mini-vidage. Vos captures d'écran montrent le code machine. Il se trouve que vous vous trouvez à l'intérieur de Windows dans ces plans, notez comment ntdll.dll est au-dessus de la pile. Les entrées mscorwks.dll sont le CLR. Plus bas, hors de vue, vous devriez voir les cadres de pile de votre propre code. Vous verrez cependant le code machine qui a été généré par le compilateur JIT. Pas votre code C #.

Il existe un complément Windbg appelé sos.dll qui étend le jeu de commandes de Windbg pour pouvoir inspecter les données gérées. Il suffit de google "sos.dll" pour obtenir de bons résultats. Ceci est cependant encore looong loin du type d'expérience de débogage que vous obtiendrez du débogueur Visual Studio. Qui est intimement conscient du code managé, très différent de Windbg ou du débogueur VS qui peut charger des minidumps. Sos a été vraiment conçu pour dépanner les bogues CLR.

Il n'y a eu aucune amélioration spectaculaire dans VS2010 autre que la page d'informations de minidump que vous voyez maintenant. Ce qui ne fait vraiment pas grand chose du tout. Je soupçonne l'équipe du débogueur d'avoir cela sur sa liste de tâches, il y a sûrement des problèmes fondamentaux à surmonter. Notamment au format minidump et au code de création. Utilisez connect.Microsoft.com pour fournir des commentaires, ils y prêtent attention et laissent les votes affecter leur liste de priorités.

41
Hans Passant

Vous devez fournir le fichier pdb (base de données de programme) au débogueur pour qu'il puisse charger les symboles. Pour obtenir une meilleure vue, utilisez également le serveur Microsoft Public Symbol. Cet article contient des informations à ce sujet.

5
HuseyinUslu