Débogage des fichiers de vidage dans Visual Studio

Question

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

Tout d'abord, j'ai ce code. Comme vous pouvez le voir, il 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 bloque sur l'instruction if. Maintenant, je veux savoir s'il s'est planté sur cette instruction if.

Si je "Démarre sans déboguer" à partir de Visual Studio, Crash.exe se plante. Il utilise 1 356 Ko de mémoire. Vista me propose l'option "Close Program/Debug". Si je choisis Debug, je peux ouvrir une nouvelle instance de Visual Studio, et il m'indique une NullReferenceException sur l'instruction if. C'est une bonne chose.

Supposons maintenant qu'il tombe en panne sur un autre ordinateur et que je lui demande de me fournir un fichier de vidage via le gestionnaire des tâches. Il fait 54,567kb. Pourquoi si gros ? C'est énorme ! Quoi qu'il en soit, je suis moins intéressé par cela (légèrement).

Si j'ouvre ce dump avec Windbg, je n'obtiens que très peu d'informations utiles à mon œil non averti :

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 présente moins d'intérêt pour moi. Pour autant que je sache, j'ai besoin d'écrire des commandes pour obtenir des résultats utiles, et Visual Studio est meilleur.

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

Donc, ma question :

Comment montrer Visual Studio à mon code source ?

De plus, y a-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 ne serait qu'un tout petit peu plus grand que l'empreinte du programme, tout en obtenant un bon débogage, avec le code source.

Answer 1

La fonctionnalité tant annoncée selon laquelle Visual Studio 2010 vous permet de déboguer les fichiers de vidage de panne et de parcourir le code source géré est assortie d'un problème : elle ne fonctionne pas. uniquement pour les assemblages .NET 4.0 . Voici les étapes à suivre :

1. Créez un fichier de vidage de panne sur un autre ordinateur à l'aide du gestionnaire de tâches.
2. Ouvrez la solution dans VS2010
3. Ouvrir le fichier .DMP (Fichier->Ouvrir...)
4. Cliquez sur Debug With Mixed (Ceci ne sera visible que pour .NET 4.0)
5. Le code source s'ouvrira et vous serez en mesure d'inspecter la cause et l'emplacement exacts de l'exception.

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

Answer 2

L'outil que vous utilisez ici n'a jamais été conçu pour dépanner les programmes gérés qui se plantent. Minidumps et Windbg sont ce que vous utilisez pour trouver ce qui ne va pas avec du code écrit en C ou C++. Ce sont des outils assez importants, ce sont des langages dont les runtimes ne supportent pas le genre de choses que l'on peut obtenir d'un programme géré qui plante. Comme une exception avec une trace de pile.

La raison pour laquelle les tailles de minidump sont si différentes est le mini dans minidump. Par conception, il est destiné à capturer un petit instantané du processus. L'argument pertinent est DumpType dans l'option Fonction MiniDumpWriteDump . Il y a un code très 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 les utiliser dans la session de débogage. Ce que vous pouvez remplacer en fournissant des drapeaux 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 le caboodle.

Ce qui est en fait assez important pour un programme géré. L'heuristique utilisée par ce créateur de minidump est une heuristique qui n'est appropriée que pour du code non géré. Le débogage d'un programme géré ne fonctionne bien que si vous incluez l'ensemble du tas de données collectées dans le vidage. Oui, ce sera un gros dump, mini ne s'applique plus.

Votre problème suivant est que vous obtenez l'âme de la vue machine à partir des données minidump. Vos captures d'écran montrent le code machine. Vous vous trouvez à l'intérieur de Windows dans ces images, notez comment ntdll.dll est au sommet 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 module complémentaire de Windbg appelé sos.dll qui étend le jeu de commandes de Windbg afin de pouvoir inspecter les données gérées. Il suffit de googler "sos.dll" pour obtenir de bons résultats. Il s'agit toutefois d'un looong loin du type d'expérience de débogage que vous obtiendrez avec le débogueur de Visual Studio. Ce dernier est intimement lié au code géré, contrairement à Windbg ou au débogueur de VS qui peut charger des minidumps. Sos a vraiment été conçu pour dépanner les bugs du CLR.

Il n'y a pas eu d'améliorations spectaculaires dans VS2010, à part la page d'information sur le minidump que vous voyez maintenant. Ce qui ne fait pas grand chose du tout. Je soupçonne l'équipe Debugger d'avoir ce problème sur leur liste de choses à faire, il y a sûrement quelques problèmes fondamentaux à surmonter. En particulier dans le format minidump et le code de création. Utilisez connect.microsoft.com pour donner votre avis, ils y prêtent attention et laissent les votes affecter leur liste de priorités.

Answer 3

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