Problema di debug lento in Visual Studio

Nella mia istanza di Visual Studio, anche se ho appena scritto una singola riga di ritorno in un'applicazione console C #, ci vorrà un minuto dopo aver premuto F5per eseguire il codice effettivo (intendo il tempo necessario per fermarsi sulla singola istruzione return dopo premendo F5- ho impostato un punto di interruzione sull'istruzione return nella mainfunzione). Che c'è? C'è una lista di controllo?

Sto utilizzando l'edizione VSTS di Visual Studio 2008 e il debug su Windows Server 2003 x64.

Potrebbe essere necessario eliminare tutti i punti di interruzione --- nota che è necessario fare clic sul pulsante "Elimina tutti i punti di interruzione" (o utilizzare Ctrl+ Shift+ F9), NON eliminarli uno per uno. Se Visual Studio ha modificato le impostazioni della soluzione, quest'ultima non funzionerà. Potrebbe essere necessario aggiungere prima un punto di interruzione, affinché funzioni (intelligente, eh?).

Nel peggiore dei casi, potrebbe essere necessario eliminare il .suofile e consentire a Visual Studio di avviarne uno nuovo da zero. Si noti che, tuttavia, si perderanno le impostazioni di configurazione della soluzione personale (solo per questa soluzione, non per altre). Tuttavia, potresti voler spostare / rinominare il file temporaneamente finché non decidi se questo è il problema o meno; in questo modo, puoi sempre spostarlo indietro. Ho visto che alcune risorse online consigliano di eliminare (spostare / rinominare) anche il .ncbfile.

L'ho già visto prima. Prova a eliminare tutti i punti di interruzione e quindi imposta quelli desiderati. Hit F5. È più veloce adesso?

Ho appena notato che hai menzionato l'impostazione della funzionalità di debug del sorgente .NET. Prova a disabilitarlo. La connettività di rete al server di origine di Microsoft potrebbe essere lenta. Disabilitare anche qualsiasi connettività del server di simboli nel menu Strumenti → Opzioni → Debug → Simboli .

Prova anche a disabilitare "Abilita valutazione proprietà e altre chiamate di funzioni implicite" nel menu Strumenti → Opzioni → Debug → Generale .

Oppure rimuovi il tuo file .suo che può essere trovato accanto al tuo file della soluzione (.sln). Ciò ha risolto un problema che avevo con sessioni di debug che richiedevano molto tempo per l'avvio e l'arresto.

Ho avuto questo problema. Dopo aver provato tutti i consigli elencati e aver rimosso tutte le estensioni di Visual Studio, abbiamo finalmente capito che in qualche modo IntelliTrace era abilitato. La disattivazione ha risolto tutto.

Procedura: abilitare e disabilitare IntelliTrace

Hai impostato molti punti di interruzione? Questi possono davvero rallentare il tempo di avvio. Ogni volta che un nuovo modulo viene caricato nello spazio degli indirizzi del processo, è necessario controllarli tutti per vedere se sono validi.

Vai al menu Strumenti → Opzioni → Debugger → Simboli e controlla se hai impostato simboli pubblici o percorsi di rete UNC . Controlla anche il menu Strumenti * → Opzioni → Debugger → Generale per vedere se hai impostato il server di origine.

Tutto ciò può influire sul debug basato sulla velocità di rete lenta o sui server non disponibili. Il tempo di attesa di 5 minuti è timeout di rete.

Se non è impostato nulla nelle opzioni, controlla se hai impostato la variabile d'ambiente _NT_SYMBOL_PATH.

Il mio collega aveva un Visual Studio a risposta molto lenta e ci sono voluti letteralmente minuti per eseguire un passaggio durante il debug.

La causa principale si è rivelata essere un programma antivirus (Threatfire) impazzito mentre Visual Studio era in esecuzione. L'uccisione del suo processo ha risolto immediatamente tutto.

Nel mio caso la modifica del simbolo di debug "Carica automaticamente il simbolo per" opzione da "Tutti i moduli" a "Solo moduli specificati" ha risolto il problema. È possibile modificare questa opzione dal menu Strumenti → Opzioni → Debug → Simboli .

Una causa diversa e in più ... Come trovare il problema

Per me era l'opzione ShowOtherThreadIpMarkers . Un valore di 1 rende Visual Studio (2010) insopportabilmente lento (3-5 secondi per ogni passaggio di debug. Con un valore di 0, è di nuovo veloce.

Qual è questa opzione? Non ne ho idea. Non sono riuscito a trovarlo tramite l'interfaccia utente di Visual Studio. Ho deselezionato tutte le possibili opzioni di debug e non ha funzionato nulla.

Quindi sono andato a Impostazioni importazione / esportazione e ho caricato le mie vecchie impostazioni salvate in precedenza andando indietro nel tempo fino a quando Visual Studio non è stato di nuovo veloce, quindi ho confrontato i file vssettings ..., ecc., Ecc.

Vorrei sottolineare che se carichi le impostazioni mentre sei in modalità di debug fermo su un punto di interruzione, diventano immediatamente effettive. Non è necessario arrestare il debugger e riavviare.

Dal blog di ScottGu collegato da Travis: "Un altro problema di prestazioni di cui ho sentito parlare di recente è un problema che alcune persone hanno segnalato di imbattersi con il componente aggiuntivo di Google Toolbar. Per qualche motivo questo a volte può causare lunghi ritardi quando si collega l'elemento visivo Debugger di Studio nel browser. Se riscontri lunghi ritardi con il caricamento dell'applicazione web e hai installato Google Toolbar (o altre barre degli strumenti), potresti provare a disinstallarle per vedere se questa è la causa del problema. "

L'esecuzione con il debugger per me era circa 10 volte più lenta rispetto all'esecuzione senza debug.

