"PDB does not match image" error in C# VS2010 project

Question

I've been using a library in my code base for a while now, and I wanted to debug right into the library level. To do that, I downloaded the source code and included the project as an existing project into my C# solution. I then had my other projects reference that project instead of the downloaded .DLL.

Once the project was referenced instead of the DLL, I ran my solution through the debugger and tried to step into a function call that would have called into the external project, but it stepped right over it. While debugging, I opened up the "Modules" window and saw that the DLL's Symbol Status read "PDB does not match image", which is the likely cause of not being able to debug this project.

My question is simple, why does the PDB not match the image if my project is directly referencing the .csproj file as a reference? There should never be any ambiguity as to what version to run.

Marxismleninism

Try cleaning the solution. – Messick

Do you have the referenced project configured to build debug symbols? – Deitz

@Messick Cleaning the solution doesn't solve the problem. The .pdb file is present in the build folder (along with the dll) – Marxismleninism

@DarrenKopp It is definitely configured to build debug symbols. I verified that the pdb files are present, as well – Marxismleninism

Timestamp on PDB file match the compile time ? – Sugared

I remember fixing it once by loading the symbols manually (in the Modules window, right lick, Load Symbol->Symbol Path). After that, I did not need to do it again. – Sugared

Answer 1

I've run into this issue before when I have another project open that also references the DLL and uses its debug info (PDB). Basically the other project puts a file lock on the PDB in the referenced project and when you compile or debug the referenced project, it quietly fails to generate an up-to-date PDB file.

If this is what is going on, make sure you have no other apps running or instances of VS open that reference your DLL, and then seek out and delete all copies of the PDB from beneath the BIN and OBJ folders, then recompile it.

I hope that helps.

Huesman

This is half of the issue, it seems. Closing anything else that might be using those DLLs/PDBs doesn't seem to help. However, if I overwrite the DLL/PDB files in my application's /bin directory with the dlls from the library's /bin directory, things work out as expected. So, it does seem to be that something is wrong with how the files are being copied to my application's /bin directory. Odd behaviour. In any case, it's not ideal but manually copying the files works in the short term. Thanks – Marxismleninism

This was exactly my issue. I was trying to debug in VS while it was running in a command window. – Pallaten

@Marxismleninism is absolutely right. I just checked at my end also and I found that the size and modified date both DLLs are different, but it should be the same. I am copying DLL & PDB files in post build event and I guess it is not copying latest dll file to destination folder. – Element

Solution: I had to stop IIS and build the project. It then copied all my files as expected. – Element

Answer 2

Sometimes it happens because you might have build the project as a release.

Right click on the solution and click on "Batch Build" > Check all your projects and click "Clean"

Including

Answer 3

For me this happened for an Excel Add-In. I went to the modules window to see why it wasn't loading for my dll. I looked at the folder where the .dll was located and went to that location. There was an .ini file in that location. Opening it revealed the install location of my application, which turned out to be in "C:\Program Files\" as opposed to the bin\debug location of my project.

Basically I had an old version of the add-in already installed that was getting loaded up upon me trying to debug the project. I uninstalled the old project, deleted the old .dll location in "C:\Users[user]\AppData\Local\assembly\etc..." and voila, the debugger loaded up the newly compiled dll.

Garrott

Answer 4

Faced same issue, it was due to old assembly and latest PDB. There was mismatch between both. The assembly was built properly, but again my post build dll copy script was overwriting it with older one. Removing the dll from post build script resolved issue. Need to ensure that dll or pdb are up to date when debugging finally commences.

Chalk

Answer 5

This happened to me today while I was trying to debug notepad++ dll plugin , I had to change build output directory to notepad++'s plugins directory and set the Debugger to launch notepad++ instead of the current project dll to proceed with set breakpoint. This had me nuts as Visual Studio 2019 was telling me that SYMBOLS were not loaded for the plugin dll which I was trying to debug.

Finally checking the modified date and time as others here suggested, made me realize the pdb was not up to date with the the build output dll timestamp. I tried rebuilding the solution but the pdb generated has same older timestamp though I delete them manually and initiate build. So all I had to do was to make a change in the source code by deleting a white space and rebuild. Voila! this time I got the debugger to load the symbols for my dll automatically and hit the set breakpoint.

Maybe cleaning the solution also might have worked.

Derwin