Langsames Debugging-Problem in Visual Studio

Selbst wenn ich in meiner Visual Studio-Instanz nur eine einzelne Rückgabezeile in einer C # -Konsolenanwendung geschrieben habe, F5dauert es eine Minute nach dem Drücken , um den eigentlichen Code auszuführen (ich meine die Zeit, die benötigt wird, um die einzelne return-Anweisung danach anzuhalten Drücken von F5- Ich habe einen Haltepunkt für die return-Anweisung in der mainFunktion gesetzt. Was ist falsch? Gibt es eine Checkliste?

Ich verwende Visual Studio 2008 VSTS Edition und debugge unter Windows Server 2003 x64.

Möglicherweise müssen Sie alle Ihre Haltepunkte löschen. Beachten Sie, dass Sie auf die Schaltfläche "Alle Haltepunkte löschen " klicken müssen (oder Ctrl+ Shift+ verwenden müssen F9) und sie NICHT einfach einzeln löschen müssen. Wenn Visual Studio Ihre Lösungseinstellungen entstellt hat, funktionieren letztere nicht. Möglicherweise müssen Sie zuerst einen Haltepunkt hinzufügen, damit dies funktioniert (clever, wie?).

Im schlimmsten Fall müssen Sie möglicherweise Ihre .suoDatei löschen und Visual Studio eine neue von Grund auf neu starten lassen. Beachten Sie jedoch, dass Sie Ihre persönlichen Lösungskonfigurationseinstellungen verlieren (nur für diese Lösung, keine anderen). Möglicherweise möchten Sie die Datei jedoch vorübergehend verschieben / umbenennen, bis Sie feststellen, ob dies das Problem ist oder nicht. Auf diese Weise können Sie es jederzeit zurückschieben. Ich habe einige Online - Ressourcen empfehlen Löschen gesehen (Verschieben / Umbenennen) , um die .ncbDatei als auch.

Ich habe das schon mal gesehen. Versuchen Sie, alle Ihre Haltepunkte zu löschen, und legen Sie dann die gewünschten fest. Hit F5. Ist es jetzt schneller?

Ich habe gerade bemerkt, dass Sie das Einrichten der .NET-Quell-Debugging-Funktion erwähnt haben. Versuchen Sie das zu deaktivieren. Ihre Netzwerkverbindung zum Microsoft-Quellserver ist möglicherweise langsam. Deaktivieren Sie auch die Symbolserver-Konnektivität im Menü Extras → Optionen → Debugging → Symbole .

Versuchen Sie auch, "Eigenschaftsbewertung und andere implizite Funktionsaufrufe aktivieren" im Menü Extras → Optionen → Debugging → Allgemein zu deaktivieren .

Oder entfernen Sie Ihre .suo-Datei, die sich neben Ihrer Lösungsdatei (.sln) befindet. Dies löste ein Problem, bei dem das Starten und Stoppen von Debug-Sitzungen lange dauerte.

Ich hatte dieses Problem. Nachdem wir alle aufgeführten Ratschläge ausprobiert und alle Visual Studio-Erweiterungen entfernt hatten, stellten wir schließlich fest, dass IntelliTrace irgendwie aktiviert war. Durch Deaktivieren wurde alles behoben.

Gewusst wie: Aktivieren und Deaktivieren von IntelliTrace

Haben Sie viele Haltepunkte gesetzt? Diese können die Startzeit erheblich verlangsamen. Jedes Mal, wenn ein neues Modul in den Prozessadressraum geladen wird, müssen alle überprüft werden, um festzustellen, ob sie gültig sind.

Gehen Sie zum Menü Extras → Optionen → Debugger → Symbole und prüfen Sie, ob öffentliche Symbole oder UNC- Netzwerkpfade festgelegt sind. Überprüfen Sie auch das Menü Extras * → Optionen → Debugger → Allgemein , um festzustellen , ob Sie den Quellserver eingestellt haben.

All dies kann sich auf das Debuggen auswirken, das auf einer langsamen Netzwerkgeschwindigkeit oder nicht verfügbaren Servern basiert. Die Wartezeit von 5 Minuten entspricht einer Netzwerkzeitüberschreitung.

Wenn in den Optionen nichts festgelegt ist, überprüfen Sie, ob die Umgebungsvariable _NT_SYMBOL_PATH festgelegt ist.

Mein Kollege reagierte sehr langsam auf Visual Studio, und es dauerte buchstäblich Minuten, um beim Debuggen einen Schritt auszuführen.

Die Hauptursache war ein Antivirenprogramm (Threatfire), das während der Ausführung von Visual Studio verrückt wurde. Durch das Beenden des Prozesses wurde sofort alles behoben.

