J'ai copié un projet existant et renommé le dossier. Maintenant, je reçois cette erreur lorsque j'essaie de compiler l'application
les informations de débogage sont introuvables ou ne correspondent pas. Aucun symbole chargé.
Voulez-vous continuer le débogage?
Si je clique sur oui, il se compile et fonctionne correctement. Mais maintenant, je dois faire face à ce message. Je suis juste curieux de savoir ce que je change dans les propriétés du projet pour l'arrêter.
La raison principale est que vous n'avez pas de pdb et d'exe correspondants.
Quelques solutions possibles:
Vous avez probablement désactivé les informations de débogage de votre projet:
Reconstruisez votre projet et réessayez, il devrait maintenant s'exécuter sans le message :)
Cela m'arrive de temps en temps, alors que le débogage du code et les modifications, il semble que Visual Studio met en cache les informations PDB et parfois il se bloque. Faire une solution de reconstruction, supprimer la pdb et en créer une nouvelle ne résout pas le problème.
Bien sûr, j'ai les informations de génération de débogage et tout ce dont il a besoin, d'autant plus que cela se produit lors du débogage du code plusieurs fois.
Visual Studio semble être satisfait de la pdb en mémoire et refuse de la mettre à jour, indépendamment des horodatages ou même des changements de taille dans la pdb.
La seule façon de réinitialiser cela est de quitter Visual Studio (l'EDI) et de le redémarrer à nouveau.
Dans certains cas rares, le IDE peut toujours être exécuté en arrière-plan (l'Explorateur de processus l'affiche) et peut maintenir le descripteur du fichier ouvert. Vous pouvez tuer le processus avant de redémarrer l'IDE.
Bonne chance
Je viens de rencontrer cette erreur dans VS2012. Il est définitivement causé par un bogue dans Visual Studio, qui se révèle dans des situations où le fichier PDB local du projet principal a le même nom que le fichier PDB final pour l'exécutable entier (même si les deux se trouvent dans des répertoires différents!)
Considérez cet exemple.
La solution se compose de trois projets: main
, a
et b
. main
est le projet de niveau supérieur pour l'exécutable, tandis que a
et b
sont des bibliothèques liées à main
.
Dans les trois projets, la variable $(IntDir)
est définie sur $(SolutionDir)\$(Configuration)\$(ProjectName)\
. Cela signifie que le projet main
transfère ses fichiers intermédiaires vers Debug\main\
, Le projet a
- vers Debug\a\
Et ainsi de suite.
Dans les paramètres C/C++ -> Output Files
, Les trois projets ont la valeur Program Database File Name
Définie sur $(IntDir)$(TargetName).pdb
. Cela signifie que le projet main
génère son fichier PDB local comme Debug\main\main.pdb
, Le projet b
comme Debug\b\b.pdb
Et ainsi de suite.
Enfin, dans les paramètres Linker -> Debugging
Du projet main
, la valeur Generate Program Database File
Est définie sur $(OutDir)$(TargetName).pdb
. Cela signifie que le fichier PDB global pour l'ensemble de l'exécutable sera généré sous la forme Debug\main.pdb
.
Notez que dans cette configuration, chaque fichier PDB est généré dans son propre répertoire distinct.
Dans cette configuration, vous obtiendrez les informations de débogage sont introuvables ou ne correspondent pas erreur si vous essayez d'exécuter le programme sous le débogueur. Et si vous regardez le fichier Debug\main.pdb
(Qui existera), vous remarquerez qu'il est exactement le même que le fichier Debug\main\main.pdb
! C'est à dire. d'une manière ou d'une autre, la PDB locale de main
a réussi à remplacer ce qui était censé être la PDB globale de l'exécutable final. C'est à dire. le débogueur a raison de se plaindre que le fichier PDB est "incorrect". C'est vraiment faux.
Encore une fois, dans la configuration ci-dessus, la PDB globale finale est en quelque sorte remplacée par la PDB locale du projet supérieur. Je ne sais pas pourquoi ça arrive. Il semble que ce soit un bug. (Notez que même si ces fichiers PDB ont le même nom, ils sont générés dans des répertoires différents, c'est-à-dire qu'ils ne devraient pas entrer en conflit.)
Une solution de contournement qui résout ce problème consiste à donner à la PDB locale du projet main
un nom différent. Par exemple, allez simplement dans C/C++ -> Output Files
Pour le projet main
et changez la valeur de Program Database File Name
En $(IntDir)$(TargetName)_local.pdb
(ou en $(IntDir)12345.pdb
si vous si désir). Cela éliminera le conflit et résoudra le problème.
Activez la création de PDB en:
Clic droit sur MyProject > Properties > Debugging
:
C/C++ > General > Debug Information Output = Program Database (/Zi)
Linker > Debugging > Generate Debug Info = Yes (/DEBUG)
Nettoyez MyProject, redémarrez Visual Studio (juste pour être sûr), reconstruisez MyProject. Le dossier de sortie doit alors contenir des fichiers * .pdb.
Si vous déboguez du code optimisé/de sortie, pensez à désactiver l'optimisation via
C++ > Optimization > Optmization = Disabled (/Od)
J'ai fait face au même problème et j'ai essayé toutes les solutions mentionnées ci-dessus, mais cela ne pouvait pas m'aider. Ensuite, j'ai trouvé une nouvelle solution au hasard et cela a fonctionné.
La solution est que, dans le cas où vous avez plusieurs projets dans une solution, vous devez marquer n'importe quel projet (spécifique que vous devez décider) comme un "Définir comme projet de démarrage". Faites un clic droit sur ce projet spécifique et cliquez sur "Définir comme projet de démarrage".
Ça a marché pour moi.
Le fichier pdb
ou la base de données du programme semble être manquant (en gros, le chemin a changé et ne peut plus être trouvé par le compilateur). Voir this poste connexe pour plus d'informations.
Faites un clic droit sur votre projet dans le navigateur de solutions => Nettoyer => Construire. C'est si votre build génère un .pdb (regardez dans votre répertoire cible) Sinon, vous devez activer le débogage en suivant les étapes mentionnées dans d'autres articles
J'ai eu un problème similaire et la raison en était que j'avais exécuté l'un des projets de ma solution dans un processus différent et que ce processus ne pouvait pas être tué. Je n'y pensais pas beaucoup. Donc, lorsque je construisais la solution dans un environnement séparé, l'un des fichiers pdb ne correspondait pas, donc à la fin je n'ai pu charger aucun des fichiers pdb. Je viens de redémarrer mon ordinateur et cela l'a corrigé.
Bonne chance
Ce problème me dérange depuis longtemps. La réponse d'AnT est très utile. L'idée principale est Ne pas avoir deux fichiers pdb portant le même nom, même s'ils ne sont pas dans le même répertoire.
Voici ma situation: j'ai des projets de remorquage nommés "FooBar" et "FooBarDll", le premier est un exe et le second est une dll. J'ai défini les deux projets Nom de la cible sur "FooBar", afin qu'ils génèrent respectivement "FooBar.exe" et "FooBar.dll".
Ensuite, je mets
Je reçois donc ces fichiers:
Debug\FooBar\FooBar.pdb // Linker pdb
Debug\FooBar.dll
Ma solution remplace chaque "TargetName" par "ProjectName", alors j'obtiendrai:
Debug\FooBar\FooBar.pdb // Linker pdb
Debug\FooBar.dll
Alors il n'y a pas de conflit!
Donner un suffixe à C/C++ pdb peut être mieux, comme: "C/C++ -> Fichiers de sortie -> Nom du fichier de base de données du programme" à "$ (IntDir) $ (ProjectName) _C.pdb"
Il y a très probablement d'autres raisons comme la non-concordance des fichiers .pdb/.exe, quelque chose n'a pas été construit/reconstruit, mais j'ai eu un cas similaire dans Visual studio 2013 -
Quelque chose à voir avec la fonction virtuelle en ligne - donc je suppose.
Dans mon cas, le débogueur sautait au milieu d'une autre fonction C++, pas celle qui était appelée. Jump était hors du code source par 11 lignes de code source, mais je ne peux pas expliquer pourquoi une erreur de calcul s'est produite. Par de simples fonctions de réorganisation, je me suis débarrassé de ce problème.
Peut être besoin d'une analyse plus détaillée de la raison pour laquelle le décalage de 11 lignes s'est produit à l'origine.
Je n'ai vu ce genre de comportement dans aucun autre studio visuel.
J'ai eu le même problème, et cela lien m'a aidé à résoudre le problème, en renommant "symsrv.no" en "symsrv.yes" dans VS IDE.
Le redémarrage de Visual Studio peut résoudre une instance de ce problème.