Problem z powolnym debugowaniem w Visual Studio

Już to widziałem. Spróbuj usunąć wszystkie swoje punkty przerwania, a następnie ustaw te, które chcesz. Wciśnij F5. Teraz jest szybciej?

Właśnie zauważyłem, że wspomniałeś o skonfigurowaniu funkcji debugowania źródeł. NET. Spróbuj to wyłączyć, łączność sieciowa z serwerem źródłowym firmy Microsoft może być powolna. Wyłącz również łączność z serwerem symboli w narzędziach > opcje > debugowanie > symbole

Spróbuj również wyłączyć opcję "Enable property evaluation and other implicit function calls" w narzędziach > Opcje > Debugowanie > Ogólne.

Lub usunąć swoje .plik suo, który znajduje się obok Twojego rozwiązania (.sln). To rozwiązało problem, który miałem z sesji debugowania biorąc dużo czasu, aby rozpocząć i zatrzymać.

Miałem ten problem. Po wypróbowaniu wszystkich wymienionych porad i usunięciu wszystkich rozszerzeń visual studio, w końcu zorientowaliśmy się, że IntelliTrace został włączony. Wyłączenie tego naprawiło wszystko.

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

Czy masz dużo ustawionych punktów przerwania? Mogą one naprawdę spowolnić czas uruchamiania. Za każdym razem, gdy nowy moduł jest ładowany do przestrzeni adresowej procesu, wszystkie muszą być sprawdzone, aby sprawdzić, czy są poprawne.

Przejdź do Narzędzia/Opcje / debugger / Symbole i sprawdź, czy masz ustawione symbole publiczne lub ustawione ścieżki sieciowe UNC. Sprawdź również Narzędzia / Opcje / debugger / ogólne, aby sprawdzić, czy masz ustawiony serwer źródłowy.

Wszystko to może mieć wpływ na debugowanie w oparciu o powolną prędkość sieci lub niedostępne serwery. 5-minutowy czas oczekiwania to sieciowe timeouty.

Jeśli nic w options nie jest ustawione, sprawdź, czy masz ustawioną zmienną środowiskową _nt_symbol_path.

Mój kolega miał bardzo powoli reagujące Visual Studio, dosłownie trwało kilka minut, aby wykonać krok podczas debugowania. Główną przyczyną okazał się program antywirusowy (threatfire), który oszalał podczas działania VS. Zabicie procesu natychmiast naprawiło wszystko.

W moim przypadku zmiana symbolu debugowania" automatycznie załaduj symbol dla opcji "z" wszystkie moduły " NA "tylko określone moduły" rozwiązała problem. Możesz zmienić tę opcję z Narzędzia -> Opcje ->debugowanie - > Symbole

Inna przyczyna plus... Jak znaleźć problem