In meinem Fall wurde das Problem durch Ändern des Debug-Symbols " Symbol automatisch laden für" von "Alle Module" in "Nur angegebene Module" behoben. Sie können diese Option über das Menü Extras → Optionen → Debugging → Symbole ändern .

Eine andere Ursache plus ... Wie man das Problem findet

Für mich war es die Option ShowOtherThreadIpMarkers . Ein Wert von 1 macht Visual Studio (2010) unerträglich langsam (3-5 Sekunden für jeden Debug-Schritt. Mit einem Wert von 0 ist es wieder schnell.

Was ist das für eine Option? Ich habe keine Ahnung. Ich konnte es nicht über die Visual Studio-Benutzeroberfläche finden. Ich habe alle möglichen Debugging-Optionen dort deaktiviert und nichts hat funktioniert.

Also ging ich zu Import / Export- Einstellungen und lud meine alten Einstellungen, die ich zuvor gespeichert hatte, in der Zeit zurück, bis Visual Studio wieder schnell war, und verglich dann die vssettings-Dateien ... usw. usw.

Ich möchte darauf hinweisen, dass wenn Sie die Einstellungen laden, während Sie sich im Debug-Modus befinden und an einem Haltepunkt gestoppt sind, diese sofort wirksam werden. Sie müssen den Debugger nicht stoppen und neu starten.

Aus dem von Travis verlinkten ScottGu-Blog: "Ein weiteres Problem, von dem ich kürzlich gehört habe, ist ein Problem, auf das einige Leute mit dem Google Toolbar-Add-In gestoßen sind. Aus irgendeinem Grund kann dies manchmal zu langen Verzögerungen beim Anhängen des Visuals führen Studio-Debugger für den Browser. Wenn beim Laden Ihrer Webanwendung lange Verzögerungen auftreten und die Google-Symbolleiste (oder andere Symbolleisten) installiert sind, sollten Sie versuchen, sie zu deinstallieren, um festzustellen, ob dies die Ursache des Problems ist. "

Das Ausführen unter dem Debugger war für mich ungefähr 10x langsamer als das Ausführen ohne Debugging.

Nachdem ich alle hier vorgeschlagenen Lösungen ausprobiert hatte, ging ich alle Debugger-Einstellungen durch und aktivierte / deaktivierte sie, um festzustellen, ob sie einen Unterschied machten.

Für mich stellte sich heraus, dass das Deaktivieren der Suppress JIT-Optimierung beim Laden des Moduls in den Debug-Einstellungen die Dinge massiv verbessert hat.

Stellen Sie sicher, dass Sie keine veralteten Netzwerkzuordnungen zu Servern haben, die nicht mehr vorhanden sind (Netzwerk-Timeouts werden Sie töten). Oder verwenden Sie so etwas wie Process Monitor , um festzustellen , ob ein Netzwerk (oder ein anderer Dateifehler) für längere Zeit blockiert zu sein scheint.

Verwenden Sie einen SymbolServer, um Symbole für Windows-DLL-Dateien herunterzuladen?

Wenn ja, deaktivieren Sie dies, da dies einige Zeit dauern kann, aber ich würde nicht erwarten, dass dies zu langen Verzögerungen in einer grundlegenden Konsolenanwendung führt.

Menü Extras → Optionen → Debugging → Symbole .

Ich weiß, dass dies ein altes Thema ist, aber für das, was es wert ist ...

Ich habe festgestellt, dass es bis zu einer Minute dauern kann, bis das Debuggen beginnt, wenn ein separates Internet Explorer-Fenster für längere Zeit geöffnet war. Schließen Sie alle Internet Explorer-Fenster und das Debuggen beginnt sofort.

In meinem Fall hat die Google Toolbar mein Debuggen verlangsamt.

gplus_notifications_gadget.html ging einfach weiter und überlastete den Debugger. Ich wollte die Google-Symbolleiste behalten, weil ich sie regelmäßig verwende. Deshalb habe ich nur die G + -Benachrichtigungsschaltfläche (die kleine Schaltfläche neben der Profilschaltfläche) deaktiviert. Es ist jetzt glücklich.

Ich hatte das gleiche Problem in Visual Studio 2010, als ich den Code unerträglich langsam eingab (zwischen 3 und 10 Sekunden). Keine der oben genannten Einstellungsänderungen hat jedoch den Trick ausgeführt.

Ich fand schließlich die ultimative Lösung, die in allen oben genannten Post-Problemen funktionieren würde: Setzen Sie alle Ihre Einstellungen zurück, wie hier beschrieben (im Wesentlichen Menü Extras → Einstellungen importieren und exportieren , Alle Einstellungen zurücksetzen und vorhandene Einstellungen in einer Datei speichern (zum Zurücksetzen) )).

