visual tutorial studio instalar español code visual-studio windbg

visual-studio - tutorial - visual studio code español



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

¿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 surja la necesidad.

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

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

Si se pregunta 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.

En realidad, 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 solucionar un problema desde su propio escritorio en lugar de luchar contra el monitor de 15 "que parpadea en una PC de prueba.

Para la escritura de código día a día utilizo Visual Studio, pero una vez que necesita comenzar a depurar problemas desde otras computadoras o encontrarse en una situación muy fea, windbg es el único camino a seguir. Pasar algún tiempo aprendiendo windbg es una gran inversión. Además, si nos fijamos en los volcados de emergencia, hay dos recursos geniales, http://www.dumpanalysis.org/blog y http://blogs.msdn.com/ntdebugging/default.aspx, que realizan todas las tareas de depuración utilizando windbg.

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 al depurar aplicaciones .NET. 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 escriba ...

.loadby sos mscorwks

... para asegurarse de cargar la extensión correcta para la versión del CLR en uso. Luego escribe ...

!help

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

Lo escuché 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 ... :-)

¿Falta el último estudio visual 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.

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

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

Problema:

  • Configure windbg en 1394. Su aplicación se ejecuta en el "objetivo". Windbg se ejecuta en el "host".
  • Ejecuta Visual Studio en el host
  • Haga que Visual Studio lance su aplicación en el objetivo utilizando las herramientas remotas.
  • Irrumpir en el windbg del modo kernel para detener el objetivo
  • Espere el tiempo suficiente para que la conexión TCP del estudio visual exceda el tiempo de espera
  • "g" en windbg para detener el objetivo
  • observe su aplicación "pop" cuando el monitor remoto se da cuenta de que la conexión de red se ha ido
  • reinicia tu aplicación :(

Solución:

  • No use Visual Studio.
  • Ejecuta un windbg en modo usuario en el objetivo con "-server"
  • Haz que el windbg del objetivo inicie tu aplicación.
  • En el host, comienza un segundo 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 usar el mismo depurador tanto para el modo kernel como para el modo usuario, windbg es muy potente incluso en modo usuario, y puedo aprovechar mis propias extensiones Windbg tanto en modo kernel como en modo usuario.

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

Siempre me gustó la función de ver y rastrear: ''wt'' -> Imprime en la ventana de salida todas las llamadas de función a medida que ocurren. ¡Eso fue genial!