¿Por qué no se cargan símbolos al depurar de forma remota?

Question

Quiero usar la depuración remota. El programa que quiero depurar se ejecuta en la máquina b. Visual Studio se ejecuta en la máquina a.

En la máquina b tengo una carpeta con los siguientes archivos:

• msvcr72.dll
• msvsmon.exe
• NatDbgDE.dll
• NatDbgDEUI.dll
• NatDbgEE.dll
• NatDbgEEUI.dll

Si cree que faltan algunos archivos, ¿podría describir también dónde se encuentran generalmente?

En el siguiente paso comencé el msvsmon.exe y mi programa en la máquina b. En la máquina a, comencé Visual Studio 2008 y mi solución en la que se escribió el programa. Luego elijo " Depuración - Adjuntar al proceso " ;. Elegí "Transporte remoto (solo nativo sin autenticación)". Utilicé la IP correcta como calificador y tomé el proceso correcto (program.exe). Después de un tiempo, apareció el siguiente mensaje en una ventana emergente:

  

Excepción no controlada en 0x7c812a7b en program.exe: 0xE0434F4D: 0xe0434f4d

Puedo continuar o romperme; Al continuar, la excepción ocurre una y otra y otra vez. Entonces presioné break y se produjo el siguiente mensaje:

  

No se cargan símbolos para ningún marco de la pila de llamadas. El código fuente no se puede mostrar.

Answer 1

Asegúrese de copiar el archivo .PDB que se genera con su ensamblaje en la misma carpeta en la máquina remota. Esto permitirá al depurador recoger los símbolos de depuración.

Answer 2

1. Agregue una carpeta compartida en su máquina de desarrollo que apunte a la ubicación de los archivos .pdb
2. Configure una variable de entorno llamada _NT_SYMBOL_PATH en la máquina remota que apunta a la carpeta compartida en su máquina de desarrollo

El depurador remoto ahora buscará símbolos en su máquina de desarrollo. No es necesario copiarlos para cada compilación.

Ver MS Video aquí .

Comience a ver 8-9 minutos. Muestra cómo configurar el depurador remoto para cargar símbolos desde un disco compartido en su máquina de desarrollo.

¡Buena suerte!

Answer 3

• En el menú Herramientas en Visual studio 2010, elija Opciones.
• En el cuadro de diálogo Opciones, abra el nodo Depuración y luego haga clic en Generales.
• Marque Mostrar todas las configuraciones si es necesario y ubique Habilitar solo mi código (Solo administrado)
• Desactívelo y haga clic en Aceptar

Después de que pueda adjuntar el proceso remoto

Answer 4

La depuración remota en .NET no funcionará si no coloca los archivos .PDB en el mismo directorio donde existe el código depurado.

Si VS todavía no puede encontrar la fuente para la depuración, el código depurado y la fuente del proyecto VS no son la misma versión . La solución es reconstruir y volver a implementar el proyecto.

Answer 5

0xE0434F4D es una excepción del CLR (es decir, código administrado). Debe realizar la depuración remota con autenticación y elegir depurar el código administrado. Alternativamente, es posible extraer la información de excepción administrada usando algunas extensiones del depurador, pero es un trabajo un poco más duro.

Referencias:

Si está roto es ...

Answer 6

1800 INFORMACIÓN es correcto, debe realizar la depuración remota con la autenticación de Windows para depurar el código administrado, de lo contrario no podrá cargar los símbolos para los ensamblados administrados. Hacer que esto funcione con autenticación es bastante complicado, ya que requiere cuentas locales en ambas máquinas con contraseñas idénticas, entre otras cosas. Esta pregunta y las respuestas de todos son bastante útiles para que funcione.

Depuración remota en Visual Studio (VS2008), Windows Forms Aplicación

Answer 7

Tuve los mismos problemas. Encontré la respuesta en los foros msdn simplemente copiaré / pegaré la respuesta correcta aquí:

  

Asegúrese de estar usando el   versión correcta de msvsmon.exe !!!       ¡Eso fue todo! Tuve el mismo problema mientras depuraba remotamente un C #   solicitud. Estaba usando x64   msvsmon.exe porque el servidor se ejecuta   Windows Server 2008 de 64 bits, pero el   la aplicación fue escrita para x86, así que   tuvo que ejecutar la versión x86 de   msvsmon.exe para deshacerse de   Este error molesto.       No se necesitaba nada más. Simplemente ejecute la versión de msvsmon.exe que   corresponde a la arquitectura de destino   de su aplicación ^ _ ^