Möglicherweise möchten Sie zuerst einen bestimmten Teil Ihrer Einstellungen speichern. Zum Beispiel habe ich zuerst mein Farbthema (Solarized-like) gespeichert und es dann nach dem globalen Zurücksetzen wiederhergestellt.

Für mich war die Einstellung, die die Leistung beeinträchtigte (Windows 8 blieb bis auf die Mausbewegung sogar hängen), das Deaktivieren von "Alle Prozesse unterbrechen , wenn ein Prozess unterbrochen wird" im Menü Optionen → Debuggen → Allgemein .

Nur eine weitere Ursache für ein langsames Debuggen von Visual Studio ...

Vor langer Zeit habe ich aktiviert, um FusionLogzu sehen, was ein Problem mit der Baugruppenbindung verursacht.

Stellen Sie sicher, dass Sie es nach der Verwendung deaktivieren. Warum? Weil es viele Protokolldaten auf die Festplatte schreibt, während es aktiviert ist.

Dies ist der FusionLogSchlüssel in der Windows-Registrierung ( regedit.exe):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

Ändern der ForceLog, LogImmersiveund die LogResourseBindingsWerte von 1 (aktiviert) bis 0 (deaktiviert).

Ich hatte auch dieses Problem, aber es hatte in meinem Fall nichts mit Haltepunkten zu tun. Es waren Code-Verknüpfungen, die ich im Aufgabenfenster hinzugefügt habe:

http://www.customsoftwareframeworks.com/blog/longwaittimetoinsertoraddalineoftextbuginvisualstudio--tasklistwindow--nur beim Hinzufügen und Entfernen von Linien

Ich bin sicher, es gibt andere Möglichkeiten, wie Sie ein Problem wie dieses sehen können, aber irgendwo gibt es einen Fehler, der dieses Problem für mich verursacht hat ... das Löschen aller meiner Optionen hätte dies behoben, aber das wollte ich nicht machen. Also habe ich es getestet und in meinem Blog darüber geschrieben ... Ihr Problem klingt wie meins.

Für mich hat es funktioniert, sicherzustellen, dass es keine bedingten Haltepunkte gibt. Abgesehen davon konnte ich das langsame Debuggen erfolgreich beheben, indem ich Visual Studio einfach neu startete und jeweils nur eine Instanz von Visual Studio öffnete.

Ich hatte ein ähnliches Problem und keine der anderen Anleitungen schien zu helfen. Ich hatte ohne Erfolg neu gestartet. Ich hatte alle Haltepunkte entfernt, die .suo-Datei gelöscht, überprüft, dass keine Symbole aus externen Quellen geladen wurden, und überprüft, dass in der Anwendung keine Pfade vorhanden waren, die nicht verfügbar waren.

Dann dachte ich, die Lösung zu reinigen. Ich habe im Ausgabefenster festgestellt, dass C # IntelliSense beim Reinigen ein Problem gemeldet hat:

Beim Lesen der Metadaten aus '{B0C3592F-F0D1-4B79-BE20-3AD610B07C23}' ist ein Problem aufgetreten ('Das System kann die angegebene Datei nicht finden.'). IntelliSense funktioniert möglicherweise erst ordnungsgemäß, wenn die Lösung neu geladen wurde.

In diesem Fall erfahren Sie genau, wie Sie die Fehlermeldung beheben können, sobald Sie sie tatsächlich entdeckt haben. (Gute Arbeit im Fehlertext, schlechte Arbeit in der Auffindbarkeit!) Ich habe die Projekte der Lösung entladen und sie dann neu geladen. Ich konnte dann erfolgreich eine saubere Lösung ausführen . Es hat funktioniert, und der Debugger auch.

Durch das Schließen des Fensters "Autos" wurde das Debuggen für mich in Visual Studio 2008 für eine große native C ++ - Lösung verbessert.

Das Verstecken wird nicht funktionieren. Es muss geschlossen werden.

Ich habe die gleiche Verlangsamung erlebt und das Trennen vom Netzwerk hat das Problem für mich behoben, wie einige andere Kommentare und Antworten angegeben haben (aber das ist natürlich keine ideale Lösung).

Für meinen Fall hat diese eine einfache Änderung meine Lösung behoben: In den Projekteigenschaften auf der Registerkarte Debug habe ich "Visual Studio-Hosting-Prozess aktivieren" deaktiviert (ich führe Visual Studio 2010 aus).

Holen Sie sich mehr Speicher und eine schnellere HD. Weitere Details finden Sie hier .