Quando eseguo il debug in Visual Studio, per qualche motivo durante il debug di un determinato thread, Visual Studio passa semplicemente a thread diversi.In che modo Visual Studio può rimanere su un thread durante il debug?
Come passare al comportamento in modo che si trovi sullo stesso thread?
In generale, blocco gli altri thread facendo clic con il tasto destro del mouse nel pannello dei threads. Non so se questo sia sano o meno comunque.
È l'impostazione predefinita perché l'esecuzione del programma nel debugger non dovrebbe modificare i risultati del programma, presumo.
Quando il programma è in esecuzione "live", passa costantemente da un thread all'altro, quindi se il debugger non ha fatto lo stesso, il programma si comporterebbe in modo diverso.
In ogni caso, l'unico modo che conosco per impedirlo è aprire la finestra Threads, fare clic con il pulsante destro su tutti gli altri thread rispetto a quello corrente e selezionare freeze. (Ricorda di nuovo a thaw)
Quando dici "quando esegui il debug di un determinato thread, lo studio visivo salterà in modo casuale su thread diversi", intendi che mentre passi attraverso il codice su un determinato thread puoi colpisci un breakpoint su un thread diverso?
Se è così, è possibile utilizzare la finestra di discussione ad 'congelare' le discussioni diverso da quello che ti interessa in debug:
Da http://msdn.microsoft.com/en-us/library/w15yf86f.aspx:
Dalla finestra Threads, è possibile impostare il thread attivo. Inoltre, è possibile bloccare o scongelare ogni singolo thread. Il blocco impedisce l'esecuzione di un thread. Lo scongelamento consente di continuare. Due barre blu verticali identificate da un blu thread.
Il supporto per questo può dipendere dalla versione di Visual Studio in uso (ad esempio, non penso che le versioni Express supportino la finestra Thread).
Tutte le risposte qui parlano di congelamento dei fili, ma diventa ingombrante quando ce ne sono molti e non si sa quale congelare. Ho trovato un trucco più facile.
Quando un punto di interruzione viene colpito da un filo i, e dire j, k, ecc stanno andando a colpire la stessa in un certo tempo, quindi disabilitare temporaneamente il punto di interruzione e avviare il debug filo i . Vedo che il debugger non passa agli altri thread dato che per quei thread non c'è breakpoint in cui penetrare. Abilita il breakpoint quando hai terminato il debug.
Questo ha senso ... ma non cambia il fatto che è altamente fastidioso. :) Sarebbe utile per il debug se MS ha aggiunto un'opzione di configurazione per rimanere all'interno del thread corrente quando viene colpito il punto di interruzione ... in questo modo, la logica che sta eseguendo in quel momento può essere debugata, senza l'ingombro e associati ritardo durante il debug di un programma con thread congelati. – Jon
Non sono d'accordo, ma un ovvio contro-argomento è che quando si esegue il debug, non si sta lavorando con la vostra vera applicazione di produzione, perché probabilmente non avete compilato la vostra applicazione di debug con le ottimizzazioni. Se stai cercando un problema logico, avere un controllo migliore del debugger è molto più utile che essere pedanticamente corretto. – stu