2013-07-16 11 views
7

Stiamo creando una soluzione per Rilascio, ma quando si tenta di allegare utilizzando Studio 2010 Professional, nessun thread mostra alcuna informazione sullo stack, né alcun punto di interruzione può essere impostato, ecc.Impossibile eseguire il debug dell'applicazione in modalità di rilascio anche con DebugType = completo

L'obiettivo è essere in grado di collegare il debugger di Visual Studio/JIT al processo in esecuzione con tutti i vantaggi di ottimizzazione possibili.

La maggior parte delle nostre ricerche si riduce a "compilare con debug: full" e sarete in grado di eseguire il debug, ma ciò non sembra essere il caso, io invece il JIT ottimizza il codice in runtime e quindi non è possibile eseguire il debug, è vero? È possibile compilare e dire al JIT di minimizzare le ottimizzazioni e consentire il debug? (Pur mantenendo altre ottimizzazioni)

UPDATE

usando @ risposta di HansPassant, ho guardato i moduli e ho visto che, anche se le PDBS si trovano nella stessa directory dei file binari, anzi non simboli di debug sono stati caricati. quello che ho anche visto è che le mie librerie sono contrassegnate come 'Codice utente' - 'NO' che probabilmente è la ragione per cui non è stato caricato automaticamente. Caricando manualmente i simboli E disabilitando 'just-my-code' Sono stato anche in grado di impostare i breakpoint e vedere le pile.

Domanda ora: perché il mio codice non è contrassegnato come codice utente? è questo comportamento normale? posso configurare questo ai miei assemblaggi in qualche modo per evitare questo?

+0

'né un punto di interruzione può essere impostato' <- perché no? è il messaggio di errore "Nessun simbolo corrispondente può essere trovato"? – wal

+0

@wal Si prega di consultare la domanda aggiornata, era una combinazione di simboli mancanti e 'just-my-code' disabilitato –

risposta

13

Il debug di un codice ottimizzato non è un grande piacere. Certamente potresti avere problemi nell'impostazione dei punti di interruzione, un metodo potrebbe essere stato in linea. Inoltre, l'ispezione delle variabili locali e degli argomenti del metodo può rendere il debugger imbronciato quando la variabile è ottimizzata per essere archiviata in un registro cpu.

Tuttavia è comunque possibile controllare gli stack di chiamate, vedrete i metodi che non sono stati evidenziati nella traccia dello stack. Errori di base che potreste fare:

  • quando si allega un debugger, si ottiene l'opzione per selezionare il tipo di debugger. Assicurati di selezionare "Gestito", non ti servirà molto per il debugger nativo
  • assicurati che stai guardando il thread corretto, il programma può essere interrotto in una posizione arbitraria. Utilizza Debug + Windows + Thread per selezionare il thread appropriato
  • assicurati di essere effettivamente danneggiato in una posizione nel codice. Si può facilmente finire all'interno di una DLL del sistema operativo Windows o di un metodo framework, ci sarà molto poco da vedere quando questo è il caso. Strumenti + Opzioni, Debug, Simboli e abilitare il server dei simboli in modo che le tracce di stack che iniziano all'interno di Windows siano accurate
  • il debugger deve essere in grado di individuare i file PDB. Usa Debug + Moduli Windows +, vedrai gli assembly caricati nel processo. Innanzitutto assicurati che quello che vuoi eseguire il debug sia effettivamente caricato. Fare clic con il tasto destro del mouse e selezionare "Informazioni sul carico del simbolo". Ti mostra dove cercava il file PDB
  • l'opzione "solo il mio codice" può essere molto complicata, è molto probabile che ti imbatti in blocchi significativi di codice che non sono tuoi. Strumenti + Opzioni, Debug, Generale e disattivare questa opzione.
+2

(+1) La finestra 'Modules' ha mostrato che i miei assembly non sono trattati come codice utente, si prega di consultare la domanda aggiornata –