Visual Studio 2015 RTM - Le débogage ne fonctionne pas
J'ai installé VS 2015 RTM (rien d'autre) et je ne parviens pas à déboguer une solution, qu'il s'agisse d'une solution existante ou nouvelle (créée avec VS 2015 et compilée avec .Net Framework 4.6), elle ouvre uniquement un nouvel onglet dans VS appelé Mode de rupture avec le texte suivant: L'application est en mode de pause Votre application est entrée dans un état de rupture, mais aucun code en cours d'exécution n'est pris en charge et pris en charge par le débogage sélectionné. moteur (par exemple, seul le code d’exécution natif est en cours d’exécution) . Et si je vérifie la fenêtre du module Debug ->: VS2015Test.exe symboles chargés
Et il ne montre pas non plus la sortie sur la console (c'est une application console qui n'a que les lignes de code suivantes:
class Program
{
static void Main(string[] args)
{
Console.WriteLine("TEST");
Console.ReadKey();
}
}
J'ai essayé de réinstaller VS 2015, redémarré l'ordinateur, supprimé tous les fichiers de% temp%/AppData/Microsoft/Visual Studio/14, démarré VS en mode administrateur, mais rien ne semble fonctionner.
Cette option permet au débogage de fonctionner: Outils -> Options -> Débogage -> Utiliser le mode de compatibilité géré
^^ Mais cela ne peut pas être la solution pour utiliser un ancien/mode hérité.
BTW: Le débogage dans VS 2013 fonctionne bien.
Toute aide serait appréciée.
Dans mon cas, cette solution est utile:
Solution: Désactivez l'option "Just My Code" dans les paramètres de débogage/général.
Référence: c-sharpcorner
J'avais ce même problème avec VS2015. Je réinitialise les paramètres, comme suggéré, mais j'ai toujours des problèmes.
Ce que je devais faire pour résoudre ce problème était de cocher "Utiliser le mode de compatibilité géré" et "Utiliser le mode de compatibilité native". Je ne sais pas lequel de ces 2 est nécessaire, mais je ne vérifie plus le problème du mode Pause.
J'ai eu un problème très similaire récemment, lié aux paramètres de débogage.
D'abord, avez-vous essayé de réinitialiser tous vos paramètres? Je pense que cela peut être lié à cela puisque vous dites qu'il est indépendant du projet et que vous avez supprimé toutes les données d'application.
Outils-> Paramètres d'importation et d'exportation Wizard -> Réinitialiser tous les paramètres
Ne vous inquiétez pas, cela vous donne la possibilité d'enregistrer les paramètres actuels.
Deuxièmement, si cela échoue, je suggérerais de consulter le journal des événements.
Entrer en mode pause suggérerait que le DE (moteur de débogage) envoie un événement d'arrêt synchronisé à Visual Studio tel que IDebugExceptionEvent2 . Je regarderais le journal des événements pour des exceptions telles que des échecs lors du chargement des assemblys référencés (comme les runtimes .NET, etc.) ou des restrictions d'accès à l'environnement.
Quelque chose indique au débogueur d'arrêter votre application en cours d'exécution, il s'agit simplement de la trouver.
Je pensais publier ceci au cas où cela aiderait quelqu'un. J'ai installé une version propre de Win 10 et Visual Studio 2015, j'ai essayé de déboguer une solution existante et j'ai rencontré des problèmes. Suivi de quelques conseils énumérés ici et d'autres endroits, mais aucun n'a fonctionné.
Pour que le débogage fonctionne normalement, j'ai modifié la configuration de la solution juste en dessous des menus. Je l'avais déjà défini en mode Release, changé cela en Debug puis nettoyé/recompilé et hop, le débogage a commencé à fonctionner normalement. Voir l'image pour info:
Ma solution s’est soudainement arrêtée de fonctionner dans le débogage ..__ J'ai reçu un message lors du débogage . 
[Titre de la fenêtre] Microsoft Visual Studio [Instruction principale] Vous déboguez une version validée de NettoProWin.exe. L'utilisation de Just My Code avec les versions Release à l'aide des optimisations du compilateur entraîne une expérience de débogage dégradée (par exemple, les points d'arrêt ne seront pas touchés) . [Arrêter le débogage] [Désactiver uniquement mon code et continuer] [Continuer le débogage] [Continuer le débogage (ne plus demander)]
J'ai choisi de continuer à déboguer, mais cela ne fonctionnait toujours pas.
La solution était simple. Il est nécessaire dans les propriétés du projet -> dans la section de construction -> remote le contrôle "Code Optimiz" 
Vérifiez le "Type de code" avant de vous connecter à un processus. Par exemple, je devais passer de CoreCLR à la v4. *
J'ai eu un problème similaire à celui-ci lorsque j'ai essayé d'utiliser Debugger.Launch pour déboguer une application Web: la fenêtre JIT Debugger Selection (Sélection du débogueur JIT) n'apparaissait jamais. Je savais que le mécanisme de débogage de VS n’était pas un problème en soi, car il fonctionnait parfaitement avec une application de console.
Finalement, un collègue a mentionné un "paramètre de registre du débogueur global" qui a déclenché une ampoule.
J'utilisais DebugDiag de Microsoft il y a quelques mois pour résoudre le problème de plantage de IIS, et j'avais une règle enregistrée pour capturer IIS des vidages sur le crash, qui ont évidemment (rétrospectivement) enregistré le service de diagnostic de débogage comme débogueur pour w3wp Processus de travail IIS).
La suppression de la règle dans DebugDiag ou l'arrêt du service de diagnostic de débogage ("C:\Program Files\DebugDiag\DbgSvc.exe") a réactivé le débogage JIT de Visual Studio.
J'espère que ça aide quelqu'un.
J'ai désactivé le système de fichiers avast, puis tout a fonctionné normalement. avast-molette de réglage = protections actives - bouton du haut désactivé.
Même est requis pour publier des projets. Un vrai cauchemar
Uhg. J'ai frappé le bas de cette page alors j'ai commencé à déchirer mon projet. J'ai trouvé une solution à mon problème particulier.
Mon problème: Je ne pouvais pas atteindre le point de rupture dans un processus fileté. Rien d'extraordinaire, je commence juste un nouveau fil dans une application console et le débogueur ne s'est pas arrêté sur les points d'arrêt. J'ai remarqué que le fil était en cours de création, mais qu'il était bloqué dans les appels externes .Net Framework et plus particulièrement dans le ThreadStart_Context. Cela explique pourquoi mes points d'arrêt n'ont jamais été touchés, car .Net Framework est en train de bloquer quelque chose.
Le problème: J'ai trouvé que je pouvais résoudre ce problème en changeant mon code de démarrage. Pour une raison quelconque, j'avais un fichier program.cs qui contenait Main () et se trouvait dans la classe Program comme on peut s'y attendre pour une application console. À l'intérieur de Main (), j'instanciais une autre classe via ce code;
new SecondClass();
Cela fonctionne normalement et j'ai beaucoup d'autres projets avec des appels Threaded où cela fonctionne bien (bon, je ne les ai pas débogués depuis un certain temps alors peut-être qu'un service pack est arrivé et cause cette régression).
La solution: Déplacer Main () dans ma SecondClass et au lieu d’appeler le constructeur SecondClass via 'new SecondClass ()', mettez à jour le constructeur SecondClass afin qu’il soit une méthode statique standard, puis appelez-le depuis Main. Après avoir apporté ces modifications, je suis en mesure de déboguer le fil une fois de plus.
J'espère que cela t'aides.
Dans mon cas,
J'ai changé de plate-forme de x86 à x64 dans Debug Configuration Manager. Cela a fonctionné pour moi.
Après l'installation de vs 2017, lors du débogage de la solution, une erreur telle que "Webkit a cessé de fonctionner correctement; Visual Studio ne pourra plus déboguer votre application." , cela empêche de poursuivre le débogage. Pour résoudre ce problème, allez dans Outils-> Options-> Débogage-> Général puis désactivez le débogage javascript pour asp.net
J'ai changé ma cible de plate-forme de "Tout processeur" à "x64".
Paramètre disponible dans: Propriétés du projet -> Construire -> Général: "Platform Target"
J'utilise VS 2015.
Dans mon cas, j'ai trouvé dans la fenêtre de sortie un indice que l'exception qui a arrêté le débogueur était une exception ContextSwitchDeadlock, qui est cochée par défaut dans les paramètres d'exception. Cette exception se produit généralement après 60 secondes dans les applications de la console. Je viens de décocher l'exception et tout a bien fonctionné.
depuis l'Explorateur de solutions -> Web -> Propriétés
sélectionnez l'onglet Construire -> Liste déroulante Configuration:
Il suffit de changer votre configuration de "Release" à "Active (Debug)"
- Arrêtez le débogage.
- Editer le fichier csproj.user
- Trouver la section a écrit ci-dessous:
<SilverlightDebugging> True </ SilverlightDebugging>
- Changer la valeur en "Faux"
- Déchargez et rechargez votre projet dans Visual Studio.
- Parfois, il fallait fermer Visual Studio.
J'ai découvert que je devais accéder aux paramètres du projet -> Web et cocher la case Enable Edit and Continue. Je ne peux pas dire pourquoi il a été décoché au début, mais cela a résolu le problème pour moi . 
Nous avons eu ce problème, après avoir essayé toutes les autres options telles que la suppression du dossier .vs, le changement de nom du nom du dossier IISExpress, la mise à jour de divers paramètres de propriétés, etc., cela ne fonctionnait pas. Ce qui a bien fonctionné, cependant, a été de désinstaller IISExpress 10.0 et de le réinstaller en activant toutes les fonctionnalités liées à IIS à partir des fonctionnalités Windows. J'espère que ça aide quelqu'un.
J'ai eu le même problème. Dans mon cas, le dll que je tentais de déboguer a été installé dans le GAC. Si votre point d'arrêt de débogage frappe lorsque vous ne faites pas référence à un objet de l'assembly cible, mais pas lorsque vous faites référence à l'assembly, cela peut être le cas pour vous.
J'ai eu des problèmes similaires sur mon application svc exécutée sur visual studio 2015; la solution consistait à changer de plate-forme de solution de "Tout processeur" à "x86". Si vous ne voyez pas l'option x86, cliquez sur "Gestionnaire de configuration" et accédez à votre projet cible et modifier la plate-forme, vous devez sélectionner le menu déroulant, puis cliquer sur "Nouveau", dans la fenêtre contextuelle, cliquer sur la liste déroulante située sous "nouvelle plate-forme", sélectionner x86, enregistrer vos modifications et reconstruire (voir pièce jointe 
)
J'ai eu ce problème, et aucun des (nombreux) messages sur ici n'a aidé. La plupart des gens pointent vers des paramètres ou des options, l'activation du mode débogage, etc. Tout cela était déjà en place (je savais que ce n'était pas cela car cela fonctionnait bien hier).
Pour moi, il s’est avéré qu’il s’agissait d’un problème de référencement, une combinaison des DLL incluses était à blâmer. Je ne peux pas dire exactement quel était le problème, mais j'ai quelques classes qui ont étendu les classes de base d'un autre projet, une interface implémentée qui s'étend elle-même à partir d'une autre interface, etc.
Le test acide consistait à créer une nouvelle classe (dans mon cas, un test unitaire) au sein du même projet que celui ayant échoué à déboguer, puis à créer une méthode vide et à définir un point d'arrêt sur celle-ci. Cela a fonctionné, ce qui a validé le fait que mes paramètres/options/etc. étaient bons. J'ai ensuite copié dans le corps de la méthode qui a échoué à déboguer, et bien sûr la nouvelle méthode commence à échouer aussi.
Finalement, j'ai supprimé toutes les références et commenté toutes les lignes de ma méthode. En les rajoutant un par un, en vérifiant Debug à chaque étape, jusqu'à ce que je trouve le coupable. J'ai évidemment eu une référence voyous là quelque part ...
Un ami avait le même problème, il ne pouvait pas déboguer dans VS2015 mais c’était correct dans VS2013. (notre projet est en .Net v4.0)
Nous avons constaté que c’était l’option «Type de code» dans Debug/Attach to Process qui était définie sur «Géré (v3.5, v3.0, v2.0)» au lieu de «Géré (v4.5, v4.0 ) "