Problème de débogage lent dans Visual Studio
Dans mon Visual Studio, même si je venais d'écrire une seule ligne de retour dans une application console C #, il me faudra une minute après avoir appuyé sur F5 pour exécuter le code réel (je parle du temps qu'il faut pour s'arrêter sur une seule instruction de retour F5 - J'ai défini un point d'arrêt sur l'instruction return dans la fonction Main). Je me demande ce qui ne va pas? Une liste de contrôle? Merci!
J'utilise l'édition Visual Studio 2008 VSTS et le débogage 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 utilisez Ctrl-Shft-F9),NOT, supprimez-les un à un. Si Visual Studio a altéré les paramètres de votre solution, ceux-ci ne fonctionneront pas. Vous devrez peut-être d'abord ajouter un point d'arrêt pour que cela fonctionne (astucieux, hein?).
Dans le pire des cas, vous devrez peut-être supprimer votre fichier .suo et laisser Visual Studio en démarrer un nouveau à partir de zéro. Notez que vous perdrez toutefois les paramètres de configuration de votre solution personnelle (uniquement pour cette solution, pas pour les 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. Certaines ressources en ligne recommandent également de supprimer (déplacer/renommer) le fichier .ncb.
J'ai déjà vu cela auparavant. 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 configuration de la fonctionnalité de débogage 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 "Activer l'évaluation des propriétés et d'autres appels de fonction implicites" dans Outils> Options> Débogage> Général.
Ou supprimez votre fichier .suo qui se trouve à côté de votre fichier solution (.sln) . Ceci résout un problème que je rencontrais avec le démarrage et l’arrêt des sessions de débogage.
Avait ce problème. Après avoir essayé tous les conseils énumérés et supprimé toutes les extensions de Visual Studio, nous avons finalement compris qu'IntelliTrace était activé. Désactiver cela a tout corrigé.
http://msdn.Microsoft.com/en-us/library/dd264948%28v=vs.100%29.aspx
Avez-vous beaucoup de points d'arrêt définis? 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, vous devez tous les vérifier pour vérifier leur validité.
Accédez à outils/options/débogueur/symboles et vérifiez si vous avez défini des symboles publics ou des chemins réseau UNC. Vérifiez également tools/options/debugger/general pour voir si vous avez défini le serveur source.
Tous ces facteurs peuvent affecter le débogage en fonction d'une vitesse de réseau lente ou de serveurs indisponibles. Le temps 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 la variable d'environnement _NT_SYMBOL_PATH est définie.
Mon collègue avait un Visual Studio qui répondait très lentement, il fallait littéralement quelques minutes pour exécuter une étape lors du débogage. La cause fondamentale en est un programme anti-virus (anti-virus) (menacefire) devenu fou pendant que VS fonctionnait. Tuer son processus a immédiatement tout réglé.
Dans mon cas, le remplacement du symbole de débogage "Charger automatiquement le symbole pour" de "tous les modules" par "uniquement des modules spécifiés" a résolu le problème. Vous pouvez modifier cette option dans 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 rend vs (2010) insupportablement lent (3-5 secondes pour chaque étape de débogage. Avec une valeur de 0, c'est de nouveau rapide.
Quelle est cette option? Je n'ai aucune idée. Je ne pouvais pas le trouver à travers l'interface utilisateur vs .. .. J'ai décoché toutes les options de débogage possibles et rien ne fonctionnait.
Je suis donc allé dans Importer les paramètres d’exportation et chargé mes anciens paramètres que j’avais enregistrés précédemment, en remontant dans le temps jusqu’à ce que vs redevienne rapide, puis en comparant les fichiers vssettings, etc.
Je voudrais faire remarquer que si vous chargez les paramètres alors que vous êtes en mode débogage arrêté sur un point d'arrêt, ils prennent effet immédiatement. Vous n'avez pas à arrêter le débogueur et à redémarrer.
Sur le blog de ScottGu, lié par Travis: "Une autre performance dont j'ai entendu parler récemment est un problème que quelques personnes ont signalé rencontrer avec le complément Google Toolbar. Débogueur Studio au navigateur. Si le chargement de votre application Web prend du temps et que la barre d’outils Google (ou d’autres barres d’outils) est installée, essayez de les désinstaller pour voir si c’est la cause du problème. "
Encore une cause de lenteur dans le débogage de Visual Studio ...
Il y a longtemps, j'ai activé FusionLog pour voir ce qui causait un problème de liaison à l'Assemblée.
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 alors qu'il est activé.
Ceci est la clé FusionLog dans le registre de Windows [regedit.exe]:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
Modifiez les valeurs ForceLog, LogImmersive et LogResourseBindings de 1 activé à 0 désactivé.
Courir sous le débogueur pour moi était environ 10 fois plus lent que courir sans déboguer.
Après avoir essayé toutes les solutions suggérées ici, j'ai parcouru tous les paramètres du débogueur et activé/désactivé pour voir si cela faisait une différence.
Pour moi, il s’est avéré que désactiver Supprimer l’optimisation JIT lors du chargement du module dans les paramètres de débogage massivement a amélioré les choses.
J'ai eu le même problème dans VS2010, avec l'insertion du code extrêmement lent (entre 3 et 10 secondes). Cependant, aucune des modifications de paramètres ci-dessus n’a été une solution… j’ai finalement trouvé la solution ultime, qui fonctionnerait dans tous les numéros ci-dessus: réinitialisez tous vos paramètres, comme décrit ici .
Vous voudrez peut-être tout d’abord enregistrer une partie particulière de vos paramètres. Par exemple, j’ai tout d’abord enregistré mon thème de couleur (semblable à Solarized), puis je l’ai restauré après la réinitialisation globale.
Assurez-vous de ne pas avoir de mappages réseau obsolètes vers des serveurs qui n'existent plus (les délais d'attente réseau vous tueront). Ou utilisez quelque chose comme Process Monitor pour voir si un réseau (ou une autre erreur de fichier) semble bloquer depuis longtemps.
Utilisez-vous un serveur de symboles pour télécharger des symboles pour les DLL Windows?
Si tel est le cas, désactivez-le car cela peut prendre un certain temps, mais je ne m'attendrais pas à ce que cela provoque de longs délais dans une application de console de base.
Outils> Options> Débogage> Symboles
Dans mon cas, la barre d’outils de Google ralentissait mon débogage. gplus_notifications_gadget.html continuait à surcharger le débogueur. Je souhaitais conserver la barre d'outils Google, car je l'utilise régulièrement. Je viens donc de désactiver le bouton de notification G + (le petit bouton situé à côté du bouton du profil). Il est heureux maintenant.
Pour moi, le paramètre qui a tué les performances (Windows 8 même suspendu sauf pour le mouvement de la souris) était de décocher "Interrompre tous les processus lorsqu'un processus est interrompu" dans Options -> Débogage -> Général.
J'espère que cela aide quelqu'un.
Je sais que c'est un sujet ancien mais pour ce que ça vaut ...
J'ai constaté que si une fenêtre séparée IE était ouverte depuis longtemps, le démarrage du débogage peut prendre jusqu'à une minute. Fermez toutes les fenêtres IE et le débogage commence immédiatement.
Quelque chose a fonctionné pour moi est de s'assurer qu'il n'y a pas de points de rupture conditionnels. À part cela, j’ai réussi à corriger le débogage lent en redémarrant Visual Studio et en n’ouvrant qu’une instance de Visual Studio à la fois. J'espère que ça aide quelqu'un ...
La fermeture de la fenêtre "Autos" a amélioré le débogage pour moi dans vs2008 pour une grande solution c ++ native. Le cacher ne fonctionnera pas, il doit être fermé.
J'ai eu un problème similaire et aucun des autres conseils 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 à partir de sources externes et vérifié qu'aucun chemin d'accès n'était disponible dans l'application.
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 peut pas trouver le fichier spécifié.'). IntelliSense peut ne pas travailler correctement jusqu'à ce que la solution soit rechargé.
Dans ce cas, une fois que vous avez découvert le message d'erreur, il vous explique exactement comment le résoudre. (Bon travail sur le texte d'erreur, travail médiocre sur la possibilité de découverte!) 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
J'ai eu ce problème aussi, mais cela n'avait rien à voir avec les points d'arrêt dans mon cas. Ce sont des raccourcis de code que j'ai ajoutés dans la fenêtre des tâches:
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 me l'a causé ... supprimer toutes mes options aurait résolu ce problème, mais c'est quelque chose que je ne voulais pas. faire. Donc, je l'ai débogué et écrit à ce sujet dans mon blog ... votre problème a l'air d'être le mien.
Merci.
J'ai connu le même ralentissement, et la déconnexion du réseau a corrigé le problème, comme l'ont indiqué d'autres commentaires et réponses (mais ce n'est évidemment pas une solution idéale).
Dans mon cas, cette simple modification a corrigé ma solution: dans les propriétés du projet de l'onglet Débogage, j'ai désactivé "Activer le processus d'hébergement Visual Studio". (Je cours VS2010)