Les symboles (pdb) pour la DLL native ne sont pas chargés en raison de l'étape de post-construction

Question

J'ai une DLL de version native qui est construite avec des symboles. Il y a une étape de post-construction qui modifie la DLL. L'étape de post-construction effectue une certaine compression et ajoute probablement des données. Le fichier pdb est toujours valide, mais ni WinDbg ni Visual Studio 2008 ne chargeront les symboles pour la DLL après l'étape de post-construction. Quels bits dans le fichier pdb ou la DLL devons-nous modifier pour obtenir WinDbg ou Visual Studio pour charger les symboles quand il charge une sauvegarde dans laquelle notre version dll est référencée?

Est-ce la taille de fichier qui compte? Une somme de contrôle ou un hachage? Un horodatage?

Modifier la décharge? ou modifier le pdb? modifier la DLL avant qu'elle ne soit expédiée?

(Nous savons que le pdb est valide car nous pouvons l'utiliser pour obtenir manuellement les noms de symboles pour les adresses dans les callstacks dump qui référencent la DLL libérée.C'est juste une douleur totale dans le * ss. dans un callstack dans tous les threads.)

Answer 1

This post m'a conduit à chkmatch. Sur la dll traitée, chkmatch montre cette info:

 
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) 

Avec la même pdb contre la dll pré-traitées, il rapporte ceci:

 
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 

J'ai ouvert les deux versions du dll et je suis allé offset 00380460. Dans la version originale, assez clair je vois le nom du pdb, mais dans la version post-traitée il n'y a pas d'info pdb à ce décalage. J'ai cherché le chemin pdb et trouvé exactement le même bloc - juste à un décalage différent. Ensuite, j'ai fait bin chercher les octets "38 00 60 04" dans la DLL d'origine. En regardant le même décalage dans la DLL traitée, j'ai trouvé les mêmes octets. J'ai donc ajusté le RVA et le décalage (situé en faisant correspondre les octets). Bingo! Maintenant, chkmatch rapporte exactement les mêmes résultats pour la DLL traitée que l'original (mis à part le RVA et le FileOffset que j'ai changé).

Modifier: Confirmé, maintenant Visual Studio charge les symboles pour les vidages qui référencent la DLL traitée.

Answer 2

dans Windbg essayez d'utiliser le .symopt +40, cela va forcer le chargement du pdb.