I recompile my solution, and when it starts in debug mode I get this warnings around my breakpoint saying that it won't be hit.
There is a copy of the source code file that is different.
Why would there be multiple versions of my source code loaded when trying to debug?
I even do a clean compile and still get this error.
Visual Studio is usually pretty good at detecting when your source code doesn't match the code signature of your attached exe or dll process. So I suspect that it is one of two possible issues:
Your debug session's Platform/Configuration (e.g. Debug/x64) doesn't match the .exe or .dll compiled architecture. OR
What you think is a "clean compile" isn't really clean.
The only source code that Visual Studio knows about is the one in front of you. But when Visual Studio is debugging an .exe or .dll, it is attaching itself to the .exe or .dll process, using reflection, and analyzing the code of that .exe/.dll. It determined that your .exe/.dll doesn't match the Platform/Configuration you wish to debug, or its reflected source code doesn't match the written code that is in front of you in Visual Studio's IDE.
When you say that you do a clean compile, make sure that it is really really clean (don't rely on the Visual Studio "Clean" feature. It's not reliable in all cases. For example, if you have created Build Events that copy contents pre- or post-compile. Instead, delete your project's /bin and /obj folders, then recompile. That will ensure your binaries always match your latest code for debugging. Do this a few times, and see if you still get the issue.
I had same error in VS 2019 .I solved that way;
Tools->Options->Debbuging->General and "Require source files to exactly match the orginal version" deselect that option
I have a large solution in Visual Studio 2012 which consists of executables and class library projects.
When debugging the application the breakpoints in one particular class library project are not being hit.
I looked at the Debug> Windows> Modules window to check the status of the symbols for that project and it says "Cannot find or open the PDB file".
It also says "No" under the "User Code" column.
I notice that there are a few other of the custom projects in the solution that are showing "No" in that column and their symbols are also failing to load. Anything with a "Yes" under "User code" seems to have had it's pdb loaded no problem. But I'm not sure if this is relevant.
I have used dumpbin /headers on the dll and the path for the pdb file is present and correct.
The module is definitely not in the exclude list for the symbol loading.
I have also tried right clicking on the entry in the modules window, selecting "Load symbols" and navigating to the path given in the dll header. When I select the pdb it says "A matching symbol file was not found in this folder".
I get this after I have deleted these folders and files, cleaned the solution, closed it and rebuilt the whole thing.
The pdb was definitely built at the same time as the dll in question.
So clearly the problem is the "cannot open the pdb" portion of the error message.
I have tried this on 2 computers and both are exhibiting the same behaviour.
Can anyone offer any suggestions on where to go from here, and perhaps why on earth the built pdb corresponding to the dll won't load for it?
I tried a few tools to check if the pdb and the dll actually matched, and using chkmatch I could see that the GUIDs in the dll being run and the pdb in the obj folder didn't match.
So it turns out that although the dll and pdb in the project's obj folder are a match, the dll that was actually getting copied to the application's destination folder by a post-build event was the old dll from the previous build.
The post-build event was running before that particular project had built, or at least finished building, and was copying in the existing dll from the bin which was subsequently overwritten by the continuing build.
I have resolved the problem by editing the project dependencies for the solution and ensuring that the project with the post-build event is dependent on the project that wasn't loading, and now the pdb loads during debug.
I simply deleted bin and obj folder from the startup project folder and rebuild the solution.
For me I just deleted the project from IIS and created it again and it works fine
For me it helped to use chkmatch tool and then just close and open visual studio, make clean and rebuild. Now my pdb gets also loaded. You can make sure it does, as Nanhydrin pointed out, from Debug -> Windows -> Modules - this view is only accessible during debugging.
I found that the project I was receiving the message about, was being optimized when built.
I went into the projects properties, Compile Tab, Advanced Compile Options... and unchecked the Enable Optimizations checkbox
In my case older version of referenced dll was in my GAC. Cleared it out, and it worked.
In my case there was a check mark on Enable Just My Code in Tools>>Options>>Debugging>>General.
I unchecked it and it worked.
Example Image
Reminder: Put the project into "Debug" configuration... for those like me who forget and feel silly.
I just had this issue and thought I would put my fix here, as it my help others (maybe even myself again?!) in the future...
Make sure that when you are attaching to the process on the remote server, that the "Attach to" is set to
Automatically determine the type of code to debug
To do this, When the server qualifier has been provided and a list of processes is visible, click the "Select" button next to the "Attach to" input.
Then, select "Automatically determine the type of code to debug" and OK out of the screen, then attach.
This fixed the issue for me, at least.
Deleted the project from solution and added it again to the solution worked for me. :)
Bit late to the party here - just in case this is helpful.
We have a couple of separate websites (in different solutions in Visual Studio). On initial load of one of the sites, we were making a call to the other site which would return an image.
Both of these sites referenced a common DLL, but while working on one site, had not realised that the other site had been left in a 'Release' build - after the site loaded, the offending DLL was rebuilt, but without symbols.
Kudos to Nanhydrin for both mentioning the modules debug window (very helpful) and for putting me on the right track with the post build event.
Answer from another thread that worked for me: https://stackoverflow.com/a/28476665/5969306
- In Visual Studio: Project Properties -> Build -> Advanced button -> Debug info drop-down and make sure the value is not “none”.
I had a line like this in my debug window:
Symbols for the module 'MyModule.dll' were not loaded.
I removed the 'Optimize code' option in Project properties -> Build. And the error disappeared.
This issue may be due to wrong reference of dlls used in project.
Delete obj and bin folders in current project and build project again.
Check for permission to ASP.NET Temporary folder:
"c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files"
User of application pool has to have the rights to subfolder with ASP.NET files, something like:
root\60039743\c28e12ee
Check options from this answer: https://stackoverflow.com/a/38377530/6911991
Click Advanced and check that Debugging Information is set to FULL
Check Run Configuration in all projects in the solution
I had this issue , tried all the other solutions (it took 2 days !! I'm crying... !TWO DAYS!) But finally I realized that my file was registered in GAC, I removed it and the problem was resolved.
At the command prompt, type the following command:
gacutil –u <assembly name>
How to: Remove an Assembly from the Global Assembly Cache
Please check the dependency of your dll, if you added to the solution, this can cause failure in loading symbols.
I resolved this issue by disabling 'Use Managed Compatibility Mode' in the Debug->Options menu:
I used to be able to debug using Visual C# Express 2010 with no problem before. However, since I've opened my project using MonoDevelop (to port it under MacOS), I can't seem to be able to debug anymore.
The exact error message is available below:
A lot of people says to go in the configuration manager, which I'm familiar with, however, I can't seem to find it in the Express version.
Since you didn't have this issue prior to opening in Monodevelop, it more than likely changed something within the solution and/or project files. There are a number of posts on stackoverflow...
stackoverflow: no symbols
stackoverflow: no symbols when crossing module boundries
(From Răzvan Panda comment on the question)
... that talk about missing symbols. However, based on the information provided about monodevelop, I'd venture to guess that the IDE changed something within the solution and/or project files.
If your solution is under source control and you don't see any differences in these files, let me know. Otherwise, you could create a new blank solution/project file (from Visual C# Express 2010) and re-add all your files to it to get the default settings back and see if that resolves your issue.
EDIT: Also, keep in mind that there are ".user" files that I guess "might" have an effect on build/debugging configurations. If re-adding your files to blank solution/project files doesn't work make sure all the "extra" files like ".user" are not in the directory. Usually files like ".csproj.user", and ".suo". I've never had an issue deleting these they store local configuration changes that are not usually checked into source control.
I had same problem with Symbols when I added some dll to my project so what I did was to manually adding them. you can try going to tools > option > Debugging > Symbols and from there you can add the file root (in this case monoDevelop) and it automatically looks for all .pdb files and adds them to your environment. After rebuild it should be Okay.
Cheers
As George Duckett said:
Re. configuration manager, enable expert settings first. Tools->Settings->ExpertSettings. Then find it under Build->ConfigurationManager
Then changed it to Debug.
I've checked out a tag for a Visual Studio 2008 project into a new local folder. (The local folder is different than where I normally work on HEAD code.)
I did a 'clean' and 'rebuild' on the project -- which created a DLL file. It rebuilt successfully and is located in the correct build area.
When I look at the files in Solution Explorer, it shows the correct absolute path for all the files within the new folder.
The problem is that when I set a breakpoint and try to debug the code, it never hits the breakpoint. When I right click on the breakpoint and look at 'Location' it shows me a path to where the file had been in the HEAD area when it was uploaded into SVN. I don't see where it is getting that old path from.
Here's a small checklist of things that can go wrong:
Verify loaded Modules (Ctrl + D + M usually). See that your code modules are loaded from where you expect them to load.
When doing clean/rebuild, only the project's output is cleaned (if I have MyAssembly project that builds a MyASsembly.dll, only the file relevant for this project will be removed. Any other assemblies that are referenced are not deleted in the cleanup process.
Try to isolate the issue. Start debugging with F10 (step into the debugged code). See if the entry point is OK, but only some other code that you're trying to hit is taken from the wrong location.
After firing up the debugger, it might help to use menu Debug -> Windows -> Modules to see exactly where Visual Studio is loading the assembly from.
Also, verify that you are building in Debug mode. I hate to admit that occasionally I build in Release mode and then wonder why the debugger does not stop at breakpoints.
Visual Studio editor does not understand unix style end of line. try to use unix2dos util on the misbehaving source files.
A C# desktop application (on the Visual Studio Express edition) worked, but then it didn't work 5 seconds later.
I tried the following:
Ensure debug configuration, debug flag, and full debug information are set on all assemblies.
Delete all bin and obj folders and all DLL files related to the project from my entire machine.
Recreate projects causing the problem from scratch.
Reboot.
I have two Windows Forms projects in the solution. One of them loads the debug information, one doesn't. They both refer to the assembly I'm trying to get debug information on in exactly the same way in the project file. Any ideas?
I want to add here, mostly for myself when I come back to review this question, that symbols are not loaded until the assembly is loaded, and the assembly is not loaded until it is needed. If the breakpoint is in a library that is only used in one function in your main assembly, the symbols will not be loaded (and it will show the breakpoint as not being hit) until that function is called.
Start debugging, as soon as you've arrived at a breakpoint or used Debug > Break All, use Debug > Windows > Modules. You'll see a list of all the assemblies that are loaded into the process. Locate the one you want to get debug info for. Right-click it and select Symbol Load Information. You'll get a dialog that lists all the directories where it looked for the .pdb file for the assembly. Verify that list against the actual .pdb location. Make sure it doesn't find an old one.
In normal projects, the assembly and its .pdb file should always have been copied by the IDE into the same folder as your .exe, i.e. the bin\Debug folder of your project. Make sure you remove one from the GAC if you've been playing with it.
Check to make sure that you are not in release but in Debug.
When in debug:
First try rebuilding your project by right mouse click the project > Rebuild
If that doesn't work, try a clean of the project (right mouse click on the project > clean)
If that didn't work check this:
Right mouse click your project
Select [Properties]
Select the [Build] tab
Make sure [Define DEBUG constant] and [Define TRACE constant] are checked
Make sure [Optimize Code] is unchecked
Click the [Advanced] button at the bottom of the Build tabpage
Make sure that [Debug Info:] is set to [full]
Click [OK] and rebuild the project ;-)
(step 7 generates the .pdb files, these are the debugging symbols)
Uncheck the "Enable Just My Code" option in the
Tools/Options/Debugging/General
Just something simple to try - you may have tried it already.
Right click the Solution in solution explorer, click "clean solution", this deletes all the compiled and temporary files associated with a solution.
Do a rebuild of the solution and try to debug again.
I've also had troubles with breakpoints multiple projects in a solution - some compiled as x86, some as x64.
The selected answer led me to fix my problem. But I need to do a few things more:
Even with "Debug" selected in the dropdown:
And in the project Properties > Build:
The Visual Studio was not loading symbols to a specific project. So in that dropdown I select "Configuration Manager" and saw that the settings to my web project was incorrect:
Then I set that to "Debug" and it started to generate the .pdb file.
BUT I need to manually copy the PDB and DLL and put in the folder that VS was looking (here is where the selected answer helped me):
Sometimes, even though it gives you this error, the Breakpoint still gets hit, so just ignore the error.
This happens fairly often in the Views of an MVC web app, i.e. .cshtml.
I was able to fix the error by simply setting the option in the 'Attach to Process' to 'Automatically determine the type of code to debug' option as shown in the attached screenshot.
Simply follow the steps below:
Go to Debug from the menu bar
Click on Attach to Process
Near the Attach to option, click on the Select button
The Select Code Type window will appear
Now select the option Automatically determine the type of code to debug and click the OK button.
Debug > Windows > Modules to see what modules were being loaded put me in the right direction.
In my case IIS Express seemed to be loading a different DLL from the temporary ASP.NET files.
The solution?
Browse to C:\Users\<YOUR USER>\AppData\Local\Temp\Temporary ASP.NET Files\vs
Delete everything in this directory!
Check if your .pbd file is missing in your bin/Debug folder. If it is then go to "Properties" of your project, selected "Build" and then "Advanced" at the bottom. Choose "full" under "Debug info" in the new window that appeared. This was my issue and solved it for me.
In my case "Optimize Code" was checked in my project properties. This caused VS to see my assembly as "not my code", and in turn, it did not load symbols for it.
The solution was to uncheck this.
Try running visual studio as an administrator within windows.
You need to enable "Generate debug info" in compiler settings
I tried everything mentioned above, but nothing worked.
[Clean solution, and check for PDB files etc.]
Even publishing the same solution did not resolve the issue.
Then I went to back to what I usually do to resolve (fool this stubborn Visual Studio)
All I did was to make a deliberate change in code and publish the solution.
Then I reverted the change and published again.
Voila [PDB files rid of evil spirits].. Not a smart resolution, but this did work.. :-|
We found the cause of our problem. This code was using the "CodeBehind" attribute in the Page directive of the .aspx file instead of the "CodeFile" attribute (ASP.NET 2.0 and beyond). After days of desperation, a simple search and replace solved the problem.
Option "Start debugging, Debug + Windows + Modules" does not exist in Microsoft Visual Studio Express 2013 edition.
Unchecking "Use Managed Compatibility Mode" in Tools Options Debugging fixes this.
Webapplications (IIS Express) only:
Rightclick IIS Express Tray and close the IIS.
Clean Solution
Clean solution and Rebuild
Check the configuration is set to Debug
Make sure that the PDB file is in the Debug folder it self
From Debug menu click Enable All Break points
Make sure you're in Debug and not is release by choosing debug in the dropdown menu like you can see in the picture below.
Then, try cleaning your project by clicking the right button in your mouse on the solution in the solution explorer window and choosing Clean solution.
Then rebuild your solution by clicking the right button in your mouse on the solution in the solution explorer window and choose Rebuild solution
Check are the following two setting the same in Visual Studio:
Right click test project, go to Properties, Build tab, and look at Platform target
Mine are all set to "Any CPU" so x64
On the Main Menu bar, go to Test, Test Settings, Default Processor Architecture
Mine was set to X86
Changing this to X64 to match above setting made the built in Visual Studio menu “Debug Test(s)” work and hit breakpoints that were previously ignored with the message “The breakpoint will not currently be hit. No symbols have been loaded for this document”.
Update:
For Visual Studio 2019 the menus have been moved around a bit:
I also had the same issue what I rebuild the whole solution (including refereced projects) in x86( or x64)
Even though I set all of my projects to x86 from Configuration Manager (Build->ConfigManager) some of my projects were not set to x86.
So Just to make sure right click on the project and follow
project -> properties -> Debug Tab, verify Configuration and Platform.
The .dll where I want to stop debugger and the associated .pdb files where copied near the .exe file. Those files had an older date so I thought they weren't updated in the runtime. I manually deleted them, Visual Studio create another pair AND put this new pair near the .exe. Now the breakpoint works!
Maybe Visual Studio cannot copy and REPLACE existing files (.dll and .pdb) near the .exe since there are another there. So if I deleted manually then VS could create new one near .exe.
I think that the root cause of the problem is that the Visual Studio use another file in runtime, no the file from the project, with the stop.
Instead of doing all these things just Close and reopen
Project Properties (then select your build config) > Build Tab > Advanced... > Debug Info (dropdown)
Set to 'all' or 'pdb-only' then rebuild
This took me a while tried other options above and for some strange reason debugging stopped working.
Tool -> Options -> Debugging -> General -> (untick) "Require source files to exactly match the original version" option
I was integrating a C# application with a static library using VS10 - which I'm new to. I wrote a managed code dll to interface them. I could set breakpoints everywhere but the static lib. I got the message described above - no symbols have been loaded for this document. I tried many of the suggestions above. I could see that the symbols weren't being loaded. I finally noticed a check box Configuration Debug, Enable unmanaged code debugging. That allowed me to set breakpoints in the static lib functions.
In my case, I was compiling a class library (DLL). No modules seem to be loaded in Debug -> Modules, so I couldn't even load the symbols manually.
My solution was to add this line to my code:
System.Diagnostics.Debugger.Launch();
Once this code is reached, an exception is triggered and .NET Framework shows a dialog box asking which Visual Studio (i.e. new instance of VS 2008, new instance of VS 2013, etc) you want to use to debug the program. You can choose the existing instance of VS with your project loaded. This will attach the process to your VS session and load all symbols, and now you can debug your project.
Of course, the compilation has to be done using the Debug configuration, not Release.
For an ASP.Net application, check the properties of the site, ASP.NET tab. Ensure that the correct ASP.NET version is selected.
I think the source if this error is, the debug symbols have a hard time surfacing to the solution after building for release.
I tried all the other answers -- generally, regenerating .pdb symbols or checking their location, cleaning and rebuilding project, ensuring active configuration is not Release etc.
What eventually worked for me is right-clicking on the project in solution explorer > Debug > Start new instance.
After trying a bunch of these, the thing that ultimately worked for me was this:
In Debug > Options > General, uncheck Enable Edit and Continue.
this happened to me after copy paste another webservice asmx file into an existing webservice, resulting in the same error when trying to debug the recently added service, to be able to debug I had to start without debug, then attach to the process. its weird but its the only way i found to be able to debug.