Debug durante la pausa e 'impossibile valutare l'espressione'

Question

Utilizzando Visual Studio, dopo aver eseguito il collegamento a un processo e aver fatto Pausa (Break-All), si passa al thread desiderato e si utilizza la finestra Quick Watch per controllare alcuni dati, ad esempio

MySingletonClass.Instance.Data 

volte mi sia ottengo questo:

Impossibile valutare l'espressione perché il thread corrente è in un sonno, aspetta, o partecipare

o questo (quando si tenta di visualizzare determinate proprietà dei dati):

Impossibile valutare l'espressione perché una cornice nativa si trova in cima allo stack di chiamate.

Abbastanza francamente, non mi interessa, voglio solo vedere i dati! So che ci sono diversi modi per aggirare questo, vale a dire:

1. Impostare un punto di interruzione sul filo e in attesa fino a che non viene colpito (ingombrante, non sempre possibile)
2. Facendo una discarica del processo e di carico posteriore in VS (anche allora ho ancora ottenere il 2 ° errore)
3. windbg

dato poteva visualizzare questi dati se presumibilmente usato windbg perché è che tutti noi non possiamo approfittare del molto più facile e VS più grazioso per ispezionare oggetti quando a collegando a un processo?

Answer 1

Perché non possiamo farlo? Non possiamo farlo perché la finestra di visualizzazione di Visual Studio non recupera solo i dati dalla memoria e li visualizza. In realtà, esegue il codice gestito (questo è ciò che significa "valuta l'espressione"). In particolare, esegue quasi sempre il metodo ToString() per visualizzare il risultato leggibile dall'utente.

Il punto cruciale è che esegue questo codice all'interno del processo/thread di cui si sta eseguendo il debug. Ciò garantisce che l'espressione valuti nello stesso modo in cui lo sarebbe se fosse effettivamente nel codice che si sta eseguendo il debug. Ciò lascia il lato negativo che può essere eseguito solo tra le istruzioni gestite, ma non mentre il codice nativo è attivo e non in un thread bloccato.

Cosa possiamo fare a riguardo? Se si sta eseguendo il debug di un'applicazione gestita e si è in uno stackframe nativo, è sufficiente premere F10 o Maiusc + F11 ripetutamente fino a tornare al codice gestito. Quindi puoi valutare le espressioni. Tuttavia, per i processi completamente nativi e per i thread in uno stato bloccato, non sono a conoscenza di alcuna soluzione alternativa.

Answer 2

Basta premere Maiusc-F11 fino a quando un frame stack gestito è in cima allo stack e sarete in grado di fare ciò che volete in VS.

Principalmente si riduce al fatto che non è sicuro valutare le espressioni in determinati punti durante l'esecuzione del processo, o si rischia di corrompere il runtime. WinDbg non protegge il runtime da te. VS lo fa.

Answer 3

Il problema è che non si tratta di dati che si desidera visualizzare, è il risultato dell'esecuzione di codice. Le proprietà .Net sono in realtà solo metodi mascherati, quindi per ottenere il valore di una proprietà, Visual Studio deve eseguire il codice dell'applicazione (questa funzionalità è nota come FuncEval).

Questo codice deve essere eseguito su alcuni thread e ciò che VS fa è che utilizza uno dei thread dell'applicazione per questo. C'è a number of situations dove VS non può eseguire il codice per produrre il risultato, e cioè quando hai visto i messaggi di errore di cui stai parlando.

Answer 4

Se si passa all'istruzione successiva, il debugger potrebbe disporre di tempo sufficiente per valutarlo prima del timeout.

Nota, questo funziona sempre.

Answer 5

Ecco uno link per una discussione su questo problema. Apparentemente quando gli argomenti della funzione sono structs, e la memoria totale necessaria nello stack per chiamare la funzione supera qualche numero magico, il visual debugger di Visual Studio viene attivato.

Ulteriori link dalla discussione quadro OpenTK.

Answer 6

se il progetto è client-server, cercare di ricaricare riferimento MySql.Data.dll

Answer 7

So che questo è un ripiego, ma sono contento del modo in cui funziona. Alla fine del mio metodo Main(), che inizia in origine tutto e crea tutte le altre strutture di dati e le discussioni e quindi termina, mi attengo a questo:

 while (true) 
     { 
      // This infinite while loop just gives me a convenient place for a 
      // breakpoint, so I can see everything everywhere during debugging. 
      Thread.Sleep(100); 
     } 

Invece di fare una "pausa All" Ho solo bastone un breakpoint sulla parentesi graffa {. Il programma si interrompe. Ho una discussione disponibile e un riferimento a tutto, così posso facilmente sfogliare tutte le strutture di dati e tutti i thread, vedere tutto ovunque.