I simboli (pdb) per le DLL native non vengono caricati a causa del passaggio di post-produzione

Question

Ho una DLL di rilascio nativa che è costruita con simboli. C'è un passo post-build che modifica la DLL. La fase di post-produzione esegue una certa compressione e probabilmente aggiunge alcuni dati. Il file pdb è ancora valido, ma né WinDbg né Visual Studio 2008 caricheranno i simboli per la DLL dopo la fase di post-generazione. Quali bit nel file pdb o nella DLL dobbiamo modificare per ottenere WinDbg o Visual Studio per caricare i simboli quando carica un dump in cui viene fatto riferimento alla nostra dll di rilascio?

È la dimensione dei file che conta? Un checksum o un hash? Un timestamp?

Modificare la discarica? o modificare il pdb? modificare la DLL prima che venga spedita?

(Sappiamo che il pdb è valido perché siamo in grado di usarlo per ottenere manualmente i nomi dei simboli per gli indirizzi nei dump callstack che fanno riferimento alla DLL rilasciata. È solo un dolore totale negli * ss farlo a mano per ogni indirizzo in un callstack in tutti i thread.)

Answer 1

This post mi ha portato a chkmatch. Sul dll trasformati, chkmatch mostra queste informazioni:

 
Executable: 
TimeDateStamp: 4a086937 
Debug info: 2 (CodeView) 
TimeStamp: 4a086937 Characteristics: 0 MajorVer: 0 MinorVer: 0 
Size: 123 RVA: 00380460 FileOffset: 00380460 
CodeView signature: sUar 

Debug information file: 
Format: PDB 7.00 
Result: unmatched (reason: incompatible debug information formats) 

Con lo stesso pdb contro la dll pre-elaborati, riporta questo:

 
Executable: 
TimeDateStamp: 4a086937 
Debug info: 2 (CodeView) 
TimeStamp: 4a086937 Characteristics: 0 MajorVer: 0 MinorVer: 0 
Size: 123 RVA: 00380460 FileOffset: 00380460 
CodeView format: RSDS 
Signature: (my guid) Age: 19 
PdbFile: (my path) 

Debug information file: 
Format: PDB 7.00 
Signature: (my matching guid) Age: 19 

Ho aperto entrambe le versioni del dll e sono andato a offset 00380460. Nella versione originale, abbastanza chiaro vedo il nome del pdb, ma nella versione post-processata non ci sono informazioni pdb su quell'offset. Ho cercato il percorso pdb e ho trovato lo stesso blocco esatto - solo con un offset diverso. Poi ho fatto la ricerca bin per i byte "38 00 60 04" nella dll originale. Guardando lo stesso offset nella DLL elaborata, ho trovato gli stessi byte. Così ho regolato il RVA e l'offset (che si trova abbinando i byte). Bingo! Ora chkmatch riporta esattamente gli stessi risultati della dll elaborata come originale (a parte RVA e FileOffset che ho modificato).

Modifica: Confermato, ora Visual Studio carica i simboli per i dump che fanno riferimento alla DLL elaborata.

Answer 2

in Windbg provare a utilizzare il .symopt +40, questo imporrà il caricamento del pdb.