Pourquoi utiliser WinDbg vs le débogueur Visual Studio (VS)?

StackOverflow https://stackoverflow.com/questions/105130

  •  01-07-2019
  •  | 
  •  

Question

Quelles sont les principales raisons d'utiliser WinDbg avec le débogueur Visual Studio?

Et est-il couramment utilisé en remplacement complet du débogueur Visual Studio, ou davantage si le besoin s’en fait sentir.

Était-ce utile?

La solution

Si vous vous demandez pourquoi vous devriez utiliser windbg sur Visual Studio, vous devez lire Débogage avancé de Windows . Chaque fois que vous avez besoin de déboguer un problème vraiment laid, Windbg dispose d’une meilleure technologie que Visual Studio. Windbg a un langage de script plus puissant et vous permet d'écrire des DLL pour automatiser des problèmes difficiles. Il installera gflags.exe, ce qui vous donnera un meilleur contrôle sur le tas pour le débogage des écrasements de mémoire.

Vous n'avez pas réellement besoin d'exécuter l'installation, vous pouvez simplement copier les fichiers et être prêt à partir. En outre, il installe adsplus.vb, de sorte que vous pouvez prendre des mini-dumps des processus en cours d'exécution. Il est également très facile d’installer le débogage à distance. Il n’ya rien de mieux que de pouvoir résoudre un problème de votre propre bureau au lieu de lutter contre le problème 15 " moniteur qui scintille sur un PC de test.

Pour l'écriture quotidienne de code, j'utilise Visual Studio, mais une fois que vous avez besoin de résoudre des problèmes de débogage à partir d'autres ordinateurs ou de vous retrouver dans une situation très laide, windbg est la seule solution. Passer du temps à apprendre Windbg est un excellent investissement. En outre, si vous examinez les décharges sur incident, il existe deux excellentes ressources, http://www.dumpanalysis.org/blog et http://blogs.msdn.com/ntdebugging/default.aspx qui le font toute leur mise au point en utilisant windbg.

Autres conseils

Voici quelques liens supplémentaires pour vous aider à utiliser WinDbg . La plupart sont spécifiques à .NET.

Vous ne spécifiez pas si vous déboguez du code natif ou managé. Cela n’affecte pas la réponse, WinDbg est extrêmement utile, mais beaucoup de personnes pensent que WinDbg est en quelque sorte moins pertinent lors du débogage d’applications .NET. Pas si. En bonus, vous pouvez en apprendre beaucoup sur le fonctionnement de la plate-forme .NET en déboguant votre application .NET dans WinDbg avec l'extension SOS. Lancez (ou attachez) votre application .NET dans WinDbg et tapez ... 

.loadby sos mscorwks

... pour vous assurer de charger la bonne extension pour la version du CLR utilisée. Puis tapez ... 

!help

... pour voir quelles commandes sont disponibles dans l'extension SOS.

J'ai entendu dire à la blague que Microsoft ne possède qu'un seul outil de développement, à savoir WinDbg. Tout ce que vous pouvez souhaiter pour le débogage est présent ou dans une extension. Bien sûr, un sous-ensemble de ces éléments est également disponible dans VS avec une interface utilisateur plus conviviale ...: -)

Je l'ai utilisé lorsque des fichiers .dmp provenant d'un serveur NT4.0 m'ont été envoyés - MSVC ne charge pas ces fichiers au format ancien.

Mélange du débogage du noyau et du débogage en mode utilisateur à distance.

autant que je sache, visual studio encore ne peut pas effectuer de débogage à distance dans le mode que je qualifie de "solution". C’est une très bonne raison d’utiliser Windbg.

Problème:

  • Configurez windbg sur 1394. Votre application s'exécute sur la "cible". Windbg fonctionne sur "l'hôte".
  • Exécuter Visual Studio sur l'hôte
  • Demandez à visual studio de lancer votre application sur la cible à l'aide des outils distants.
  • Entrez dans le mode noyau windbg pour arrêter la cible
  • Attendez suffisamment longtemps pour que la connexion TCP de Visual Studio expire
  • " g " dans windbg pour déstabiliser la cible
  • observez votre application " pop " lorsque le moniteur distant réalise que la connexion réseau a disparu
  • redémarrez votre application: (

Solution:

  • N'utilisez pas Visual Studio.
  • Exécuter un windbg en mode utilisateur sur la cible avec "-server" "
  • Demandez à windbg de la cible de lancer votre application.
  • Sur l'hôte, démarrez un 2e windbg qui se connecte à la cible avec "-remote".
  • Si la connexion TCP meurt, démarrez simplement une autre instance de windbg sur l'hôte et rien ne sera perdu. Votre application n'est pas morte car le processus windbg de contrôle du mode utilisateur est en cours d'exécution sur la cible.

De plus, je trouve qu'il est plus facile d'utiliser le même débogueur pour le mode noyau et le mode utilisateur, windbg est très puissant, même en mode utilisateur, et je peux utiliser mes propres extensions windbg. en mode noyau et en mode utilisateur.

Léger, peut être exécuté sans l’installer sur la machine d’un client, rapidement, peut déboguer le mode noyau.

Le dernier studio visuel manque-t-il encore un équivalent à celui de Windbg " -o " que le débogueur attache automatiquement aux processus enfants? Très utile pour les applications devant être exécutées à partir d’un fichier .bat compliqué ou pour les applications qui se divisent en deux et quittent le processus parent.

J'ai toujours aimé la fonction de surveillance et de traçage: "wt" - > Il imprime dans la fenêtre de sortie tous les appels de fonction au fur et à mesure. C’était vraiment cool!

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top