Answer 8

Si bien las respuestas anteriores son correctas, me encontré con instancias en las que los PDB que se construyeron con el ensamblaje que se está depurando estaban en su lugar en la ubicación remota y no se estaban recogiendo. Si está utilizando TFS u otro mecanismo de compilación que admita la publicación de sus símbolos de depuración, recomendaría hacerlo. Luego, en Visual Studio Options > Debugging > Symbols, puede agregar esa ubicación a la opción Servidores de símbolos para cargar esos símbolos en cualquier momento que coincidan.

Esto me ha permitido depurar casi todo lo que se está ejecutando que he escrito incluso si se trata de un ensamblado llamado dinámicamente (algo que no pude poner en práctica durante mi vida cuando solo publicaba símbolos con el ensamblaje). ¡Utiliza esta característica muy útil!

Answer 9

Pude hacer que esto funcionara yendo a Propiedades del proyecto, pestaña Compilar y configurando la ruta de salida de construcción a mi máquina remota, por ejemplo \ myserver \ myshare \ myappdir

En la pestaña de depuración, he seleccionado Usar máquina remota marcada y configurada en myserver

Answer 10

También me encontré con esto al usar una configuración de compilación personalizada . ( DEV en lugar de Debug )

Para corregir esto, modifiqué las Propiedades del proyecto - > Construir - > Salida - > Configuración avanzada y me aseguré de que la configuración Salida - > Información de depuración estuviera completa o < strong> pdb-only . La configuración predeterminada Release generalmente se establece en none .

Answer 11

Vaya a Herramientas- > Opciones- > Depuración- > Símbolos y agregue la ruta a los archivos .pdb para el ejecutable. El camino en mi máquina local funcionó bien.

Answer 12

De acuerdo con la documentación, para administrado (intenté conectarlo a un servicio administrado de Windows (construido contra .net 4.5) en una máquina remota con Visual Studio 2012) los símbolos deberían estar en la máquina remota .

Entonces, simplemente guardé los símbolos (asegúrese de que coincidan con los módulos / ensambles de la aplicación en la máquina remota) en la máquina remota, lo comparta y lo consulte a través de la configuración de símbolos del sistema local (donde vs se está ejecutando).

Nota: el servicio y los símbolos no necesitan estar en el mismo directorio que funciona para mí con el servicio de Windows 2k12 + .net 4.5.

para más detalles:

http://msdn.microsoft. com / es-us / library / bt727f1t (v = vs.100) .aspx

Extracto del enlace:

Ubicación de archivos de símbolos (.pdb)

---

Los archivos de símbolos contienen la información de depuración para los ejecutables compilados. Los archivos de símbolos de la aplicación a depurar deben ser los archivos que se crearon cuando se compilaron los ejecutables de la aplicación. Los archivos de símbolos también deben ubicarse donde el depurador pueda encontrarlos.

& # 8226; Los archivos de símbolos para aplicaciones nativas deben ubicarse en la computadora host de Visual Studio.

& # 8226; Los archivos de símbolos para aplicaciones administradas deben ubicarse en la computadora remota.

& # 8226; Los archivos de símbolos para aplicaciones mixtas (administradas y nativas) deben ubicarse tanto en la computadora host de Visual Studio como en la computadora remota.

Saludos

Answer 13

Me encontré con este problema y las soluciones anteriores no me lo solucionaron. En mi caso, mi solución VS2010 tenía muchos proyectos. El proyecto que intentaba depurar de forma remota no estaba configurado en mi solución VS2010 como StartUp Project, porque mis scripts de creación no eran del todo correctos.

Hice clic derecho en el proyecto dentro de mi solución que estaba tratando de depurar y seleccioné Establecer como proyecto de inicio y luego mis símbolos se cargaron correctamente y mi punto de interrupción fue alcanzado.

Answer 14

Tuve el mismo problema durante la depuración remota, se resolvió con los siguientes pasos en VS 2008:

1. copia el archivo pdb local junto con sus archivos binarios
2. Ejecute la misma versión de msvmon para la que se creó su aplicación. Si su aplicación está diseñada para la arquitectura x86, debe ejecutar la versión x86 de msvmon, incluso si la está ejecutando en una máquina x64. Le dará una advertencia cuando intente ejecutar, pero debería ejecutarse.