WinDbg doesn't load symbol file that is created using the same source but built at a differnt time than the original

We released a product (C#.NET library) and didn't store the pdb file of the library, assuming that we can always generate symbol files using the same source code.

Now, we want to analyze crash dump (mini dump) file of an application that is using our library. Since we didn't store the pdb file, I created a new one using the same source code (using the same tag in SVN). Then I tried WinDbg and provided the pdb file, but the debugger didn't like it.

Since the source code is the same, I think the only difference is the date the build was done (We are using the same machine for releases). Can this really cause the debugger to not load the symbol file? How does WinDbg identify a symbol file?

If I am sure that the symbol file is identical to the original one (except the date), is there a way to force WinDbg to load the symbol file?

Thanks.

Note: If I make a new release and artificially create a dump file, symbols are loaded pr开发者_如何学Pythonoperly.

---

Rebuilding without changing the sources will change the pdb file. See John Robbins' blog entry PDB FILES: WHAT EVERY DEVELOPER MUST KNOW for the gory details.

You need to tell WinDbg to be less picky about the symbol files it's prepared to load. From (a slightly elderly) WinDbg helpfile:

SYMOPT_LOAD_ANYTHING

This symbol option reduces the pickiness of the symbol handler when it is attempting to match symbols.

This option is off by default. Once the debugger is running, it can be turned on or off by using .symopt+0x40 or .symopt-0x40, respectively.

---

"Can this really cause the debugger to not load the symbol file?"...

Yes: Each time a binary + pdb is build, they get a new GUID. So in addition to the timestamp difference between your dumpfile and new PDB file, the GUIDs will be off.