Why do my PDB's for my VB6 project not match the generated dll?

Question

I have a VB6 project and have enabled it to generate pdb files (this shows how to do that). However I can't debug with them and when I check them with symcheck I get this output:

>SYMCHK: MyFile.dll         FAILED  - MyFile.pdb mismatched or not found

>SYMCHK: FAILED files = 1

>SYMCHK: PASSED + IGNORED files = 0

I've checked with the verbose output that its finding the pdb (even moving it to a directory that its checking) but it just doesn't seem to want to match.

What might cause this and what can I do about it?

Nutt

try an older windbg/symchk version. I think MSFT updated the PDB format over the years, and maybe the new versions can't understand that older format from VB6. – Callis

have you tried my advice and used older debugger version? – Callis

Possibly a user identity issue ? – Fortran

Answer 1

You can try setting the compatibility of your VB6 project. It is clearly explained here: http://www.techrepublic.com/article/demystifying-version-compatibility-settings-in-visual-basic/

Maybe the change in the associated GUID causes the pdb mismatch.

Juggle

Answer 2

I experienced the same issue with Visual Studio (it was on a c# project). Because you didn't provide many information about your environment setup it's hard to tell the exact causes of the problem.

Because I have no experience with Visual Basic IDE I will propose causes of the problem with Visual Studio. Depending on your projects and setup this could be applicable or not to your VB IDE. Just try to apply them to it.

So here is a non exhaustive list of potential issues that may be causing this behavior with visual studio:

1. The dlls used by your program are cached ones
   • This can occur if your executable is using cached version of the dll (this is also known as shadow-copying). Often these files are in a temporary folder. To fix it, one has to simply delete these temporary files.
2. Your debugger is trying to load modules and symbols at the wrong place
   • For instance Visual Studio can be set to load modules at a specific place.
     To fix it one has to fix the place where modules are loaded (Ctrl + D + M usually).
3. Your clean/rebuild operation only rebuild the output project.
   • Visual studio may rebuild only your output project while you wanted to rebuild all of your solution.
     To fix it, one has to check it is correctly rebuilding the whole solution.
     Note that your clean operation may not delete references that are referenced by the project but not relevant to it. These files will remain in the output folders until you delete them.
4. Visual Studio has entered a unstable state and probably need to be restarted.
   • I count no more the numerous times where a simple restart of my Visual Studio instance fixed most of the weird compile-time behavior.
     To fix it one has to simply restart Visual Studio.

Usually a kind of bullet-proof way to go when you encounter this is to :

• clean the solution
• delete every bin and obj folders in each of your projects
• delete any temporary folder used for shadow-copy
• perform a rebuild

Goss