Problème de débogage lent dans Visual Studio

Dans Visual Studio, même après avoir écrit une seule ligne de retour dans une application de console C #, il me faudra une minute pour appuyer sur F5 pour exécuter le code actuel. F5 – Je mets un point d’arrêt sur la déclaration de retour dans la fonction principale). Je me demande ce qui ne va pas Une liste de contrôle? Merci!

J’utilise l’édition et le débogage de Visual Studio 2008 VSTS sous Windows Server 2003 x64.

merci d’avance, George

Vous devrez peut-être supprimer tous vos points d’arrêt – notez que vous devez cliquer sur le bouton “supprimer tous les points d’arrêt” (ou utiliser Ctrl-Shft-F9), et NE PAS simplement les supprimer un par un. Si Visual Studio a modifié vos parameters de solution, ce dernier ne fonctionnera pas. Vous devrez peut-être d’abord append un point d’arrêt pour que cela fonctionne (intelligent, hein?).

Si le pire est à venir, vous devrez peut-être supprimer votre fichier .suo et laisser Visual Studio en démarrer un nouveau. Notez toutefois que vous perdrez vos parameters de configuration de solution personnels (uniquement pour cette solution, pas pour d’autres). Toutefois, vous souhaiterez peut-être déplacer / renommer le fichier temporairement jusqu’à ce que vous déterminiez s’il s’agit ou non du problème. De cette façon, vous pouvez toujours le déplacer. J’ai vu certaines ressources en ligne recommander de supprimer (déplacer / renommer) le fichier .ncb également.

J’ai déjà vu ça avant. Essayez de supprimer tous vos points d’arrêt, puis définissez ceux que vous souhaitez. Hit F5. Est-ce plus rapide maintenant?

Je viens de remarquer que vous avez mentionné la création d’une fonctionnalité de débogage de source .NET. Essayez de désactiver cela, votre connectivité réseau au serveur source de Microsoft peut être lente. Désactivez également toute connectivité de serveur de symboles dans Outils> Options> Débogage> Symboles.

Essayez également de désactiver l’option “Activer l’évaluation des propriétés et les autres appels de fonctions implicites” dans Outils> Options> Débogage> Général.

Ou supprimez votre fichier .suo qui se trouve à côté de votre fichier de solution (.sln). Cela a résolu un problème que j’avais avec les sessions de débogage prenant beaucoup de temps pour démarrer et arrêter.

Eu ce problème Après avoir essayé tous les conseils énumérés et supprimé toutes les extensions visuelles de studio, nous avons finalement compris que IntelliTrace était en quelque sorte activé. Désactivation qui corrige tout.

http://msdn.microsoft.com/en-us/library/dd264948%28v=vs.100%29.aspx

Avez-vous beaucoup de points d’arrêt? Ceux-ci peuvent vraiment ralentir le temps de démarrage. Chaque fois qu’un nouveau module est chargé dans l’espace d’adressage du processus, ils doivent tous être vérifiés pour voir s’ils sont valides.

Accédez à tools / options / debugger / symbols et vérifiez si vous avez défini des symboles publics ou des chemins réseau UNC. Vérifiez également les outils / options / debugger / general pour voir si vous avez défini le serveur source.

Tous ces éléments peuvent affecter le débogage en fonction d’une vitesse réseau lente ou de serveurs indisponibles. Le délai d’attente de 5 minutes correspond aux délais d’attente du réseau.

Si rien n’est défini dans les options, vérifiez si vous disposez de la variable d’environnement _NT_SYMBOL_PATH.

Mon collègue avait une réponse très lente à Visual Studio, il a fallu quelques minutes pour effectuer une étape lors du débogage. La cause principale s’est avérée être un programme anti-virus (menacefire) qui est devenu fou pendant que VS fonctionnait. Tuer son processus a tout réglé immédiatement.

Dans mon cas, changer le symbole de débogage “Charger automatiquement le symbole pour” option de “tous les modules” à “uniquement les modules spécifiés” a résolu le problème. Vous pouvez modifier cette option depuis Outils -> Options -> Débogage -> Symboles

Une cause différente plus … Comment trouver le problème

