¿Por qué utilizar WinDbg frente al depurador de Visual Studio (VS)?

Question

¿Cuáles son las principales razones para usar WinDbg frente al depurador de Visual Studio?

Y es comúnmente utilizado como un reemplazo completo para el depurador de Visual Studio, o más para cuando sea necesario.

Answer 1

Si se está preguntando por qué debería usar windbg en Visual Studio, entonces necesita leer Advanced Windows Debugging. Cada vez que necesite depurar un problema realmente desagradable, Windbg tiene una mejor tecnología para hacerlo que Visual Studio. Windbg tiene un lenguaje de scripting más poderoso y le permite escribir archivos DLL para automatizar problemas difíciles. Instalará gflags.exe, que le brinda un mejor control sobre el montón para eliminar sobrescrituras de memoria.

No necesita ejecutar la instalación, puede simplemente copiar los archivos y estar listo para funcionar. También instala adsplus.vb, por lo que puede tomar mini-volcados de procesos en ejecución. También es muy fácil de configurar para realizar la depuración remota. No hay nada mejor que poder depurar un problema de su propio escritorio en lugar de luchar contra el monitor de 15 "que parpadea en una PC de prueba.

Para escribir código día a día utilizo Visual Studio, pero una vez que necesita comenzar Depuración de problemas de otras computadoras o encontrarse en una situación muy fea, windbg es la única manera de ir. Pasar un tiempo aprendiendo windbg es una gran inversión. También si nos fijamos en volcados de emergencia hay dos grandes recursos, http://www.dumpanalysis.org/blog y http://blogs.msdn.com/ntdebugging/default.aspx que hacen toda su depuración usando windbg

Answer 2

Lo he usado cuando me enviaron archivos .dmp desde un servidor NT4.0 - MSVC no cargará estos archivos de formato anterior.

Answer 3

Ligero, se puede ejecutar sin instalarlo en la máquina de un cliente, rápido, puede depurar el modo kernel.

Answer 4

No especifica si está depurando código nativo o administrado. No afecta la respuesta, WinDbg es extremadamente útil para ambos, pero muchas personas creen que WinDbg es de alguna manera menos relevante cuando debuggi ng .NET aplicaciones. No tan. Como beneficio adicional, puede aprender mucho sobre cómo funciona la plataforma .NET mediante la depuración de su aplicación .NET en WinDbg con la extensión SOS. Ejecutar (o adjuntar a) su aplicación .NET en WinDbg y el tipo ...

.loadby sos mscorwks 

... para asegurarse de que se carga la extensión correcta para la versión de CLR en uso. Luego escriba ...

!help 

... para ver qué comandos están disponibles en la extensión SOS.

Lo he escuchado decir en broma que Microsoft solo tiene una herramienta de desarrollador, y es WinDbg. Todo lo que pueda desear para la depuración está allí, o en una extensión. Claro, un subconjunto de esas cosas también están disponibles en VS con una interfaz de usuario más amigable ... :-)

Answer 5

Aquí hay algunos otros enlaces para ayudar con el uso de WinDbg, la mayoría son específicos de .NET.

• John Robbins habla sobre el uso de cmdtree para crear una ventana de comandos.
• Aquí está una rápida WinDbg/SOS cheat sheet.
• If broken it is, fix it you should tiene un montón de WinDbg/Sos artículos relacionados, principalmente en torno a la depuración de ASP.NET.
• Here es una vista general antigua de SOS de MSDN mag. Se trata .NET 1.1 por lo que su edad se está mostrando.

Answer 6

Mezclar kernel-debugging plus remote-user-mode-debugging.

AFAIK, visual studio todavía no se puede hacer la depuración remota en el modo que describo como "solución". Esa es una buena razón para usar windbg.

Problema:

• Configurar windbg través de 1394. Su aplicación se ejecuta en el "blanco". Windbg se ejecuta en el "host".
• Ejecuta Visual Studio en el host
• Haz que Visual Studio lance tu aplicación en el objetivo usando las herramientas remotas.
• entrar en el windbg modo de núcleo que apague el objetivo
• esperar el tiempo suficiente para la conexión TCP de Visual Studio para el tiempo de espera
• "g" en windbg a un-alto del objetivo
• observar a su aplicación "pop" cuando el monitor remoto se da cuenta de la conexión de red se ha ido
• reinicia la aplicación :(

Solución:

• No use visual studio.
• Ejecuta un windbg en modo de usuario en el destino con "-server"
• Haz que el windbg del objetivo inicie tu aplicación.
• En el host, inicie un 2nd windbg que se conecta al objetivo con "-remote".
• Si la conexión TCP se acaba, inicie otra instancia de windbg en el host y no se perderá nada. Su aplicación no murió porque el proceso windbg del modo de usuario controlador se está ejecutando en el objetivo.

Además, me resulta más fácil utilizar el mismo depurador para el modo núcleo y modo de usuario, windbg es muy potente, incluso en modo de usuario, y puedo aprovechar mis propias extensiones de WinDbg tanto en modo núcleo y modo de usuario instancias.

Answer 7

¿Faltan los últimos estudios visuales un equivalente a "-o" de windbg que hace que el depurador se una automáticamente a procesos secundarios? Muy útil para aplicaciones que deben ejecutarse desde un archivo .bat complicado o aplicaciones que se bifurcan y salen del proceso principal.

Answer 8

Siempre me ha gustado la característica de ver y trazar: 'wt' -> Imprime en la ventana de salida todas las llamadas de función a medida que ocurren. ¡Eso fue genial!