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

  • Question

  • Hi all,

    I'm having a problem with debugging -- symbols for my assembly are not being loaded.  Long story short, I'm writing a WSS 3.0 workflow and deploying it on a remote SharePoint server.  So far everything is OK, and the workflow runs.

    To debug the workflow, in theory, what I need to do is to attach to the ASP.NET process on the server (w3wp.exe).  From there, I should be able to debug the workflow code. 

    In practice, what happens is that VS complains about symbols not being loaded, and I'm not able to debug.  My workflow assembly is being loaded -- I can see it in the modules window.  However, for symbol status, I get `Cannot find or open the PDB file'.  If I go through the symbol load information, I get this:

    C:\WINDOWS\assembly\GAC_MSIL\SimpleWorkflow\3.0.0.0__d0af882641d96b1a\SimpleWorkflow.pdb: Cannot find or open the PDB file.
    D:\Home\mpenkov\My Documents\Visual Studio 2005\Projects\SimpleWorkflow\SimpleWorkflow\obj\Debug\SimpleWorkflow.pdb: Cannot find or open the PDB file.
    ...

    It's looking for the PDB file everywhere, including the project obj directory.  I've checked that the PDB file is in the obj directory.

    So next, I decide to try and load the symbols manually (right-click on SimpleWorkflow.dll in Modules window, Load Symbols) and point it to the PDB file in the obj directory.  I get the following error: `The symbol file SimpleWorkflow.pdb does not match the module'.

    At this point, I have a number of questions for those who are more knowledgeable in the ways of VS 2005 debugging.

    1) Why is this happening?
    2) How does VS determine that the PDB file doesn't match the assembly?  What does it look at?
    3) How can I rectify this?  Can I somehow force it to load the symbols from the PDB file anyway?

    Lastly, a few points that can clarify my position:
    1) The project is being built in Debug mode
    2) The assembly is signed.  This is a requirement for deploying stuff to SharePoint -- it needs to have a strongname

    I hope I haven't missed anything.

    So, does anyone have any suggestions?  It would be really great, as this thing has me really pinned down at the moment.

    Cheers and regards,
    Michael

    Sunday, October 8, 2006 6:45 AM

Answers

  • This scenario is not supported in the Visual Studio debugger.  You need the original dll's PDB

    John

    Tuesday, October 31, 2006 5:04 PM
    Moderator

All replies

  • The error "does not match the module" is caused when the signatures (actually a GUID) built into both pdb and module do not match.  Common caauses are that updates are not propogated to the GAC properly (for instance did you uninstall and then install the assembly in question after your last rebuild?

    John

    Wednesday, October 25, 2006 6:27 AM
    Moderator
  • We have a DLL at customer site and need a matching PDB file for debugging purposes. We can rebuild the exact DLL, plus matching PDB, internally.

    How can we make debugger accept the new PDB as a match to the DLL at customer site?
    They are not from the same build, but based on the exact same source code.

    Monday, October 30, 2006 9:22 AM
  • This scenario is not supported in the Visual Studio debugger.  You need the original dll's PDB

    John

    Tuesday, October 31, 2006 5:04 PM
    Moderator
  • I'm just adding this in case it is of use to anyone. This reply is not entirely relevant to mpenkov's issue.

    For a project solution (mainly C++) created with VS2005, I have rebuilt (using Incredibuild) the solution from outside the IDE. Subsquently, when attempting to debug, the VS debugger is reporting all the modules as "No symbols loaded".

    When trying to manually load the symbols, I get:

    "The symbol file <module_name>.pdb does not match the module"

    This is the first time I have seen this happen. Incredibuild is normally reliable.

    To fix the problem, I closed and re-opened the IDE then loaded the same solution. I then changed the startup project, to be prompted for the executable to debug.

    Either one, or both of the above, fixed the problem.
    Friday, November 30, 2007 3:30 PM
  •  

    Hi,

     

    I have recently had this - VS2005 - and it was particular to a remote debugging issue.

     

    I was only shipping the EXE/DLLs, but when I attached remotely, it could not find the symbols. No matter where I put my symbols (or used symstore in a vain hope that it was something to do with my dir structure). The PDB files were the ones compiled at the same time as the EXE/DLL (in 1 project so all together!!!).

     

    Looking at "Symbol Load Info" it shows the debugging trying to load the symbols from paths that could ONLY have been on my machine (something like: C:\Source Code\VSS\ICAP RTD Framework\Release\IMDConnect Feed Plugin Setup)...

     

    I managed to put the PDB files onto the remote machine into the directories where the installed files were running from. Then, within my remote debugging session in VS2005, I clicked LOAD SYMBOLS, and sure enough, they managed to load!!!!!!!!!!

     

    And this time "Symbol Load Info" shows the path the installs were running from on the remote!!!

     

    I think this is a bug - VS2005 should be able to load LOCAL symbols which match the REMOTE debug session - OR???

     

    Regards

      James

    Tuesday, January 22, 2008 12:16 PM
  • John,

    I am beyond frustration with this issue. Is there a solution? I am running visual studio 2008 and cannot debug Javascript. I continue to get "The breakpoint will currently not be hit. The document is not loaded" message.

    I've tried several possible solutions to this problem that I've come across in forums to not avail. I am about to flip!

    Please point me in the right direction... I'm begging

    Thanks
    Friday, February 1, 2008 8:16 PM
  • Please tell me you found a solution for this problem.

     

    My situation is identical except I'm working with MSCRM 4.0.

     

    I also tried loading the symbols manually and received the same message.

     

    I've looked for two days at all the posts on this subject, but no solutions.

     

    Thanks

     

    Desperate Derek

     

    Saturday, March 22, 2008 5:01 AM
  • Hi All,

    I managed to solve this issue which seems to be some kind of bug in VS2005.
    I was building in Release configuration and optimize code = false, but it was complaining the debug symbols did not match the assembly, so I built in Debug configuration and manually copied the .pdb to the Release output directory. Things went smoothly and the symbols were loaded.

    Hope this helps!

    Felipe
    Monday, April 14, 2008 2:32 PM

  • John Cunningham's replay is not an answer. There is the ability to debug workflows. So how do we load the symbols?
    Tuesday, July 22, 2008 6:54 PM
  • I am having the same problem. 

    I added a new empty project to my solution and ever since I have received messages about symbols not being loaded for the document.  Then I read about the modules window and manually loading the symbols but I get the "The symbol file xxxxx.pdb does not match the module." msgbox.  My .exe was pointing to a .pdb file in another directory (outside of the solution directory).  I moved this directory and then was able to try to manually load the symbols which did not work.

    I'm working with the CF - a WM6 device.

    This is a fairly serious issue for us.

    Matt
    Tuesday, August 5, 2008 8:46 PM
  • Same problem here. Same symptoms, everything. Serious issue for us too. We have VS2005 SP1.
    Thursday, January 22, 2009 5:03 PM
  • Had the same problem here.
    Restarting Visual Studio solved everything, as usual :)

    Guess I got lucky.

    Restarting seems to be the general solution with Microsoft products. Too bad it doesn't work like that in real life.
    Monday, March 9, 2009 6:40 PM
  • 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
  • My problem was caused by one of my projects holding on to an outdated version of another project. For example: projectA references projectB but when I rebuilt the solution projectA didn't get a new copy of projectB (don't know why). So when I gac'ed, the old version of projectB's dll was installed. I fixed it by changing "Copy Local" to true for projectB in projectA's references.

    It would be nice if the IDE gave a good reason why the PDB's didn't match. In case, the version of projectB in the gac was couple of days old!
    Friday, May 29, 2009 2:13 PM
  • 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 3:37 PM
  • SoftRite here - found my problem... Still love to blame Microsoft though and WILL every chance I get! (giggle) What was going on was forsome 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:37 PM
  • I have the same problem. In the modules window of VS2005 "No native symbols in symbol file." is displayed and wenn I try to load the pdb manually I get the message box text "The symbol file ...pdb does not match the module". The dlls are not installed or located in the GAC. Have restarted and rebuild the project. What is wrong?
    Monday, September 28, 2009 2:28 PM
  • We have a mixed language project and what I can see is, that on all C# modules the symbols are NOT loaded while of C++ modules symbols are loaded. Any idea for the reason?
    Monday, September 28, 2009 2:45 PM
  • Check the article at -
    http://www.tech-archive.net/Archive/VisualStudio/microsoft.public.vsnet.debugging/2007-08/msg00009.html

    I was able to resolve my problem by Turning off the "Just My Code" option in Tools -> Options ->Debugging -> "Enable Just My Code"
    Tuesday, October 6, 2009 8:57 AM
  • Hy,

    I did hace the same problem for debugging a sharepoint web application.

    I resolved it by copying the pdb file on the remote server and referenced it in vs2008.

    Now i can debug the application.

    Regards

    Monday, November 9, 2009 11:55 AM
  • Did anybody solve this problem?

    There are a lot guys having this problem but no answer from Microsoft (bad answer = no answer ) .
    ...
    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

    Yeah, I must agree with that. There seems to be a lot of people of the likes of John Cunningham - MSFT (impressive - he even got 2 gold medals!!)
    Anyway, let me share a solution that worked beautifully for me - it might be the one that'll work for you guys as well (BTW, this was done in VS-2008):

    Right-click your project, select "Property Pages", then click on "References" (left-hand sidebar). Select the DLL from the right-hand panel and remove it.
    Then re-add it by clicking "Add" and selecting the DLL file from your "/bin/debug" folder. That should do it.

    I found it to be more straightforward and less intrusive than all of the other solutions around .

    Micro$oft Motto: "Where do we want you to go today?"
    Tuesday, February 9, 2010 1:11 PM
  • John Cunningham, this is definitely not the answer. My friend, let me give you a free advice: if you don't have an answer, don't post. No matter how many medals you may have, it does not pay to alienate an entire community with bad responses. And I think there should be a "vote as not helpful " , as this answer does not help anyone.
    Thursday, February 11, 2010 9:52 AM
    • Edited by OleksandrP Friday, March 5, 2010 2:43 PM mistake
    Friday, March 5, 2010 2:41 PM
  • Bug still exists in VS2005. When I copy the PDB (of Managed Code) to the remote side, I can do remote dubugging. If not and I try to load the symbols manually from the local location of the same PDB, I get still the error "The symbol file ... does not match the module". Thats really awfull.

    Project has just one exe which is be installed by copy deployment.

    Wednesday, September 8, 2010 12:39 PM
  • Hi

    Im debugging a asembly from a console application and i also had the problem specified.

    I solved it by GAC'ing the latest build and also adding the pdb file to the GAC location.

    I'm confused as my application is pointing to a dll in another folder.

    Fernando Pires Dustin

    Tuesday, March 1, 2011 8:17 AM
  • I was finally able to solve this by going into the project properties and renaming my assembly name and default namespace.  Then I deleted the OBJ and BIN directories in my project site and the published site.  Then I got out of VS (2010) and went back in and rebuilt.  It worked from there.
    Friday, April 1, 2011 6:25 PM
  • @fernandop1: I'm seeing a similar symptom with my Excel add-in in VS2010 Pro.  The PDB file is not loaded, so I can't debug properly.  Looking at the Modules window (Debug>Windows>Modules), I see that my code's DLL is loaded not from the project's bin\Debug directory, but from some weird location in AppData\Local\assembly\dl3.  There is, indeed, a DLL file there with the same name as my DLL from bin\Debug, but it's a completely different file.  Like you, I'm mystified by this file's location and appearance.  The DLL is not listed in GAC (checked using gacutil.exe from .NET tools).  If I delete AppData\Local\assembly\dl3, it gets recreated on the next debug run, with the wrong DLL in there again.

    I worked around the problem by manually copying my DLL from bin\Debug to the dl3 location over the incorrect one.  After that, the symbols loaded properly and I was able to debug.  But it's clearly a VS bug, since its internal procedure (whatever it actually is) fails to use the latest compiled DLL when I hit F5.

    • Proposed as answer by ldw3 Friday, May 13, 2011 3:16 PM
    • Unproposed as answer by ldw3 Friday, May 13, 2011 3:16 PM
    • Proposed as answer by dmyaho2 Monday, May 7, 2012 11:03 PM
    Wednesday, May 4, 2011 2:19 PM
  • I'm not sure if this will help.  I'm using VS 2008, but I had the same problem and solved it by going into Build, Configuration Manager, and setting it to Debug instead of Release
    Friday, May 13, 2011 3:17 PM
  • I just encountered this problem.  It was my bad. 
    I forgot that when I compile a DLL, it  needs to be deployed to the GAC.  If I build the dll and DO NOT deploy to the GAC, the GAC version does not match the version in Visual Studio.  By deploying to the GAC, the symbols were loaded successfully. 

    Not sure if this helps.


    • Edited by jd_hancock Tuesday, September 6, 2011 1:07 PM
    Tuesday, September 6, 2011 1:07 PM
  • Hi folks,

    My apologies for my absence, I have not been on the debugger team for a while.  Re-reading my response, it definitely came over a bit terse, so I want to apologise for that.  I'll clarify my previous response as thus.

    The scenario of forcing the debugger to load mismatched symbols is not supported in the debugger (option 3) above.  When I was on the debugger team, we closely monitored how folks were using this feature in the context of ntsd/windbg.  When using this feature, people would often forget that at that point, the debugger will happily lie to you since it is not to know that the symbols are mismatched.  This caused even greater confusion and customer frustration than getting the right symbols.

    Symbol matching is done by a GUID in both files that have to match in most cases.  As I read through the thread here, the actual number of paths into the "you are mismatched" are quite varied.  The debugger can show you which symbol files it tried to load by right clicking on the module in the module window and selecting "Symbol Load Information".  This may help track down which paths were searched and which dll/pdbs were loaded.

    In many cases, I've found that a variety of process hosts are loading previous copies of the dll, and not the one you last built, so that is something to watch for.

    I've asked the debugger team to get engaged on this thread to help folks who are having this issue.

    Thanks, and once again apologies,

    John


    John Cunningham [MSFT]
    Monday, October 3, 2011 6:53 PM
    Moderator
  • I have a few outstanding questions on this issue:

    First off, I'm seeing this happen with a project/solution for VS2008 Profession Edition and using the VS2008 Remote Debugger.

    1. Do we have to use the GAC in order for remote debugging to properly map *.pdb files to C# assembles of any type of project (Windows Forms, WPF, Silverlight, or WCF) running on another machine?

    2. Do we have to have the *.pdb files on the remote machine?  In the past, I could easily pull in the *.pdb files from the local dev machine instead of tainting the test environment.

    I tried using 'Remote (Native only with no authentication)' as a Transport, but this refused to load the *.pdb files even when manual selected from the Debug -> Windows -> Modules window.

    I tried using 'Default' as a Transport, but although I've set it up on the App Side and granted my logged in user account Debug priveledges, VS2008 is unable to connect (see attached image below).

    3. Does 'Default' require File Sharing to be enabled?  If so, why?  I did try and File Sharing is disabled for security reasons.

    4. If I don't care about authentication, why do I need to use stronger authentication just to debug?  Am I doing something wrong?

    5. When analyzing the network traffic, I noticed it failed to connect through port 137 (for netbios-ns).  Is this required on the app machine?

    After fixing File Sharing Support (enabling port 137), this next required DCOM to be enabled for the Remote Debugging Monitor to connect back to Visual Studio.

    6. Does Microsoft have a Tool that will repair the environment to make this easier?

    Dan





    • Edited by justdan23 Friday, January 6, 2012 4:20 PM
    Friday, January 6, 2012 2:04 PM

  • There you go again, MSFT, telling your customers what we need and don't need.  How hard would it be to bury a check box somewhere (not the default option) along the lines of "Load outdated debug symbols (I accept the risk)?"  Doing this would eliminate work stoppages caused by Visual Studio bugs. 

    Here is my work stoppage: I have this same, maddening issue in Visual Studio 2012, unable to debug my DLL that uses native C++ (no CLR).  I was able to debug this DLL without any issues using Visual Studio 6.  In VS 2012, I can exit, come back in, clean and rebuild the DLL AND  its PDB file. Verifying that the file dates and times match, I copy both the new PDB and new DLL to the same folder. When I run the app, I can see exactly which DLL module is loaded and which PDB file I am trying to load, and they from the same build. Still, VS 2012 WILL NOT LOAD the PDB file.

    So, tell me again, why did you remove this capability from Visual Studio 6? [Ironically, VS 6 was much better at knowing the PDB files were correct, so I didn't need an option to use outdated PDB files.  But I really need it with newer versions of VS.] Let's see, apparently, this was the reason: "people would often forget that at that point, the debugger will happily lie to you since it is not to know that the symbols are mismatched.  This caused even greater confusion and customer frustration than getting the right symbols."

    Why prevent experienced developers from doing their jobs so that you can avoid confusing inexperienced developers?  Especially when making it an option would prevent 99% of the confusion by junior developers?  I haven't been confused by out-of-date debugging symbols since my first week working with Visual C++, but if you feel it is necessary to prevent this, at least provide a work-around.  

    I don't fault you for the bug in VS that thinks my PDB file is out of date.  Windows environments have diverged so much and become so complicated there is no way that you can test all cases...  What really annoys me is when you take away my ability to do things I need, and that I used to be able to do.

    I guess that's just the imperious MSFT way.  

    Jim


    • Edited by jswksc Friday, December 6, 2013 12:50 AM
    Thursday, December 5, 2013 9:14 PM
  • Symbol matching is done by a GUID in both files that have to match in most cases. 


    John Cunningham [MSFT]
    Had the same problem. Inspired by the GUID comment, and having noticed that my DLL time stamp was out of date, I realized that the debugger was picking up a DLL image from somewhere else on my system. I did a search for all copies of my DLL, erased them, did a clean build, and the problem disappeared. This is not an MS bug. Granted, however, the error message could be more informative and saved the 2 hours I spent on this. For example, when I run into a problem that takes me hours and days to solve, I always decorate the error message, like "(nnnnn) timestamp: error msg (Hint! GUIDs may not match between, fx, EXE and DLL. Are there multiple copies of the DLL on your system?)" Okay, that's a little much, but you get my drift.

    RT

    Friday, July 31, 2015 6:31 PM