Pour moi, c’était l’option ShowOtherThreadIpMarkers. Une valeur = 1 fait que vs (2010) ralentit insupportablement (3-5 secondes pour chaque étape de débogage. La valeur 0 est à nouveau rapide.

Quelle est cette option? Je n’ai aucune idée. Je n’ai pas pu le trouver via l’interface utilisateur vs. J’ai décoché toutes les options de débogage possibles et rien n’a fonctionné.

Je me suis donc rendu dans Import Export Settings et j’ai chargé mes anciens parameters. Je les ai enregistrés précédemment en remontant dans le temps jusqu’à ce que le vs soit à nouveau rapide, puis j’ai comparé les fichiers vssettings … etc, etc.

Je voudrais faire remarquer que si vous chargez les parameters alors que vous êtes en mode de débogage arrêté sur un point d’arrêt, ils entrent en vigueur immédiatement. Vous n’avez pas besoin d’arrêter le débogueur et de redémarrer.

Sur le blog de ScottGu, lié par Travis: «Un autre problème de performance dont j’ai entendu parler récemment est un problème que quelques personnes ont déclaré avoir rencontré avec le complément de la barre d’outils de Google. Débogueur Studio vers le navigateur Si vous constatez de longs délais dans le chargement de votre application Web et l’installation de la barre d’outils Google (ou d’autres barres d’outils), vous pouvez essayer de les désinstaller pour voir si cela est la cause du problème. ”

Assurez-vous de ne pas avoir de mappages réseau obsolètes sur des serveurs qui n’existent plus (les délais d’attente du réseau vous tueront). Ou utilisez quelque chose comme Process Monitor pour voir si un réseau (ou autre erreur de fichier) semble bloquer pendant longtemps.

Utilisez-vous un Symbol Server pour télécharger des symboles pour Windows DLL?

Si c’est le cas, désactivez-le car cela peut prendre du temps, mais je ne m’attendrais pas à ce que cela entraîne de longs délais dans une application de console de base.

Outils> Options> Débogage> Symboles

Je sais que c’est un vieux sujet mais pour ce que ça vaut …

J’ai constaté que si une fenêtre IE séparée était ouverte depuis longtemps, le débogage peut prendre une minute. Fermez toutes les fenêtres IE et le débogage démarre immédiatement.

Dans mon cas, la barre d’outils Google ralentissait mon débogage. gplus_notifications_gadget.html continue de continuer et de surcharger le débogueur. Je voulais conserver la barre d’outils Google car je l’utilise régulièrement. J’ai donc désactivé le bouton de notification G + (le petit bouton situé à côté du bouton de profil).

Exécuter sous le débogueur était à peu près 10 fois plus lent que sans le débogage.

Après avoir essayé toutes les solutions suggérées ici, j’ai parcouru tous les parameters du débogueur et activé / désactivé pour voir si cela faisait une différence.

Pour moi, la désactivation de l’ optimisation Suppress JIT sur la charge du module dans les parameters de débogage a considérablement amélioré les choses.

J’ai eu le même problème avec VS2010, avec une progression du code extrêmement lente (entre 3 et 10 secondes). Cependant, aucune des modifications de parameters ci-dessus n’a suffi. J’ai finalement trouvé la solution ultime, qui fonctionnerait dans tous les problèmes de publication ci-dessus: réinitialiser tous vos parameters, comme décrit ici .

Vous pouvez d’abord vouloir enregistrer une partie particulière de vos parameters, par exemple, j’ai d’abord enregistré mon thème de couleur (de type Solarized), puis l’ai restauré après la réinitialisation globale.

Pour moi, le paramètre qui a tué les performances (Windows 8, même suspendu sauf pour le mouvement de la souris) était UNCHECK “Casser tous les processus quand un processus est interrompu” dans Options -> Débogage -> Général.

J’espère que ça aide quelqu’un.

Juste une autre cause d’une expérience de débogage lente de Visual Studio …

Il y a longtemps, j’ai activé FusionLog pour voir ce qui causait un problème de liaison d’assemblage.

Assurez-vous de le désactiver après l’avoir utilisé. Pourquoi? Parce qu’il écrit beaucoup de données de journalisation sur le disque lorsqu’il est activé.

Ceci est la clé FusionLog sur le registre de regedit.exe [ regedit.exe ]:

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion 

Modifiez les ForceLog , LogImmersive et LogResourseBindings de 1 activé à 0 désactivé.

J’ai eu ce problème aussi, mais cela n’avait rien à voir avec les points d’arrêt dans mon cas. Ce sont les raccourcis de code que j’ai ajoutés dans la fenêtre des tâches:

http://www.customsoftwareframeworks.com/blog/longwaittimetoinsertoraddalineoftextbuginvisualstudio–tasklistwindow–lyhenaddingandremovelines

Je suis sûr qu’il y a d’autres façons de voir un problème comme celui-ci, mais il y a un bogue quelque part qui a causé ce problème pour moi … la suppression de toutes mes options aurait résolu ce problème, mais c’est quelque chose que je ne voulais pas faire. Alors, je l’ai débogué et écrit à ce sujet dans mon blog … votre problème ressemble au mien.

Merci.

Quelque chose qui a fonctionné pour moi est de s’assurer qu’il n’y a pas de points d’arrêt conditionnels. A part ça, j’ai réussi à corriger le débogage lent en redémarrant simplement Visual Studio et en n’ouvrant qu’une seule instance de Visual Studio à la fois. J’espère que ça aide quelqu’un …

J’ai eu un problème similaire et aucune des autres directives n’a semblé aider. J’avais redémarré en vain. J’avais supprimé tous les points d’arrêt, supprimé le fichier suo, vérifié que les symboles n’étaient pas chargés depuis des sources externes et vérifié qu’aucun chemin d’access à l’application n’était indisponible.

Ensuite, j’ai pensé à nettoyer la solution. J’ai remarqué dans la fenêtre de sortie que C # IntelliSense signalait un problème lors du nettoyage:

Un problème est survenu lors de la lecture des métadonnées de ‘{B0C3592F-F0D1-4B79-BE20-3AD610B07C23}’ (‘Le système ne trouve pas le fichier spécifié.’). IntelliSense peut ne pas fonctionner correctement tant que la solution n’est pas rechargée.

Dans ce cas, une fois que vous avez réellement découvert le message d’erreur, il vous indique exactement comment le résoudre. (Bon travail sur le texte d’erreur, travail médiocre sur la découvrabilité!) J’ai déchargé les projets de la solution, puis les ai rechargés. J’ai ensuite réussi à exécuter une solution propre. Cela a fonctionné, et le débogueur a également bien fonctionné.

HTH

La fermeture de la fenêtre “Autos” a amélioré le débogage pour moi en 2008 pour une grande solution native en c ++. Cacher cela ne fonctionnera pas, il doit être fermé.

J’ai connu le même ralentissement et la déconnexion du réseau a résolu le problème pour moi, comme d’autres commentaires et réponses l’ont indiqué (mais bien sûr, ce n’est pas la solution idéale).

Pour mon cas, cette simple modification a corrigé ma solution: Dans les propriétés du projet, sur l’onglet de débogage, j’ai désactivé “Activer le processus d’hébergement Visual Studio”. (Je cours VS2010)

Obtenez plus de mémoire et une HD plus rapide. Plus de détails ici .