Dla mnie była to opcja ShowOtherThreadIpMarkers. wartość =1 sprawia, że vs (2010) jest nieznośnie powolny (3-5 sekund dla każdego kroku debugowania. Z wartością 0 jest szybko ponownie.

Co to za opcja? Nie mam pojęcia. Nie mogłem go znaleźć przez interfejs użytkownika vs. Odznaczyłem wszystkie możliwe opcje debugowania i nic nie działało.

Więc poszedłem do Import Export Settings i załadowałem moje stare ustawienia mam wcześniej zapisany w czasie cofania do czasu, aż vs znów był szybki, a następnie porównał pliki vssettings... itd, itp.

Chciałbym zauważyć, że jeśli wczytasz ustawienia, gdy jesteś w trybie debugowania zatrzymane na punkcie przerwania, stają się one skuteczne natychmiast. nie musisz zatrzymywać debuggera i restartować go.

Z bloga ScottGu linked by Travis: "jeszcze jeden występ gotcha, o którym słyszałem ostatnio, to problem, na który kilka osób zgłosiło napotkanie dodatku Google Toolbar. Z jakiegoś powodu może to czasami powodować duże opóźnienia podczas dołączania debugera Visual Studio do przeglądarki. Jeśli widzisz duże opóźnienia z ładowaniem aplikacji internetowej i masz zainstalowany pasek narzędzi Google (lub inne paski narzędzi), możesz spróbować je odinstalować, aby sprawdzić, czy jest to przyczyną problem."

Upewnij się, że nie masz żadnych starych mapowań sieciowych do serwerów, które już nie istnieją(przekroczenie czasu sieci zabije cię). Lub użyj czegoś takiego jak Process Monitor, aby sprawdzić, czy sieć (lub inny błąd pliku) wydaje się blokować przez długi czas.

Czy używasz serwera symboli do pobierania symboli dla DLL systemu Windows?

Jeśli tak wyłącz to, ponieważ może to zająć trochę czasu, ale nie spodziewałbym się, że spowoduje to duże opóźnienia w podstawowej aplikacji konsoli.

Narzędzia > Opcje > Debugowanie > Symbole

Wiem, że to stary temat, ale jeśli to coś warte...

Odkryłem, że jeśli mam otwarte od dłuższego czasu oddzielne okno IE, rozpoczęcie debugowania może zająć nawet minutę. Zamknij wszystkie okna IE i debugowanie rozpocznie się natychmiast.

W moim przypadku Google Toolbar spowalniał moje debugowanie. gplus_notifications_gadget.html po prostu cały czas przeładowywał debugger. Chciałem zachować pasek narzędzi Google, ponieważ używam go regularnie, więc po prostu wyłączyłem przycisk powiadomienia G+ (mały przycisk oprócz przycisku profilu.) Jest teraz szczęśliwy.

Uruchamianie pod debugerem dla mnie było około 10x wolniejsze niż uruchamianie bez debugowania.

Po wypróbowaniu każdego rozwiązania zaproponowanego tutaj, przejrzałem wszystkie ustawienia debuggera i włączyłem/wyłączyłem, aby sprawdzić, czy to coś zmieniło.

Dla mnie okazało się, że wyłączenie wyłącza optymalizację JIT przy obciążeniu modułu w Ustawieniach debugowania masowo poprawiło się.

Miałem ten sam problem w VS2010, z wkraczaniem w kod potwornie wolno (od 3 do 10 sekund). Jednak żadna z powyższych modyfikacji ustawień nie zadziałała. W końcu znalazłem ostateczne rozwiązanie, które sprawdziłoby się we wszystkich powyższych kwestiach: Zresetuj wszystkie ustawienia, jak opisano tutaj .

Możesz najpierw zapisać określoną część ustawień, na przykład najpierw zapisałem Mój motyw kolorów( podobny do Solaryzowanego), a następnie przywróciłem go po globalnym reset.

Dla mnie ustawienie, które zabiło wydajność (windows 8 nawet wisiał poza ruchem myszy) było odznaczenie "Break all process when one process breaks" w Options -> Debugging - > General.

Mam nadzieję, że to komuś pomoże.

Jeszcze jedna przyczyna powolnego debugowania w Visual Studio...

Dawno temu włączyłem FusionLog aby zobaczyć, co spowodowało problem związany z montażem.

Upewnij się, że wyłączyłeś go po użyciu. Dlaczego? Ponieważ zapisuje wiele danych logowania na dysk, gdy jest włączony.

To jest FusionLog klucz w rejestrze okna[ regedit.exe ]:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

Zmień ForceLog, LogImmersive i LogResourseBindings wartości od 1 włączone do 0 wyłączone.

Też miałem ten problem, ale w moim przypadku nie miał on nic wspólnego z punktami przerwania. To były skróty kodu, które dodałem w oknie Zadania:

Http://www.customsoftwareframeworks.com/blog/longwaittimetoinsertoraddalineoftextbuginvisualstudio--tasklistwindow--onlywhenaddingandremovelines

Jestem pewien, że są inne sposoby, aby zobaczyć taki problem, ale jest gdzieś błąd, który spowodował ten problem dla mnie...usunięcie wszystkich moich opcji naprawiłoby to, ale to jest coś, czego nie chciałem robić. Więc debugowałem go i pisałem o tym na moim blogu...twój problem brzmi jak mój.

Coś, co zadziałało dla mnie, to upewnienie się, że nie ma warunkowych punktów przerwania. Poza tym udało mi się naprawić powolne debugowanie, po prostu restartując visual studio i otwierając tylko jedną instancję visual studio na raz. Mam nadzieję, że to komuś pomoże...

Miałem podobny problem i żadne inne wskazówki nie pomogły. Zrestartowałem się na nic. Usunąłem wszystkie punkty przerwania, usunąłem plik suo, sprawdziłem, czy symbole nie są ładowane z zewnętrznych źródeł i sprawdziłem, czy nie istnieją żadne ścieżki w aplikacji, która była niedostępna.

Potem pomyślałem, aby wyczyścić roztwór. Zauważyłem w oknie wyjściowym, że C# IntelliSense zgłosił problem podczas czyszczenia:

Wystąpił problem z odczytaniem metadanych od "{B0C3592F-F0D1-4B79-BE20-3AD610B07C23}" ('System nie może znaleźć pliku określone.'). IntelliSense może nie działać prawidłowo, aż rozwiązanie przeładowany.

W tym przypadku, gdy rzeczywiście odkryjesz komunikat o błędzie, powie Ci dokładnie, jak go rozwiązać. (Dobra robota w tekście błędu, słaba praca w wykrywalności!) Rozładowałem projekty rozwiązania, a następnie przeładowałem je. Byłem wtedy w stanie z powodzeniem uruchomić czyste rozwiązanie. Zadziałało, a debugger zrobił jak cóż.

HTH

Zamknięcie okna "Autos" poprawiło dla mnie debugowanie w vs2008 dla dużego natywnego rozwiązania c++. Ukrywanie tego nie zadziała, musi być zamknięte.

Doświadczyłem tego samego spowolnienia, a odłączenie od sieci naprawiło problem dla mnie, jak kilka innych komentarzy i odpowiedzi stwierdziło(ale oczywiście nie jest to idealne rozwiązanie).

W moim przypadku ta jedna prosta zmiana naprawiła moje rozwiązanie: we właściwościach projektu na karcie debugowania wyłączyłem " Włącz proces hostingu Visual Studio."(I am running VS2010)

Uzyskać więcej pamięci i szybszy HD. więcej szczegółów tutaj .