Dopo aver provato ogni soluzione suggerita qui, ho esaminato tutte le impostazioni del debugger e abilitato / disabilitato per vedere se ha fatto la differenza.

Per me, si è scoperto che la disattivazione di ottimizzazione reprimere JIT il carico del modulo nelle impostazioni di debug massicciamente migliorato le cose.

Assicurati di non avere mappature di rete obsolete su server che non esistono più (i timeout di rete ti uccideranno). Oppure usa qualcosa come Process Monitor per vedere se una rete (o un altro errore di file) sembra bloccarsi per molto tempo.

Stai usando un server di simboli per scaricare simboli per i file DLL di Windows?

In tal caso, disabilitalo poiché può richiedere del tempo, ma non mi aspetto che ciò causi lunghi ritardi in un'applicazione console di base.

Menu Strumenti → Opzioni → Debug → Simboli .

So che questo è un vecchio argomento, ma per quello che vale ...

Ho scoperto che se ho una finestra separata di Internet Explorer aperta per molto tempo, può essere necessario fino a un minuto per avviare il debug. Chiudi tutte le finestre di Internet Explorer e il debug si avvia immediatamente.

Nel mio caso Google Toolbar ha rallentato il mio debug.

gplus_notifications_gadget.html continuava ad andare avanti e a sovraccaricare il debugger. Volevo mantenere la Google Toolbar perché la uso regolarmente, quindi ho semplicemente disabilitato il pulsante di notifica G + (il piccolo pulsante accanto al pulsante del profilo). Adesso è felice.

Ho avuto lo stesso problema in Visual Studio 2010, con il passaggio del codice estremamente lento (tra 3 e 10 secondi). Tuttavia, nessuna delle modifiche alle impostazioni di cui sopra ha funzionato.

Alla fine ho trovato la soluzione definitiva, che avrebbe funzionato in tutti i problemi del post sopra: ripristina tutte le tue impostazioni, come descritto qui (essenzialmente menu Strumenti → Importa ed esporta impostazioni , Ripristina tutte le impostazioni , con il salvataggio delle impostazioni esistenti in un file (per il ripristino )).

Potresti prima voler salvare una parte particolare delle tue impostazioni. Ad esempio, ho prima salvato il mio tema colore (simile a Solarizzato) e poi l'ho ripristinato dopo il ripristino globale.

Per me, l'impostazione che ha interrotto le prestazioni (Windows 8 è stato addirittura bloccato tranne che per il movimento del mouse) era deselezionare "Interrompi tutti i processi quando un processo si interrompe" nel menu Opzioni → Debug → Generale .

Solo un'altra causa di una lenta esperienza di debug di Visual Studio ...

Molto tempo fa ho potuto FusionLogvedere cosa stava causando un problema di associazione dell'assembly.

Assicurati di disabilitarlo dopo averlo usato. Perché? Perché scrive molti dati di registrazione sul disco mentre è abilitato.

Questa è la FusionLogchiave nel registro di Windows ( regedit.exe):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

Cambiare i ForceLog, LogImmersivee LogResourseBindingsvalori da 1 (attivato) a 0 (disattivato).

Anch'io ho avuto questo problema, ma nel mio caso non aveva nulla a che fare con i punti di interruzione. Sono state le scorciatoie del codice che ho aggiunto nella finestra delle attività:

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

Sono sicuro che ci sono altri modi in cui potresti vedere un problema come questo, ma c'è un bug da qualche parte che ha causato questo problema per me ... l'eliminazione di tutte le mie opzioni avrebbe risolto il problema, ma è qualcosa che non volevo fare. Quindi, ho eseguito il debug e ne ho scritto nel mio blog ... il tuo problema sembra il mio.

Qualcosa che ha funzionato per me è assicurarmi che non ci siano punti di interruzione condizionali. Oltre a questo, ho avuto successo nel correggere il debug lento semplicemente riavviando Visual Studio e aprendo solo un'istanza di Visual Studio alla volta.

Ho avuto un problema simile e nessuna delle altre linee guida sembrava aiutare. Mi ero riavviato inutilmente. Avevo rimosso tutti i punti di interruzione, eliminato il file .suo, controllato che i simboli non venissero caricati da fonti esterne e controllato che non esistessero percorsi nell'applicazione non disponibile.

Quindi, ho pensato di pulire la soluzione. Ho notato nella finestra di output che C # IntelliSense ha segnalato un problema durante la pulizia:

Si è verificato un problema durante la lettura dei metadati da "{B0C3592F-F0D1-4B79-BE20-3AD610B07C23}" ("Il sistema non riesce a trovare il file specificato."). IntelliSense potrebbe non funzionare correttamente finché la soluzione non viene ricaricata.

In questo caso, una volta scoperto il messaggio di errore, ti dice esattamente come risolverlo. (Buon lavoro sul testo dell'errore, cattivo lavoro sulla rilevabilità!) Ho scaricato i progetti della soluzione, quindi li ho ricaricati. Sono stato quindi in grado di eseguire con successo la soluzione pulita . Ha funzionato e anche il debugger ha funzionato.

La chiusura della finestra "Autos" ha migliorato il debug in Visual Studio 2008 per una grande soluzione C ++ nativa.

Nasconderlo non funzionerà. Deve essere chiuso.

Ho sperimentato lo stesso rallentamento e la disconnessione dalla rete ha risolto il problema per me come hanno affermato altri commenti e risposte (ma ovviamente questa non è una soluzione ideale).

Nel mio caso, questa semplice modifica ha risolto la mia soluzione: nelle proprietà del progetto nella scheda di debug ho disabilitato "Abilita il processo di hosting di Visual Studio" (sto eseguendo Visual Studio 2010).

Ottieni più memoria e un HD più veloce. Maggiori dettagli sono qui .