Débogage des fichiers de vidage dans Visual Studio

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

Tout d’abord, j’ai ce code. Comme vous pouvez le voir, il va planter le programme!

using System; namespace Crash { class Program { static void Main(ssortingng[] args) { ssortingng a = null; if (a.Length == 12) { // ^^ Crash } } } } 

Le programme se bloque sur l’instruction if. Maintenant, je veux savoir que cela a planté sur cette déclaration si.

Si je “démarre sans débogage” à partir de Visual Studio, Crash.exe se bloque. Il utilise 1 356 Ko de mémoire. Je reçois l’option Vista de Close Program / Debug. Si je choisis Debug, je peux ouvrir une nouvelle instance de Visual Studio, et cela me dirige vers une exception NullReferenceException sur l’instruction if. C’est bon.

Maintenant, laissez-moi supposer qu’il se bloque sur un autre ordinateur, et je les amène à me donner un fichier de vidage via le Gestionnaire des tâches. C’est 54,567kb. Pourquoi si grand! C’est vaste! Quoi qu’il en soit, cela m’intéresse moins (légèrement)

Si j’ouvre cette page avec Windbg, mon œil non averti est très peu utilisé:

 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. Autant que je sache, je dois é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’ai beaucoup de choses qui signifient quelque chose pour les personnes intelligentes comme vous, et je ne suis pas intelligent! Je reçois ces deux écrans:

entrer la description de l'image ici

entrer la description de l'image ici

Alors, ma question:

Comment afficher Visual Studio dans mon code source?

En outre, existe-t-il un moyen d’obtenir un fichier de vidage plus petit? Il semble ridiculement grand, même après la 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 toujours obtenir un bon débogage, avec le code source.

La fonctionnalité très annoncée que Visual Studio 2010 vous permet de déboguer des fichiers de vidage sur incident et de parcourir le code source géré est fournie avec un gotcha: elle ne fonctionne que pour les assemblys .NET 4.0 . 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. Cliquez sur Debug With Mixed (ceci 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

Dans la mesure où le débogage avec uniquement natif est concerné, Visual Studio n’est pas plus utile que WinDbg.

Les outils que vous utilisez ici n’ont jamais été conçus pour résoudre les programmes gérés en panne. Minidumps et Windbg sont ce que vous utilisez pour déterminer ce qui ne va pas avec le code écrit en C ou C ++. Des outils assez importants, ce sont des langages dont les runtimes ne supportent pas le genre de goodies que vous pouvez retirer d’un programme géré en panne. Comme une exception avec une trace de stack.

La raison pour laquelle les tailles de minidump sont si différentes est due au mini-minidump. De par leur conception, il s’agissait de capturer un petit instantané du processus. L’argument approprié est DumpType dans la 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 car vous ne l’utiliserez probablement pas dans la session du débogueur. Que vous pouvez remplacer en fournissant des indicateurs supplémentaires de type de vidage. Le minidump que l’explorateur génère a tous ces drapeaux activés, vous obtenez le kit complet 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 convient uniquement au code non géré. Le débogage d’un vidage de programme géré ne fonctionne bien que si vous incluez l’intégralité du tas récupéré dans le vidage. Oui, ce sera un gros vidage, le 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 minidump. Vos captures d’écran affichent le code machine. Vous vous trouvez à l’intérieur de Windows dans ces plans, notez comment ntdll.dll est au-dessus de la stack. Les entrées mscorwks.dll sont le CLR. Plus bas, hors de vue, vous devriez voir les frameworks de stack de votre propre code. Vous verrez cependant le code machine 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 loin du type d’expérience de débogage que vous obtiendrez avec le débogueur de Visual Studio. Qui est intimement au courant du code managé, très différent de Windbg ou du débogueur VS qui peut charger minidumps. Sos était 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 pas grand chose du tout. Je soupçonne l’équipe de débogage de l’avoir sur sa liste de tâches, il y a sûrement des problèmes fondamentaux à surmonter. En particulier dans le format minidump et le code de création. Utilisez connect.microsoft.com pour fournir des commentaires, ils y prêtent attention et permettent aux votes d’affecter leur liste de priorité.

Vous devez fournir le fichier pdb (firebase database de programme) associé 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.