¿Por qué no se cargan símbolos cuando se realiza una depuración remota?

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

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

Ver MS Video aquí.

Comienza a ver 8-9 minutos. Demuestra cómo configurar el depurador remoto para que se cargue símbolos de una unidad compartida en su máquina de desarrollo.

¡Buena suerte!

• En el menú Herramientas de Visual studio 2010, seleccione Opciones.
• En el cuadro de diálogo Opciones, abra el nodo Depuración y haga clic en Generales.
• Marque Mostrar todas las configuraciones si es necesario y localice Habilitar solo Mi código (Gestionado únicamente)
• Desmarque y haga clic en Aceptar

Después de que pueda adjuntar el proceso remoto

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

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

0xE0434F4D es una excepción al 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 de depurador, pero es un trabajo un poco más duro.

Referencias:

Si está roto...

La INFORMACIÓN de 1800 es correcta, tiene que hacer depuración remota con autenticación de Windows para depurar el código administrado, de lo contrario no podrá cargar los símbolos de los ensamblados administrados. Hacer que esto funcione con la 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 muy útiles para que funcione.

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

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

Asegúrese de que está utilizando el versión correcta de msvsmon.exe!!! ¡Eso fue todo! tuve el mismo problema mientras que la depuración remota de un C# aplicación. Yo estaba usando x64 msvsmon.exe porque el servidor se ejecuta Windows Server 2008 64-bit, pero el la aplicación fue escrita para x86, así que tuvo que ejecutar la versión x86 de msvsmon.exe con el fin de deshacerse de este molesto error. No se necesitaba nada más. Simplemente ejecute la versión de msvsmon.exe que corresponde a la arquitectura de destino de su solicitud ^_^

Si bien las respuestas anteriores son correctas, me encontré con casos en los que los PDBs 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, le recomendaría hacerlo. Luego, en Opciones de Visual Studio>Depuración > Símbolos, puede agregar esa ubicación a la opción Servidores de símbolos para cargar esos símbolos cada vez que se encuentren coincidentes.

Esto tiene me permitió depurar casi cualquier cosa que se esté ejecutando que haya escrito, incluso si se trata de un ensamblado dinámicamente llamado (algo que no pude conseguir para mi vida cuando solo publicaba símbolos con el ensamblado). Hacer uso de esta característica muy útil!

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

En la pestaña de depuración he comprobado Usar máquina remota y establecido en myserver

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

Para corregir esto, modificé la configuración de Propiedades del proyecto Properties>Construir Output>Salida Advanced>Avanzada y me aseguré de que la configuración de Información de depuración de salida fuera completa o solo pdb. La configuración predeterminada Release se establece típicamente en none.

De acuerdo con la documentación, para managed (he intentado conectar a un servicio de Windows administrado (construido contra.net 4.5) en una máquina remota con visual studio 2012) los símbolos deben ser en la máquina remota.

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

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

Para más detalles:

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

Extracto del enlace:

Símbolo de localización (.pdb) Files

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

•Los archivos de símbolos para aplicaciones nativas deben estar ubicados en el equipo host de Visual Studio.

•Los archivos de símbolos de las aplicaciones administradas deben estar ubicados en el equipo remoto.

•Los archivos de símbolos para aplicaciones mixtas (administradas y nativas) deben estar ubicados tanto en el equipo host de Visual Studio como en el equipo remoto.

Saludos!

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