la información de depuración no se puede encontrar o no coincide con Visual Studio’s

Copié un proyecto existente y cambié el nombre de la carpeta. Ahora recibo este error cuando bash comstackr la aplicación

debugging information cannot be found or does not match. No symbols loaded. Do you want to continue debugging ? 

Si hago clic en sí, comstack y funciona bien. Pero ahora tengo que lidiar con ese mensaje. Solo tengo curiosidad sobre lo que cambio en las propiedades de los proyectos para que pare.

La razón principal es que no tiene un pdb y un exe que coincidan.

Algunas posibles soluciones:

  • Está comstackndo en versión en lugar de depurar
  • Debes limpiar / construir o reconstruir
  • No tiene sus archivos pdb generados en el mismo directorio que el exe
  • Tiene un pdb que no coincide, tal vez la fuente copiada es más reciente que la fecha actual y algo no está funcionando correctamente.
  • Prueba a limpiar todos los archivos de objetos de depuración
  • Se está conectando a un proceso que comenzó desde una ubicación diferente desde donde existe su versión de comstackción y pdb
  • Reiniciar Visual Studio

Probablemente haya desactivado la información de depuración para su proyecto:

  • Haga clic derecho en su proyecto -> Propiedades
  • Propiedades de configuración -> Enlazador -> Depuración
  • Cambie “Generar información de depuración” de No a Sí

Reconstruye tu proyecto y vuelve a intentarlo, ahora debería ejecutarse sin el mensaje 🙂

Esto me sucede de vez en cuando, mientras depura el código y realiza cambios, parece que Visual Studio almacena en caché la información del pdb y, a veces, se atasca. Hacer una solución Rebuild, eliminar el pdb y crear uno nuevo no soluciona el problema.

Por supuesto, tengo la información de generación de depuración y todo lo que se necesita, especialmente dado que esto ocurre al depurar el código varias veces.

Visual Studio parece estar contento con el pdb en memoria y se niega a actualizarlo, independientemente de las marcas de tiempo o incluso los cambios de tamaño en el pdb.

La única manera de restablecer esto es salir de Visual Studio (el IDE) y reiniciarlo nuevamente.

En algunos casos raros, el IDE puede seguir ejecutándose en segundo plano (el explorador de procesos lo muestra allí) y puede mantener abierto el identificador del archivo. Puede matar el proceso antes de reiniciar el IDE.

Buena suerte

Acabo de encontrar este error en VS2012. Definitivamente es causado por un error en Visual Studio, que se revela en situaciones en las que el archivo PDB local del proyecto principal tiene el mismo nombre que el archivo final PDB para todo el ejecutable (¡incluso si los dos están ubicados en directorios diferentes!)

Considera este ejemplo.

La solución consiste en tres proyectos: main , a , y b . main es el proyecto de nivel superior para el ejecutable, mientras que a y b son bibliotecas vinculadas a main .

En los tres proyectos, la variable $(IntDir) se establece en $(SolutionDir)\$(Configuration)\$(ProjectName)\ . Esto significa que el proyecto main descarga sus archivos intermedios a Debug\main\ , project a – a Debug\a\ y así sucesivamente.

En C/C++ -> Output Files configuración de C/C++ -> Output Files los tres proyectos tienen Program Database File Name valor del Program Database File Name establecido en $(IntDir)$(TargetName).pdb . Esto significa que el proyecto main genera su archivo PDB local como Debug\main\main.pdb , proyecto b como Debug\b\b.pdb y así sucesivamente.

Finalmente, en Linker -> Debugging Configuración de Linker -> Debugging del proyecto main el valor Generate Program Database File se establece en $(OutDir)$(TargetName).pdb . Esto significa que el archivo PDB global para todo el ejecutable se generará como Debug\main.pdb .

Tenga en cuenta que en esta configuración cada archivo PDB se genera en su propio directorio separado.

En esta configuración obtendrá información de depuración que no se puede encontrar o no coincide con el error si intenta ejecutar el progtwig bajo el depurador. Y si Debug\main.pdb un vistazo al archivo Debug\main.pdb (que existirá), verás que es exactamente lo mismo que el archivo Debug\main\main.pdb . Es decir, de alguna manera el PDB local para main logró sobrescribir lo que se suponía que sería el PDB global para el ejecutable final. Es decir, el depurador tiene razón en quejarse de que el archivo PDB es “incorrecto”. De hecho, está mal.

De nuevo, en la configuración anterior, el PDB global final de alguna manera es sobreescrito por el PDB local del proyecto superior. No sé por qué sucede. Parece ser un error. (Tenga en cuenta que aunque estos archivos PDB tienen el mismo nombre, se generan en diferentes directorios, es decir, no deberían entrar en conflicto).

Una solución que soluciona este problema es dar al PDB local del proyecto main un nombre diferente. Por ejemplo, solo vaya a C/C++ -> Output Files para el proyecto main y cambie Program Database File Name valor del Program Database File Name a $(IntDir)$(TargetName)_local.pdb (o a $(IntDir)12345.pdb si así lo desea ) Esto eliminará el conflicto y resolverá el problema.

