none
The symbol file im.pdb does not match the module RRS feed

  • Question

  • Hi,

    I am having problems trying to load the symbol database for debugging. The visual studio debugger simply refuses to load the debug symbols, stating that it does not match my dll, even though it was generated at the same time during the build event.

    Neither the pdb nor the dll was modified in any way, so I don't get why the VS debugger still refuses to load the pdb. Is there something I can do to force it to load it? As far as I can tell, the signatures of the dll and the pdb matches perfectly.

    Thanks!
    Wednesday, February 20, 2008 11:28 AM

Answers

  • If you right click on the module in the modules window the debugger will show you were it looked for symbols and why it didn't load them.

     

    If it is telling you that the symbols don't match, I strongly suspect that the symbols actually don't match. While there is a first time for everything, on my years on the debugger I have had probably hundreds of users ask a similar question and every single time it turned out that the symbols really didn't match.

     

    Gregg

     

    Wednesday, February 20, 2008 10:51 PM
    Moderator

All replies

  • If you right click on the module in the modules window the debugger will show you were it looked for symbols and why it didn't load them.

     

    If it is telling you that the symbols don't match, I strongly suspect that the symbols actually don't match. While there is a first time for everything, on my years on the debugger I have had probably hundreds of users ask a similar question and every single time it turned out that the symbols really didn't match.

     

    Gregg

     

    Wednesday, February 20, 2008 10:51 PM
    Moderator
  • Did anybody solve this problem?

    There are a lot guys having this problem but no answer from Microsoft (bad answer = no answer). We are facing the same problem: "PDB does not match image". How can it be that the pbd file generated by cl or link (whichever does this) does not mach the output file (exe or dll). This means there is either a bug in the generating tool (cl.exe or link.exe) or a Visual Studio 2008 bug.

    Our project generated one exe file and one dll file. No warning are shown during compilation and linking. The symbols for the exe are loaded, but they aren't for the dll. The probing paths include also the pdb file path but for that, there is the famous message: PDB does not match image.

    Did anybody find workarrounds for this? (Restarting VS makes no sense in our case, because we attach VS debugger to the exe process)

    Regards,
    Gabriel
    Tuesday, March 24, 2009 2:58 PM
  • Apart from the most obvious reason that symbols in fact does not match the generated module - dll or exe - there could be another reason. If the process you have attached to debugger is not the one whose module you are trying to debug into, you'll see this error. Make sure the VS debugger is attached to the right process, then symbols should be loaded if they in fact match.

    Thanks

    Dolly

    Thursday, June 18, 2009 6:51 PM
  • I am truly amazed by the lack of information in either response...  Is everyone is reading the same MS documentation, which in most cases raises more questions than answers anyway, however there still is no resolution to the problem... as stated in the original problem "How do i".. lol the first answer isnt even an answer derogatory statement which leaves the question unaswered.   Then the second "answer" is simply a reverb of the first.

    Want an answer to this problem well here it is.

    MS has a bug, which they can not fix because it is so elusive and can be caused by many different reasons. 

    There you have it... the answer... lol just as good as the other two huh except the truth.

    Forgot to add... did you see the problem in VS2003?  Neither did I.
    Tuesday, July 14, 2009 7:52 PM
  • I tried everything under the sun and likely there are multiple issues - but this is where I went wrong.
    When I setup my remote debugging monitor, I couldn't get it to let me attach in using authentication, so I used "No Authentication (native only)".  I was able to connect just fine, but always got the "symbol file xxx.pdb does not match the module" issue when trying to manually load the symbol file ('cause it didn't load automatically).
    Finally ran the remote debugging monitor as administrator, set it to Windows Authentication, attached to the remote process and viola - everything worked fine including it loading the symbol files.  The only bug for me was the error message from MS - totally misleading.
    Thursday, August 6, 2009 12:00 AM
  • I am also having this problem. I have a Solution with a project that builds as an .EXE and another project that builds as a .dll. All the code in in the same Solution - 2 projects. Everything builds and runs but no way to step into the .dll code. Tried evrything. Whatever Microsoft is doing, something is wrong. Too many folks are having this problem and wasting their time on it. If MS were responsible, they would get the code sample from (me) and solve the problem and post the solution or fix their system I think.
    Sunday, August 9, 2009 2:59 PM
  • SoftRite here - found my problem... Still love to blame Microsoft though and WILL every chance I get! (giggle) What was going on was for some reason ANOTHER version of my program .dll was residing in Win/System32 directory! It was getting loaded instead of the one in my project even though everthing looked perfect. When I killed the one in Sys32, mine loaded along with debuginfo... Oh well
    Sunday, August 9, 2009 4:38 PM
  • I'm having similar problems.  I was able to to debug my active x control in IE until I added the zlib.  This is al using VS 2005.  I can still debug the activex control with VS 2003 and 2008.  I'm getting a "Unknown symbol handler error." in the Symbol load information, but only in VS 2005.
    dev
    Monday, August 10, 2009 10:46 PM
  • I think this is caused my MS removing the ability to specifiy which build you are running... I use this method to debug windows services.  I registered the service under the debug build, and but I use a macro to build and auto attach to the process once it starts.  It worked at first, but soon after it quit working.  I work around it by first making a debug build, then the release build.  Its dumb that I have to do this, but thats MS for ya. 

    Also its pretty dumb that people can mark their answer as the answer on this site... even though you may not agree with the answer or that they even understand the issue to begin with.
    Sunday, September 6, 2009 4:04 PM
  • I just fixed this for myself after a couple of stressy hours...

    1. Make sure you're on Debug mode and attaching to the right exe

    2. In the attach box (ctrl alt P), make sure that "Attach to" is set to "Automatic" - I had changed this a few days before for c++ dll debugging. gotcha!

    3. Attach to the exe and not the .vshost.exe

    BTW I always add the current configuration and platform dropdowns to the VS IDE toolbar, so you can always see that you're in Debug not Release.

     

    Wednesday, September 22, 2010 1:50 PM
  • Although the message is too vague to be useful, in my case it was correct. The DLL and the PDB files didn't match - my DLL wasn't getting copied to the device I was debugging, so the older DLL really didn't match the newer PDB.

    @Gregg: your comment about the "modules" window just added to an already confused situation. In the Visual Studio 2005 Professional debugger, there is no such window.

    After I copied the matching DLL manually, I was able to load the symbols and debug the code.

     

    Thursday, October 28, 2010 8:47 PM
  • -Check if you're not running x64 msvsmon.exe while trying to debug x86 module and vice versa;

    -Check you're running msvsmon.exe as administrator;

    -Check you have Options/ No Authentication (native only) + Allow any user to debug selected;

    -Check you have Transport = Remote (Native only...) when you attach the debugger;

    -Check the solution build folder (where *.pdb are) has the same version of the executables you're trying to attach the debugger to (this is in case you copy them, in a virtual machine for example as I do);

    Wednesday, February 16, 2011 9:01 AM
  • Eleven years later this is still perfect advice.  I spent 3 hours with blinders on trying to understand this - before I pulled myself out of the details and notice that I took for granted the PDB was from the same build.  Nope.

    If you are reading this - pull yourself out of the details and ensure the dll and pdb were created at the same time!  This error message is pretty darn accurate. 

    :) - John

    Tuesday, August 20, 2019 7:15 PM