Pourquoi aucun symbole n'est-il chargé lors du débogage à distance?

Question

Je veux utiliser le débogage à distance. Le programme que je veux déboguer s'exécute sur la machine b. Visual Studio s'exécute sur la machine a.

Sur la machine b, j'ai un dossier contenant les fichiers suivants:

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

Si vous pensez que certains fichiers sont manquants, pouvez-vous également décrire leur emplacement habituel?

À l'étape suivante, j'ai lancé msvsmon.exe et mon programme sur la machine b. Sur une machine, j'ai lancé Visual Studio 2008 et ma solution dans laquelle le programme a été écrit. Ensuite, je choisis "Debug - Attach to Process". J'ai choisi "Transport à distance (natif uniquement sans authentification)". J'ai utilisé la bonne adresse IP comme qualificatif et pris le bon processus (programme.exe). Au bout d'un moment, le message suivant s'est affiché dans une fenêtre contextuelle:

  

Exception non gérée à 0x7c812a7b dans Program.exe: 0xE0434F4D: 0xe0434f4d

Je peux continuer ou faire une pause; En continuant, l'exception se produit encore et encore et encore. J'ai donc appuyé sur pause et le message suivant est apparu:

  

Aucun symbole n'est chargé pour un cadre de pile d'appels. Le code source ne peut pas être affiché.

Answer 1

Assurez-vous de copier le fichier .PDB généré avec votre assembly dans le même dossier sur la machine distante. Cela permettra au débogueur de récupérer les symboles de débogage.

Answer 2

1. Ajouter un dossier partagé sur votre machine dev qui pointe vers l'emplacement des fichiers .pdb
2. Configurez une variable d'environnement appelée _NT_SYMBOL_PATH sur la machine distante pointant vers le dossier partagé de votre machine dev
.

Le débogueur distant va maintenant rechercher des symboles sur votre machine de développement. Pas besoin de les copier pour chaque build.

Voir la vidéo MS ici .

Commencez à regarder 8-9 minutes. Il explique comment configurer le débogueur distant pour charger les symboles à partir d'un partage de disque sur votre ordinateur de développement.

Bonne chance!

Answer 3

• Dans le menu Outils de Visual studio 2010, choisissez Options.
• Dans la boîte de dialogue Options, ouvrez le nœud de débogage, puis cliquez sur Généraux.
• Cochez Afficher tous les paramètres si nécessaire et localisez Activer uniquement mon code . (Géré uniquement)
• Décochez-la , puis cliquez sur OK
.

Une fois que vous pouvez attacher le processus distant

Answer 4

Le débogage distant dans .NET ne fonctionnera pas si vous ne placez pas les fichiers .PDB dans le même répertoire où le code débogué existe.

Si VS ne parvient toujours pas à trouver la source pour le débogage, le code de débogage et la source du projet VS ne sont pas la même version . La solution est en train de reconstruire et de redéployer le projet.

Answer 5

0xE0434F4D est une exception du CLR (code géré, par exemple). Vous devez effectuer un débogage à distance avec authentification et choisir de déboguer le code géré. Il est également possible d'extraire les informations sur les exceptions gérées à l'aide de certaines extensions du débogueur, mais le travail est un peu plus dur.

Références:

Si elle est brisée, elle est ...

Answer 6

1800 INFORMATION est correct, vous devez effectuer un débogage à distance avec une authentification Windows pour pouvoir déboguer le code géré, sinon vous ne pourrez pas charger les symboles des assemblys gérés. Le faire fonctionner avec l'authentification est assez délicat, car cela nécessite, entre autres, des comptes locaux sur les deux machines avec des mots de passe identiques. Cette question et les réponses de chacun sont très utiles pour que cela fonctionne.

Débogage distant dans Visual Studio (VS2008), Windows Forms Application

Answer 7

J'ai eu les mêmes problèmes. Trouvé la réponse sur le msdn forums Je vais simplement copier / coller la bonne réponse ici:

  

Assurez-vous que vous utilisez le   version correcte de msvsmon.exe !!!       C'est tout ce que c'était! J'ai eu le même problème lors du débogage à distance d'un C #   application. J'utilisais x64   msvsmon.exe parce que le serveur s'exécute   Windows Server 2008 64 bits, mais le   application a été écrite pour x86, donc je   dû exécuter la version x86 de   msvsmon.exe afin de se débarrasser de   cette erreur agaçante.       Rien d'autre n'était nécessaire. Il suffit d’exécuter la version de msvsmon.exe qui   correspond à l'architecture cible   de votre application ^ _ ^

