Eventuali impostazioni VC++ consigliate per una migliore analisi PDB sulle build di rilascio

Question

Esistono impostazioni VC++ che dovrei conoscere per generare file PDB migliori che contengono più informazioni?

Ho un sistema di analisi del crash dump in atto in base al progetto crashrpt.

Inoltre, il mio server di build di produzione ha il codice sorgente installato su D:\, ma la mia macchina di sviluppo ha il codice sorgente su C:\.Ho inserito il percorso di origine nelle impostazioni di VC++, ma quando guardo lo stack di chiamate di un arresto anomalo, non passa automaticamente al mio codice sorgente.Credo che se avessi il codice sorgente della mia macchina di sviluppo su D: \ funzionerebbe.

Answer 1

"Ci sono impostazioni VC++ di cui dovrei essere a conoscenza"

Assicurati di disattivare l'omissione del puntatore del frame.Il blog di Larry Osterman ha i dettagli storici su fpo e i problemi che causa con il debug.

I simboli sono stati caricati correttamente.Mostra lo stack di chiamate, ma facendo doppio clic su una voce non mi porta al codice sorgente.

Che versione di VS stai utilizzando?(O stai usando Windbg?) ...in VS dovrebbe sicuramente richiedere la fonte la prima volta se non trova la posizione.Tuttavia mantiene anche un elenco delle fonti che non sono state trovate, quindi non te lo chiede ogni volta.A volte la lista da non guardare è una seccatura...per ripristinare il prompt è necessario accedere a Esplora soluzioni/Nodo soluzione/Proprietà/Proprietà debug e modificare l'elenco dei file nel riquadro inferiore.

Infine potresti utilizzare "simboli eliminati".Si tratta di file pdb generati per fornire informazioni di debug per far passare lo stack di chiamate oltre l'FPO, ma con le posizioni di origine eliminate (insieme ad altri dati).I simboli pubblici per i componenti del sistema operativo Windows sono pdb rimossi.Per il tuo codice questi causano semplicemente dolore e non ne valgono la pena a meno che tu non fornisca i tuoi pdb a esterni.Come avresti uno di questi orribili pdb spogliati?Potresti averli se usi "binplace" con il comando -a.

Buona fortuna!Una vera storia di mini dump è una manna dal cielo per il debug della produzione.

Answer 2

Se crei direttamente dal tuo sistema di gestione del codice sorgente, dovresti annotare i tuoi file pdb con le origini del file.Ciò consente di recuperare automaticamente i file sorgente esatti durante il debug.(Questo è lo stesso processo utilizzato per recuperare il codice sorgente del framework .Net).

Vedere http://msdn.microsoft.com/en-us/magazine/cc163563.aspx per maggiori informazioni.Se usi subversion come SCM puoi controllare il progetto SourceServerSharp.

Answer 3

Potresti provare a utilizzare MS-DOS sost comando per assegnare la directory del codice sorgente a D:guidare.

Answer 4

Questa è la procedura che ho utilizzato dopo qualche problema simile al tuo:

a) Copiato sul server di produzione tutti i file EXE e DLL che erano stati creati, ciascuno con il relativo PDB corrispondente nella stessa directory, avviato il sistema e atteso che si verificasse l'arresto anomalo.

b) Copiato tutti i file EXE, DLL e PDB sul computer di sviluppo (in una cartella temporanea) insieme al minidump (nella stessa cartella).Utilizzato Visual Studio per caricare il minidump da quella cartella.

Poiché VS ha trovato i file sorgente dove erano stati originariamente compilati, è sempre stato in grado di identificarli e caricarli correttamente.Come nel vostro caso, nella macchina di produzione il drive utilizzato non era C:, ma nella macchina di sviluppo lo era.

Altri due consigli:

• Una cosa che facevo spesso era copiare un EXE/DLL ricostruito e dimenticarmi di copiare il nuovo PDB.Ciò ha rovinato il ciclo di debug, VS non sarebbe stato in grado di mostrarmi lo stack di chiamate.

• A volte, ho ricevuto uno stack di chiamate che non aveva senso in VS.Dopo un po' di mal di testa, ho scoperto che windbg mi mostrava sempre lo stack corretto, ma VS spesso no.Non so perché.

Answer 5

Nel caso qualcuno fosse interessato, un collega mi ha risposto a questa domanda via email:

Artem ha scritto:

C'è una bandiera da MinIdumpWriteMump () che può fare dump crash migliori che consentiranno di vedere lo stato del programma completo, con tutte le variabili globali, ecc.Per quanto riguarda Call Stacks, dubito che possano essere migliori a causa delle ottimizzazioni ...A meno che non si spenga (forse alcune) ottimizzazioni.

Inoltre, penso che disabilitare le funzioni in linea e l'intera ottimizzazione del programma aiuteranno molto.

In effetti, ci sono molti tipi di dump, forse potresti sceglierne uno abbastanza piccolo ma avere ancora più informazioni http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx

Tali tipi non aiuteranno con lo stack di chiamate, influiscono solo sulla quantità di variabili che potrai vedere.

Ho notato che alcuni di questi tipi di dump non sono supportati nella versione 5.1 5.1 che utilizziamo.Potremmo aggiornarlo alla versione più recente e 6.9, però, ho appena controllato l'EULA per gli strumenti di debug MS: il più recente dbghelp.dll è ancora a posto per ridistribuire.

Answer 6

Visual Studio ti chiede il percorso del file sorgente?Se non lo è, non pensa di avere simboli per lo stack di chiamate.L'impostazione del percorso di origine dovrebbe funzionare senza dover mappare l'esatta posizione originale.

Puoi capire se i simboli vengono caricati guardando la finestra "moduli" in Visual Studio.

Supponendo che tu stia creando un PDB, non penso che ci siano opzioni che controllino direttamente la quantità di informazioni nel PDB.Puoi modificare il tipo di ottimizzazioni eseguite dal compilatore per migliorare la debugging, ma ciò costerà le prestazioni: come sottolinea il tuo collega, disabilitare inline aiuterà a rendere le cose più evidenti nel file di arresto anomalo, ma avrà un costo in fase di esecuzione.

A seconda della natura della tua applicazione, ti consiglio di lavorare con file di dump completi, se puoi, sono più grandi, ma ti danno tutte le informazioni sul processo...e comunque quanto spesso si blocca :)

Answer 7

Visual Studio ti sta spingendo per il percorso al file di origine?

NO.

Se non lo è, non pensa che abbia simboli per il callstack.L'impostazione del percorso di origine dovrebbe funzionare senza dover mappare l'esatta posizione originale.

I simboli sono stati caricati correttamente.Mostra lo stack di chiamate, ma facendo doppio clic su una voce non mi porta al codice sorgente.Ovviamente posso cercare nei file la riga in questione, ma è un duro lavoro :)