Problema di debug lento in Visual Studio

Nel mio Visual Studio, anche io ho appena scritto una singola riga di ritorno in un’applicazione console C #, mi occorrerà un minuto dopo aver premuto F5 per eseguire il codice effettivo (intendo il tempo necessario per fermarsi sulla singola istruzione return dopo aver premuto F5 – Ho impostato un breakpoint sull’istruzione return nella funzione Main). Mi chiedo cosa c’è che non va? Qualche lista di controllo? Grazie!

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

grazie in anticipo, George

Potrebbe essere necessario eliminare tutti i punti di interruzione — nota che è necessario fare clic sul pulsante “Elimina tutti i punti di interruzione” (o usare Ctrl-Shft-F9), NON eliminarli solo uno per uno. Se Visual Studio ha alterato le impostazioni della soluzione, quest’ultima non funzionerà. Potrebbe essere necessario aggiungere prima un punto di interruzione, affinché funzioni (intelligente, eh?).

Se la cosa peggiore si verifica nel peggiore dei casi, potrebbe essere necessario eliminare il file .suo e consentire a Visual Studio di avviarne uno nuovo da zero. Si noti che perderete comunque le impostazioni di configurazione della soluzione personale (solo per questa soluzione, non altre). Tuttavia, è ansible spostare / rinominare temporaneamente il file finché non si determina se questo è il problema; in questo modo, puoi sempre spostarlo indietro. Ho visto alcune risorse online consigliare di eliminare (spostare / rinominare) anche il file .ncb .

L’ho già visto prima. Prova a eliminare tutti i punti di interruzione e quindi imposta quelli che desideri. Premi F5. È più veloce ora?

Ho appena notato che hai menzionato l’impostazione della funzionalità di debug del codice sorgente di .NET. Prova a disabilitarla, la tua connettività di rete al server di origine Microsoft potrebbe essere lenta. Disabilitare inoltre qualsiasi connettività del server di simboli in Strumenti> Opzioni> Debug> Simboli

Prova anche a disabilitare “Abilita valutazione proprietà e altre chiamate di funzioni implicite” in Strumenti> Opzioni> Debug> Generale.

Oppure rimuovi il tuo file .suo che si trova accanto al file della tua soluzione (.sln). Questo ha risolto un problema che avevo con le sessioni di debug che impiegavano molto tempo per avviarsi e fermarsi.

Avuto questo problema Dopo aver provato tutti i consigli elencati e rimosso tutte le estensioni degli studi visivi, abbiamo finalmente capito che in qualche modo IntelliTrace era abilitato. Disabilitare quello ha riparato tutto.

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

Avete un sacco di punti di interruzione impostati? Quelli possono davvero rallentare i tempi di avvio. Ogni volta che un nuovo modulo viene caricato nello spazio degli indirizzi del processo, tutti devono essere controllati per vedere se sono validi.

Vai a strumenti / opzioni / debugger / simboli e controlla se hai impostato set di simboli pubblici o percorsi di rete UNC. Controlla anche strumenti / opzioni / debugger / generale per vedere se hai impostato il server di origine.

Tutti questi possono influenzare il debug basato su velocità di rete lenta o server non disponibili. I 5 minuti di attesa sono i timeout di rete.

Se non è impostato nulla nelle opzioni, verificare se è stata impostata la variabile di ambiente _NT_SYMBOL_PATH.

Il mio collega aveva un Visual Studio che rispondeva molto lentamente, letteralmente ci sono voluti dei minuti per eseguire un passo durante il debug. La causa principale si è rivelata essere un programma anti virus (threatfire) che è impazzito mentre VS era in esecuzione. Uccidere il suo processo ha immediatamente risolto tutto.

Nel mio caso cambiando il simbolo di debug l’opzione “Carica automaticamente simbolo per” da “tutti i moduli” a “solo moduli specificati” ha risolto il problema. Puoi cambiare questa opzione da Strumenti -> Opzioni -> Debug -> Simboli

Una causa diversa più … Come trovare il problema

