问题
I have a native release dll that is built with symbols. There is a post build step that modifies the dll. The post build step does some compression and probably appends some data. The pdb file is still valid however neither WinDbg nor Visual Studio 2008 will load the symbols for the dll after the post build step. What bits in either the pdb file or the dll do we need to modify to get either WinDbg or Visual Studio to load the symbols when it loads a dump in which our release dll is referenced?
Is it filesize that matters? A checksum or hash? A timestamp?
Modify the dump? or modify the pdb? modify the dll before it is shipped?
(We know the pdb is valid because we are able to use it to manually get symbol names for addresses in dump callstacks that reference the released dll. It's just a total pain in the *ss do it by hand for every address in a callstack in all the threads.)
回答1:
This post led me to chkmatch. On the processed dll, chkmatch shows this 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)
With the same pdb against the pre-processed dll, it reports this:
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
I opened up both versions of the dll and went to offset 00380460. In the original version, clear enough I see the name of the pdb, but in the post-processed version there is no pdb info at that offset. I searched for the pdb path and found the exact same block - just at a different offset. Then I did bin search for the bytes "38 00 60 04" in the original dll. Looking at the same offset in the processed dll, I found the same bytes. So I adjusted the RVA and the offset (located by matching the bytes). Bingo! Now chkmatch reports the exact same results for the processed dll as the original (aside from the RVA and FileOffset that I changed).
Edit: Confirmed, now Visual Studio loads the symbols for dumps that reference the processed dll.
回答2:
in Windbg try using the .symopt +40, this will force loading the pdb.
来源:https://stackoverflow.com/questions/873210/symbols-pdb-for-native-dll-are-not-loaded-due-to-post-build-step