I have a dll built from mixed code in VS 2012. This dll is loaded from a .exe built in native C++.
When I debug the dll (via F5 from VS 2012), the breakpoints are not hit. The message is :
No executable code is associated with this line. Possible causes include: preprocessor directives or compiler/linker option
However when I run the exe from Windows explorer then perform "attach to process", all the breakpoints are hit.
I tried changing the debugger type to "Mixed", "Native", "Managed", I also played with debugging options but the results were all the same; except when the debugger type is "managed", the breakpoints seem to be loaded (a filled red circle appears instead of an empty red circle) but are not hit.
Can you please give me an explanation of this strange phenomenon ?
When starting a debugging section with the false debug path ( this can be set in the project properties ) it can happen, that the pdb will not be loaded, because the working directory is not at the executable with the pdb. So no information about the source location is there and the debugger can answer: No executable code is associated with this line.
When starting the application directly the working directory is normally the place where the application is located, the pdb get's loaded breakpoint get's hit.
When debugging the app check if the corresponding pdb get's loaded, just to be sure that everything is right here.
Related
I have a big application and I want to debug a given class. So I compile the DLL the class is in, in release and replace, in the application setup directory, the DLL and also add its PDB. I cannot do it in Debug since the application then does not work properly.
After doing that, I start the application and attach to it with the VS debugger. But my four breakpoints in the four methods I wish to debug exhibit the message "The breakpoint will not currently be hit. No symbols have been loaded for this document".
In an unsuccessful attempt to fix this, I have added the pdb I have copied to the installation directory of my application to the pdb locations in Debug | Options and Settings | Debugging | Symbols.
Why is this happening, can something be done?
I copied an existing project and renamed the folder. Now I get this error when I try to compile the application
debugging information cannot be found or does not match. No symbols loaded.
Do you want to continue debugging ?
If I click yes, it compiles and runs fine. But now I have to deal with that message. Just curious about what I change in the projects properties to get it to stop.
You probably have deactivated the debugging information for your project:
Right click on your project -> Properties
Configuration properties -> Linker -> Debugging
Switch "Generate Debug Info" from No to Yes
Rebuild your project and retry, it should now run without the message :)
The main reason is that you don't have a matching pdb and exe.
Some possible solutions:
You are compiling in release instead of debug
You need to clean/build or rebuild
You don't have your pdb files being generated in the same directory as the exe
You have a mismatching pdb, maybe the copied source is newer than today's date and something isn't building properly.
Try cleaning out all debug object files
You are attaching to a process that you started from a different location from where your build exe and pdb exist
Restart Visual Studio
This happens to me every now and then, while debugging code and making changes it seems like visual studio caches the pdb information and sometimes it gets stuck. Doing a Rebuild solution, deleting the pdb and creating a new one doesn't fix the problem.
Of course I do have the generate debug information on and all that it's needed, specially since this happens while debugging the code several times.
Visual Studio seems to be happy with the in-memory pdb and refuses to update it, regardless of time-stamps or even size changes in the pdb.
The only way to reset this is to exit Visual Studio (the IDE) and restart it again.
In some rare occurrences, the IDE might be still running in the background (process explorer shows it there) and might hold the handle to the file open. You can kill the process before restarting the IDE.
Good Luck
I just encountered this error in VS2012. It is definitely caused by a bug in Visual Studio, which reveals itself in situations when the local PDB file of the main project has the same name as the final PDB file for the entire executable (even if the two are located in different directories!)
Consider this example.
Solution consists of three projects: main, a, and b. main is the top-level project for the executable, while a and b are libraries linked into main.
In all three projects $(IntDir) variable is set to $(SolutionDir)\$(Configuration)\$(ProjectName)\. This means that project main dumps its intermediate files to Debug\main\, project a - to Debug\a\ and so on.
In C/C++ -> Output Files settings all three projects have Program Database File Name value set to $(IntDir)$(TargetName).pdb. This means that project main generates its local PDB file as Debug\main\main.pdb, project b as Debug\b\b.pdb and so on.
Finally, in Linker -> Debugging settings of project main the Generate Program Database File value is set to $(OutDir)$(TargetName).pdb. This means that the global PDB file for the entire executable will be generated as Debug\main.pdb.
Note that in this setup each PDB file is generated in its own, separate directory.
In this setup you will get Debugging information cannot be found or does not match error if you attempt to run the program under the debugger. And if you take a look at the Debug\main.pdb file (which will exist), you will notice that it is exactly the same as Debug\main\main.pdb file! I.e. somehow the local PDB for main managed to overwrite what was supposed to be the global PDB for the final executable. I.e. the debugger is right to complain that the PDB file is "wrong". It is indeed wrong.
Again, in the above setup the final global PDB somehow gets overwritten by local PDB of the top project. I don't know why it happens. It appears to be a bug. (Note that even though these PDB files have the same name, they are generated in different directories, i.e. they should not conflict.)
A workaround that fixes this issue is to give the local PDB of project main a different name. For example, just go to C/C++ -> Output Files for the main project and change Program Database File Name value to $(IntDir)$(TargetName)_local.pdb (or to $(IntDir)12345.pdb if you so desire). This will eliminate the conflict and solve the problem.
Enable PDB creation by:
Right click on MyProject > Properties > Debugging:
C/C++ > General > Debug Information Output = Program Database (/Zi)
Linker > Debugging > Generate Debug Info = Yes (/DEBUG)
Clean MyProject, restart Visual Studio (just to be sure), rebuild MyProject.
The output folder should then contain *.pdb files.
If you debug optimized/release code consider switching off optimization via
C++ > Optimization > Optmization = Disabled (/Od)
I faced the same problem and tried all above mentioned solutions but it couldn't help me.
Then I found a new solution randomly and it worked.
Solution is that,in case you are having many projects in a solution then you should mark any one (specific one which you have to decide) project as a "Set as Startup Project".
Right click on that specific project and click "Set as Startup Project".
It worked for me.
The pdb or Program Database file appears to be missing (basically, the path has changed and can no longer be found by the compiler). See this related post for additional information.
I had a similar problem and the reason was that I had run one of the projects of my solution in a different process and that process couldn't be killed. I didn't think much of it. So when I was building the solution in a separate environment one of the pdb files didn't match so at the end I couldn't load any of the pdb files. I just restarted my computer and that fixed it.
Good luck
Restarting Visual Studio can fix one instance of this problem.
Right click on your project in the solution browser => Clean => Build.
That is if your build generates a .pdb at all (look in your target dir)
If not, you should enable debug by the steps mentioned in other posts
Most probably there are other reasons like .pdb / .exe file mismatch, something were not built / rebuilt, but I had similar case in Visual studio 2013 -
Something to do with virtual inline function - so I suspect.
In my case debugger were jumping in a middle of another C++ function, not the one which was called. Jump was off source code by 11 source code lines, but I cannot explain why much miscalculation happened. By simple rearranging functions I've got rid of this problem.
May be needs more detailed analysis why 11 lines shift happened originally.
Haven't seen this kind of behavior in any other visual studio.
This problem has bothered me for a long time. AnT's anwser is very helpful. The main idea is Don't have any two pdb files have the same name, even they are not in the same directory.
This is my situation: I have tow projects name "FooBar" and "FooBarDll", the first one is an exe, and the second one is a dll. I set both projects Target Name to be "FooBar", so that they will generate "FooBar.exe" and "FooBar.dll" respectively.
Then I set
"General -> Intermediate Directory" to be "$(OutDir)\$(ProjectName)\"
"C/C++ -> Output Files -> Program Database File Name" to be "$(IntDir)$(TargetName).pdb"
"Linker -> Debugging -> Generate Program Database File" to be "$(OutDir)$(TargetName).pdb"
So I get these files:
Debug\FooBar.exe
Debug\FooBar.pdb //C++ pdb
Debug\FooBar\FooBar.pdb //Linker pdb
Debug\FooBar.dll
Debug\FooBar.pdb // C++ pdb again!
Debug\FooBarDll\FooBar.pdb // Linker pdb
My solution is replacing every "TargetName" with "ProjectName", then I will get:
Debug\FooBar.exe
Debug\FooBar.pdb //C++ pdb
Debug\FooBar\FooBar.pdb //Linker pdb
Debug\FooBar.dll
Debug\FooBarDll.pdb // C++ pdb
Debug\FooBarDll\FooBarDll.pdb // Linker pdb
Then there is no conflict!
Give C/C++ pdb a suffix may be better, like: "C/C++ -> Output Files -> Program Database File Name" to be "$(IntDir)$(ProjectName)_C.pdb"
I had the same issue, and this link helped me solved the problem, by rename "symsrv.no" to "symsrv.yes" in VS IDE folder.
Curious, it happens to me that I needed to change the folder name from:
...\Custom Librarry (MyDll.dll(
to
...\Custom Librarry (MyDll.dll)
just by closing the parenthesis it worked !
I got a minidump from a server on which my native c++ app was running. I also have the exe and pdb files. I am able to open the minidump using Visual Studio 2005 Pro and it correctly loads the symbols from the pdb file.
I run the debugger (F5) and it shows me that it crashed. When I click on the stack trace to see where, it tells me that it can't find the source code "There is no source code available for the current location.".
How do I tell Visual Studio where the source code is?
My exe is an optimized release build that I build with a pdb file.
From this MSDN page:
In the Solution Property Pages, you can change the directories where the debugger looks for sources files and tell the debugger to ignore selected source files. See Debug Source Files, Common Properties, Solution Property Pages Dialog Box.
Make sure you supply VS with the sources that correspond to the binaries and PDB files.
Normally, VS should ask you where the sources are when first double-clicking a stack frame. I ran into a problem where VS would pop up the There is no source code available for the current location. dialog when clicking on some stack frames only, but display the source for others. This turned out to be because the /Zi flag was not set for some projects, causing the link back to the source files to be missing. This flag can be set in Project Propery Pages > C/C++ > General > Debug Information Format.
I have to debug multiple dlls each within their own project. There is a parent executable that loads a dll, which serves as a container for the other dlls.
My question is how can I debug the whole 'component' ie: all the dll's involved, using Visual Studio 2005 for C++.
If they're all in the same solution, set a breakpoint in the DLL project where you want to debug, right click on the EXE project, and select Debug > Start new instance.
If they're in separate solutions, open the DLL solution, right click on the project, expand the Configuration Properties node in the tree on the left, select Debugging. Set the Command property to point to the debug build of the EXE in the other project. Then set your breakpoint(s) and hit F5 to start debugging.
Arbitrarily pick one of the DLL projects as the startup project, it doesn't matter which. Right-click + Properties, Debugging. Set the 'Command' setting to the path of a test EXE that will load the DLLs. If you don't have a good one then just write one, might as well add it to the project and make it the startup project.
Pay attention to the Output window while the EXE starts. You'll see notifications for each DLL that gets loaded. As soon as one of the DLLs that's in your solution gets loaded then the debugger jumps in, looks for the .pdb file for the DLL and activates any breakpoints you'd have set in the DLL source code. You cannot debug the DLL unless the EXE loads it.
If that still doesn't enable breakpoints then use Debug + Windows + Modules and locate the DLL in the list. Right-click it and choose Symbol Load Information to find out where the debugger looked for the .pdb file. This doesn't go wrong very often since the DLL contains the path to the .pdb file. The far more typical failure mode is that the EXE simply didn't load the DLL.
I copied an existing project and renamed the folder. Now I get this error when I try to compile the application
debugging information cannot be found or does not match. No symbols loaded.
Do you want to continue debugging ?
If I click yes, it compiles and runs fine. But now I have to deal with that message. Just curious about what I change in the projects properties to get it to stop.
You probably have deactivated the debugging information for your project:
Right click on your project -> Properties
Configuration properties -> Linker -> Debugging
Switch "Generate Debug Info" from No to Yes
Rebuild your project and retry, it should now run without the message :)
The main reason is that you don't have a matching pdb and exe.
Some possible solutions:
You are compiling in release instead of debug
You need to clean/build or rebuild
You don't have your pdb files being generated in the same directory as the exe
You have a mismatching pdb, maybe the copied source is newer than today's date and something isn't building properly.
Try cleaning out all debug object files
You are attaching to a process that you started from a different location from where your build exe and pdb exist
Restart Visual Studio
This happens to me every now and then, while debugging code and making changes it seems like visual studio caches the pdb information and sometimes it gets stuck. Doing a Rebuild solution, deleting the pdb and creating a new one doesn't fix the problem.
Of course I do have the generate debug information on and all that it's needed, specially since this happens while debugging the code several times.
Visual Studio seems to be happy with the in-memory pdb and refuses to update it, regardless of time-stamps or even size changes in the pdb.
The only way to reset this is to exit Visual Studio (the IDE) and restart it again.
In some rare occurrences, the IDE might be still running in the background (process explorer shows it there) and might hold the handle to the file open. You can kill the process before restarting the IDE.
Good Luck
I just encountered this error in VS2012. It is definitely caused by a bug in Visual Studio, which reveals itself in situations when the local PDB file of the main project has the same name as the final PDB file for the entire executable (even if the two are located in different directories!)
Consider this example.
Solution consists of three projects: main, a, and b. main is the top-level project for the executable, while a and b are libraries linked into main.
In all three projects $(IntDir) variable is set to $(SolutionDir)\$(Configuration)\$(ProjectName)\. This means that project main dumps its intermediate files to Debug\main\, project a - to Debug\a\ and so on.
In C/C++ -> Output Files settings all three projects have Program Database File Name value set to $(IntDir)$(TargetName).pdb. This means that project main generates its local PDB file as Debug\main\main.pdb, project b as Debug\b\b.pdb and so on.
Finally, in Linker -> Debugging settings of project main the Generate Program Database File value is set to $(OutDir)$(TargetName).pdb. This means that the global PDB file for the entire executable will be generated as Debug\main.pdb.
Note that in this setup each PDB file is generated in its own, separate directory.
In this setup you will get Debugging information cannot be found or does not match error if you attempt to run the program under the debugger. And if you take a look at the Debug\main.pdb file (which will exist), you will notice that it is exactly the same as Debug\main\main.pdb file! I.e. somehow the local PDB for main managed to overwrite what was supposed to be the global PDB for the final executable. I.e. the debugger is right to complain that the PDB file is "wrong". It is indeed wrong.
Again, in the above setup the final global PDB somehow gets overwritten by local PDB of the top project. I don't know why it happens. It appears to be a bug. (Note that even though these PDB files have the same name, they are generated in different directories, i.e. they should not conflict.)
A workaround that fixes this issue is to give the local PDB of project main a different name. For example, just go to C/C++ -> Output Files for the main project and change Program Database File Name value to $(IntDir)$(TargetName)_local.pdb (or to $(IntDir)12345.pdb if you so desire). This will eliminate the conflict and solve the problem.
Enable PDB creation by:
Right click on MyProject > Properties > Debugging:
C/C++ > General > Debug Information Output = Program Database (/Zi)
Linker > Debugging > Generate Debug Info = Yes (/DEBUG)
Clean MyProject, restart Visual Studio (just to be sure), rebuild MyProject.
The output folder should then contain *.pdb files.
If you debug optimized/release code consider switching off optimization via
C++ > Optimization > Optmization = Disabled (/Od)
I faced the same problem and tried all above mentioned solutions but it couldn't help me.
Then I found a new solution randomly and it worked.
Solution is that,in case you are having many projects in a solution then you should mark any one (specific one which you have to decide) project as a "Set as Startup Project".
Right click on that specific project and click "Set as Startup Project".
It worked for me.
The pdb or Program Database file appears to be missing (basically, the path has changed and can no longer be found by the compiler). See this related post for additional information.
I had a similar problem and the reason was that I had run one of the projects of my solution in a different process and that process couldn't be killed. I didn't think much of it. So when I was building the solution in a separate environment one of the pdb files didn't match so at the end I couldn't load any of the pdb files. I just restarted my computer and that fixed it.
Good luck
Restarting Visual Studio can fix one instance of this problem.
Right click on your project in the solution browser => Clean => Build.
That is if your build generates a .pdb at all (look in your target dir)
If not, you should enable debug by the steps mentioned in other posts
Most probably there are other reasons like .pdb / .exe file mismatch, something were not built / rebuilt, but I had similar case in Visual studio 2013 -
Something to do with virtual inline function - so I suspect.
In my case debugger were jumping in a middle of another C++ function, not the one which was called. Jump was off source code by 11 source code lines, but I cannot explain why much miscalculation happened. By simple rearranging functions I've got rid of this problem.
May be needs more detailed analysis why 11 lines shift happened originally.
Haven't seen this kind of behavior in any other visual studio.
This problem has bothered me for a long time. AnT's anwser is very helpful. The main idea is Don't have any two pdb files have the same name, even they are not in the same directory.
This is my situation: I have tow projects name "FooBar" and "FooBarDll", the first one is an exe, and the second one is a dll. I set both projects Target Name to be "FooBar", so that they will generate "FooBar.exe" and "FooBar.dll" respectively.
Then I set
"General -> Intermediate Directory" to be "$(OutDir)\$(ProjectName)\"
"C/C++ -> Output Files -> Program Database File Name" to be "$(IntDir)$(TargetName).pdb"
"Linker -> Debugging -> Generate Program Database File" to be "$(OutDir)$(TargetName).pdb"
So I get these files:
Debug\FooBar.exe
Debug\FooBar.pdb //C++ pdb
Debug\FooBar\FooBar.pdb //Linker pdb
Debug\FooBar.dll
Debug\FooBar.pdb // C++ pdb again!
Debug\FooBarDll\FooBar.pdb // Linker pdb
My solution is replacing every "TargetName" with "ProjectName", then I will get:
Debug\FooBar.exe
Debug\FooBar.pdb //C++ pdb
Debug\FooBar\FooBar.pdb //Linker pdb
Debug\FooBar.dll
Debug\FooBarDll.pdb // C++ pdb
Debug\FooBarDll\FooBarDll.pdb // Linker pdb
Then there is no conflict!
Give C/C++ pdb a suffix may be better, like: "C/C++ -> Output Files -> Program Database File Name" to be "$(IntDir)$(ProjectName)_C.pdb"
I had the same issue, and this link helped me solved the problem, by rename "symsrv.no" to "symsrv.yes" in VS IDE folder.
Curious, it happens to me that I needed to change the folder name from:
...\Custom Librarry (MyDll.dll(
to
...\Custom Librarry (MyDll.dll)
just by closing the parenthesis it worked !