Per me era l’opzione ShowOtherThreadIpMarkers. Un valore = 1 rende vs (2010) insopportabilmente lento (3-5 secondi per ogni passo di debug. Con il valore 0 è di nuovo veloce.

Cos’è questa opzione? Non ne ho idea. Non riuscivo a trovarlo attraverso l’interfaccia utente vs. Ho deselezionato tutte le possibili opzioni di debug e non ho funzionato.

Così sono andato su Import Export Settings e ho caricato le mie vecchie impostazioni che avevo precedentemente salvato andando indietro nel tempo fino a quando era di nuovo veloce, quindi confrontato i file di vssettings … ecc., Ecc.

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

Dal blog di ScottGu collegato da Travis: “Un altro trucchetto sulle prestazioni di cui ho sentito parlare recentemente è un problema che alcune persone hanno segnalato durante l’esecuzione con il componente aggiuntivo di Google Toolbar. Per qualche motivo questo a volte può causare lunghi ritardi durante il collegamento di Visual Studio debugger nel browser. Se si verificano ritardi prolungati con il caricamento dell’applicazione Web e la barra degli strumenti di Google (o altre barre degli strumenti) sono installate, è ansible provare a disinstallarle per vedere se questa è la causa del problema. ”

Assicurati di non avere alcun mapping di rete stantio ai 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 da molto tempo.

Stai usando un Symbol Server per scaricare i simboli per le DLL di Windows?

In tal caso, disabilitarlo in quanto potrebbe richiedere un po ‘di tempo, ma non mi aspetto che ciò causi lunghi ritardi in un’app di console di base.

Strumenti> Opzioni> Debug> Simboli

So che questo è un vecchio argomento ma per quello che vale …

Ho scoperto che se ho avuto una finestra IE separata aperta per un lungo periodo di tempo può richiedere fino a un minuto per avviare il debug. Chiudi tutte le windows di IE e il debug inizia immediatamente.

Nel mio caso Google Toolbar stava rallentando il mio debug. gplus_notifications_gadget.html ha continuato ad andare avanti e sovraccaricare il debugger. Volevo mantenere Google Toolbar perché lo uso regolarmente, quindi ho semplicemente distriggersto il pulsante di notifica G + (il pulsante piccolo oltre al pulsante del profilo). È felice ora.

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

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

Per me, è risultato che disabilitare l’ ottimizzazione dell’eliminazione JIT sul carico del modulo nelle impostazioni di debug ha migliorato notevolmente le cose.

Ho avuto lo stesso problema in VS2010, con l’introduzione del codice atrocemente lento (tra 3 e 10 secondi). Tuttavia, nessuna delle modifiche alle impostazioni precedenti ha funzionato. Alla fine ho trovato la soluzione definitiva, che avrebbe funzionato in tutti i post precedenti: ripristinare tutte le impostazioni, come descritto qui .

Puoi in primo luogo voler salvare una parte particolare delle tue impostazioni, ad esempio ho prima salvato il mio tema colore (simile a Solarized), quindi ripristinato dopo il reset globale.

Per me, l’impostazione che ha ucciso le prestazioni (Windows 8 è stato impiccato, eccetto per il movimento del mouse) era UNCHECK “Interrompi tutti i processi quando un processo si interrompe” in Opzioni -> Debug -> Generale.

Spero che questo aiuti chiunque.

Solo un’altra causa di una lenta esperienza di debug di Visual Studio …

Molto tempo fa ho abilitato FusionLog per vedere che cosa stava causando un problema di associazione all’assemblaggio.

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

Questa è la chiave FusionLog sul registro di Windows [ regedit.exe ]:

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion 

Modificare i ForceLog , LogImmersive e LogResourseBindings da 1 abilitato a 0 disabilitato.

Ho avuto anche questo problema, ma non aveva nulla a che fare con i breakpoint nel mio caso. Sono state le scorciatoie di 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 questo problema, ma è qualcosa che non volevo fare. Quindi, ho eseguito il debug e ne ho scritto nel mio blog … il tuo problema suona come il mio.

Grazie.

Qualcosa che ha funzionato per me è assicurarsi che non ci siano punti di interruzione condizionati. A parte questo, ho avuto successo correggendo il debugging lento semplicemente riavviando Visual Studio e aprendo solo un’istanza di Visual Studio alla volta. Spero che aiuti qualcuno …

Ho avuto un problema simile e nessuno degli altri orientamenti sembrava aiutare. Ho riavviato inutilmente. Avevo rimosso tutti i punti di interruzione, cancellato il suo file, controllato che i simboli non venissero caricati da fonti esterne e controllato che nessun percorso esistesse nell’applicazione che non era 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}’ (‘Imansible trovare il file specificato.’). IntelliSense potrebbe non funzionare correttamente fino a quando la soluzione non viene ricaricata.

In questo caso, una volta che hai effettivamente scoperto il messaggio di errore, ti dice esattamente come risolverlo. (Buon lavoro sul testo dell’errore, scarso lavoro sulla reperibilità!) Ho scaricato i progetti della soluzione, quindi li ho ricaricati. Sono stato quindi in grado di eseguire correttamente una soluzione pulita. Ha funzionato e anche il debugger ha funzionato.

HTH

Chiudere la finestra “Auto” mi ha migliorato il debugging in vs2008 per una grande soluzione nativa in c ++. Nascondendolo 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 non è una soluzione ideale).

Nel mio caso questa semplice modifica ha risolto la mia soluzione: Nelle proprietà del progetto nella scheda Debug ho disabilitato “Abilita il processo di hosting di Visual Studio”. (Sto utilizzando VS2010)

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