Symbols (pdb) for native dll are not loaded due to

Question

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.)

Answer 1

in Windbg try using the .symopt +40, this will force loading the pdb.

Answer 2

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.