Answer 8

Bien que les réponses ci-dessus soient correctes, j’ai rencontré des cas dans lesquels les PDB construits avec un assemblage en cours de débogage étaient en place sur le site distant et n’avaient pas été récupérés. Si vous utilisez TFS ou un autre mécanisme de génération prenant en charge la publication de vos symboles de débogage, je vous recommande de le faire. Ensuite, dans Options > Débogage> Symboles de Visual Studio, vous pouvez ajouter cet emplacement à l'option Serveurs de symboles pour charger ces symboles à chaque fois qu'ils correspondent.

Cela m’a permis de déboguer maudit près de tout ce qui est en cours d’exécution que j’ai écrit, même s’il s’agit d’un assemblage appelé dynamiquement (quelque chose que je ne pouvais pas travailler pendant toute ma vie lorsque je ne publiais que des symboles avec l’assemblage). Utilisez cette fonctionnalité très pratique!

Answer 9

J'ai pu le faire en accédant à Propriétés du projet, onglet Compiler et en définissant le chemin de sortie de la construction vers ma machine distante, par exemple \ myserver \ myshare \ myappdir

Dans l'onglet de débogage, l'option Utiliser l'ordinateur distant est cochée et configurée sur myserver

Answer 10

J'ai également rencontré ce problème lors de l'utilisation d'une configuration de construction personnalisée. ( DEV au lieu de Debug )

Pour corriger cela, j'ai modifié le paramètre Propriétés du projet - > Construire - > Sortie - > Options avancées et veillé à ce que le paramètre Sortie - > Informations de débogage soit saturé ou < strong> pdb uniquement . La configuration Par défaut par défaut est généralement définie sur aucune .

Answer 11

Accédez à Outils> Options> > Débogage - > Symboles , puis ajoutez le chemin d'accès aux fichiers .pdb de l'exécutable. Le chemin sur ma machine locale a bien fonctionné.

Answer 12

Selon la documentation, pour les ordinateurs gérés (j'ai essayé de me connecter à un service Windows géré (construit contre .net 4.5) sur une machine distante avec Visual Studio 2012), les symboles devraient être sur la machine distante .

Alors, j'ai juste gardé les symboles (assurez-vous qu'ils correspondent aux modules / assemblages de l'application sur la machine distante) sur la machine distante, partagez-les et faites-y référence via les paramètres de symboles du système local (où vs est en cours d'exécution).

Remarque: le service et les symboles ne doivent pas obligatoirement figurer dans le même répertoire, car ils fonctionnent correctement pour moi avec le service Windows 2k12 + .net 4.5.

pour plus de détails:

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

Extrait du lien:

Localisation de fichiers de symboles (.pdb)

Les fichiers de symboles contiennent les informations de débogage pour les exécutables compilés. Les fichiers de symboles de l'application à déboguer doivent être les fichiers créés lors de la compilation des exécutables de l'application. Les fichiers de symboles doivent également être situés où le débogueur peut les trouver.

& # 8226; Les fichiers de symboles pour les applications natives doivent être situés sur l'ordinateur hôte Visual Studio.

& # 8226; Les fichiers de symboles des applications gérées doivent se trouver sur l'ordinateur distant.

& # 8226; Les fichiers de symboles pour les applications mixtes (gérées et natives) doivent être situés à la fois sur l'ordinateur hôte Visual Studio et sur l'ordinateur distant.

Cordialement!

Answer 13

J'ai rencontré ce problème et les solutions ci-dessus ne m'ont pas résolu le problème. Dans mon cas, ma solution VS2010 comportait de nombreux projets. Le projet que j'essayais de déboguer à distance n'était pas défini dans ma solution VS2010 en tant que projet StartUp, car mes scripts de création n'étaient pas tout à fait corrects.

J'ai cliqué avec le bouton droit de la souris sur le projet dans ma solution que j'essayais de déboguer et j'ai sélectionné Définir comme projet de démarrage , puis mes symboles ont été chargés correctement et mon point d'arrêt a été touché.

Answer 14

J'ai eu le même problème lors du débogage à distance, il a été résolu en suivant les étapes suivantes sur VS 2008:

1. vous copiez le fichier pdb local avec vos fichiers binaires
2. Exécutez la même version de msvmon pour laquelle votre application a été créée. Si votre application est conçue pour une architecture x86, vous devez exécuter la version x86 de msvmon, même si vous l'exécutez sur une machine x64. Cela vous avertira quand vous essayez de courir, mais ça devrait marcher.