Enfrenté el mismo problema e intenté todas las soluciones mencionadas anteriormente, pero no pudo ayudarme. Luego encontré una nueva solución al azar y funcionó.

La solución es que, en caso de que tenga muchos proyectos en una solución, debe marcar cualquier proyecto (específico que tenga que decidir) como “Establecer como proyecto de inicio”. Haga clic derecho en ese proyecto específico y haga clic en “Establecer como proyecto de inicio”.

Funcionó para mí

Habilite la creación de PDB por:

Haga clic derecho en MyProject > Properties > Debugging :

  • C/C++ > General > Debug Information Output = Program Database (/Zi)
  • Linker > Debugging > Generate Debug Info = Yes (/DEBUG)

Limpiar MyProject, reiniciar Visual Studio (solo para estar seguro), reconstruir MyProject. La carpeta de salida debería contener archivos * .pdb.

Si depura el código optimizado / versión, considere desactivar la optimización a través de

  • C++ > Optimization > Optmization = Disabled (/Od)

Parece que falta el archivo pdb o la base de datos del progtwig (básicamente, la ruta ha cambiado y el comstackdor ya no puede encontrarla). Consulte esta publicación relacionada para obtener información adicional.

Tuve un problema similar y la razón fue que había ejecutado uno de los proyectos de mi solución en un proceso diferente y ese proceso no se pudo eliminar. No pensé mucho en eso. Entonces, cuando estaba construyendo la solución en un entorno separado, uno de los archivos pdb no coincidía, por lo que al final no pude cargar ninguno de los archivos pdb. Acabo de reiniciar mi computadora y eso lo solucionó.

Buena suerte

Reiniciar Visual Studio puede corregir una instancia de este problema.

Haga clic derecho en su proyecto en el navegador de soluciones => Limpiar => Construir. Eso es si su comstackción genera un .pdb en absoluto (busque en su directorio de destino) De lo contrario, debe habilitar la depuración siguiendo los pasos mencionados en otras publicaciones.

Lo más probable es que existan otras razones como la falta de coincidencia entre los archivos .pdb / .exe, algo no se creó / reconstruyó, pero tuve un caso similar en Visual Studio 2013 –

Algo relacionado con la función virtual en línea, así lo sospecho.

En mi caso, el depurador saltaba en medio de otra función de C ++, no la que se llamaba. Saltar fue el código fuente de 11 líneas de código fuente, pero no puedo explicar por qué ocurrió un error de cálculo. Mediante simples funciones de reorganización, me deshice de este problema.

Puede ser necesario un análisis más detallado por qué el cambio de 11 líneas ocurrió originalmente.

No he visto este tipo de comportamiento en ningún otro estudio visual.

Este problema me ha molestado por mucho tiempo. Anwser de AnT es muy útil. La idea principal es No tener dos archivos pdb con el mismo nombre , incluso si no están en el mismo directorio.

Esta es mi situación: tengo proyectos de remolque con el nombre “FooBar” y “FooBarDll”, el primero es un exe, y el segundo es un dll. Establecí que ambos proyectos Target Name sean “FooBar”, para que generen “FooBar.exe” y “FooBar.dll” respectivamente.

Luego establecí

  1. “General -> Directorio intermedio” para ser “$ (OutDir) \ $ (ProjectName) \”
  2. “C / C ++ -> Archivos de salida -> Nombre de archivo de base de datos de progtwig” to be “$ (IntDir) $ (TargetName) .pdb”
  3. “Enlazador -> Depuración -> Generar archivo de base de datos de progtwig” para ser “$ (OutDir) $ (TargetName) .pdb”

Entonces obtengo estos archivos:

  1. Debug \ FooBar.exe
  2. Debug \ FooBar.pdb // C ++ pdb
  3. Debug \ FooBar \ FooBar.pdb // Linker pdb

  4. Debug \ FooBar.dll

  5. Debug \ FooBar.pdb // C ++ pdb nuevamente!
  6. Debug \ FooBarDll \ FooBar.pdb // Linker pdb

Mi solución reemplaza cada “TargetName” con “ProjectName”, luego obtendré:

  1. Debug \ FooBar.exe
  2. Debug \ FooBar.pdb // C ++ pdb
  3. Debug \ FooBar \ FooBar.pdb // Linker pdb

  4. Debug \ FooBar.dll

  5. Debug \ FooBarDll.pdb // C ++ pdb
  6. Debug \ FooBarDll \ FooBarDll.pdb // Linker pdb

¡Entonces no hay conflicto!

Dar C / C ++ pdb un sufijo puede ser mejor, como: “C / C ++ -> Archivos de salida -> Nombre de archivo de base de datos de progtwig” to be “$ (IntDir) $ (ProjectName) _C.pdb”

Tuve el mismo problema, y ​​este enlace me ayudó a resolver el problema, al cambiar el nombre “symsrv.no” por “symsrv.yes” en la carpeta VS IDE.

Curioso, me pasa que necesitaba cambiar el nombre de la carpeta de:

 ...\Custom Librarry (MyDll.dll( 

a

 ...\Custom Librarry (MyDll.dll) 

¡Simplemente cerrando el paréntesis funcionó!