I am currently able to set up and compile a a visual studio project using cmake however I am unable to breakpoint in source at all. Originally I was warned by VS when I tried to run with the debugger that debug symbols could not be found. To fix this I simply went to the projects properties and selected Linker->Debugging and set "Generate Debug Info" to yes. Now it generates the necessary pdb file, however if I put a break point in the source code it will hollow out and tell me that no symbols where loaded for the document.
So my question is why is it not matching the source to the pdb file and what can I do to correct this?
Thanks.
Here's a git repo with a simple example: https://github.com/Samurai336/CmakeSimple
Ok I figured out what the problem was, thanks to digging deeper into user Fraser's comment, where he asked if I set my debug information format to "/Zi or /ZI". Well it was set to Zi so to put the science back in computer science I gave /ZI a shot. The compiler yelled at me that " '/ZI' and '/02' are incompatible." So today I looked into what the /02 flag is and realized that it was max speed optimization flag and had a hunch that was why it was having issues debugging. Sure enough when I changed the flag to '/Od'(disabled) everything break pointed accordingly.
This leaves me with a one major question though: How do I set these flags for the VS compiler from cmake?
I'll probably pose this as a separate question if I don't find it already answered.
Thanks for the help everyone.
Related
I am trying to debug a program written in C++ in Visual Studio (using Debug x64 configuration) and have encountered the issue I mentioned in the title. Now I've seen this question:
How do I remedy "The breakpoint will not currently be hit. No symbols have been loaded for this document." warning?
and tried the answers there, however they do not seem to work for me. This is the function I'm trying to debug:
which, as you can see, is part of _tools_string.cpp. This file belongs to a project called common-files-lib-vs:
And as I start debugging and select Debug->Windows->Modules, I can see that the symbols for this project have in fact been loaded:
Breakpoints do not work in any other file belonging to this project, however they do work properly in files found elsewhere.
As I've mentioned before, I haven't found a solution that would work for me, besides the question I've linked was asked in regard to C# (I'm not sure it makes that big of a difference in this case, but still). Has anyone perhaps had this problem before and managed to come up with a solution?
When debugging a C++ Project using Visual Studio 2010, it cannot find the source for crt. When I am trying to go inside one such module, it displays "No Source Available". It also does not provide an option to Browse so that I can help it locate the source location.
Under the Option Solution->Common Properties->Debug Source Files, the proper location to the crt source is updated.
In lack of source level debugging of crt I have to read through the disassemble which is getting difficult.
Can anyone help me figure out what might be going wrong?
Please Note ** I am using an external build system via Visual Studio to build my C++ Project.
With the guidance of Hans here how I narrowed down to the problem.
While the breakpoint was still active, I listed all the Symbol Load information. I realized that msvcr100d.i386.pdb did not match the dll. It actually went all the way down to fetch from the microsoft public symbol store which off course had the symbols stripped off. So that was the root cause of my problem.
And here is a similar problem in social.msdn
You can see the cause of the problem by using Debug + Windows + Modules while you have a break active. Right-click msvcr100d.dll and select "Symbol Load Information" to get info about the .pdb that the debugger uses.
For some reason the Microsoft Symbol Server supplies one that has the source info stripped. It is probably intentional, something to do with service and security patches of the DLL getting out of sync with the source code in vc/crt/scr. You can get a real answer instead of a guess by posting to connect.microsoft.com
A workaround of sorts is to compile your code with /MTd instead of /MDd, if that's possible at all. Project + Properties, C/C++, Code Generation, Runtime Library setting. The debugger will then use the .pdb file in vc/lib. Do keep your eyes on the ball, debug your code instead of the CRT's.
You can find the sources for the CRT in your installation folder, subfolder VC\CRT\SRC.
If they're not there, did you install them when installing VS2010? (not sure whether you can really choose this).
I am having some trouble debugging a visual studio 2008 C++ project. When I start running it in debug, the breakpoints are disabled with the message
The Breakpoint will not be hit. No Symbols have been loaded for this
document.
I have tried cleaning and rebuilding, but this doesn't make a difference.
I also tried looking in Debug->Windows->Modules. If I right click on the module I am trying to debug and press Symbol load information it brings up a list of places it has tried to load the symbols from. The first in the list is correct and the file exists, but next to it is this error
C:\path\to\my\symbol\Debug\MyProject.pdb: Unknown symbol handler for
error
Does anyone know what causes this or how to fix it?
First of all, it is possible that some of your modules won't show in the module window, because some of them may be loaded dynamically (only as needed).
You might want to check in your project properties under Linker > Debugging > Generate Program Database File and Generate Debug Info. Be sure these two are set properly.
Also, check if C/C++ > General > Debug Information Format is set to Program Database for Edit And Continue (/ZI) or something similar.
I know you mentioned that your symbol file exists, but checking what I just mentioned will ensure you have the right version of your symbol in the right place.
Finally, check if all your project and files in your solution are set to compile as Debug and not Release or something else, because no symbols will be generated (hence none will be loaded) for this project / file.
Hope this helps a bit.
In my case, the problem was solved by checking "Use Managed Compatibility Mode" in Tools / Options / Debugging / General.
In case anyone has this problem when using 'Attach to process', the answer to this question solved it for me:
Visual Studio is not loading modules when attaching to process
Specifically, switching to 'Native code' in the 'Attach to' options instead of 'Auto'.
I have managed to solve this by copying my source sideways and checking out a completely clean copy. I assume it was some setting stored in the projects .suo file.
Go to the "Properties" for the website that would use that dll for debugging and then select "Native Code" in the "Debuggers" section below:
There could be a problem with the mspdbsrv.exe process. Try killing it and start debugger again.
For me the fix was in restarting the Visual Studio :) As simple as that. Nothing else helped - tried to Clean (even deleted all files in the Debug folder), checked settings, even killed the mspdbsrv.exe process, but only VS restart did the trick.
In the Modules window you can right click and add your Debug output folder to folders where your system looks for symbol files. Also, the thing that worked for me was deleting all the output files manually, Clean won't do it every time and that's why even though the .pdb file is generated, it doesn't correspond to your output files, thus not loading symbols from it.
Delete all files in the bin and obj folders. Then build the solution again. If your problem was like mine, it seemed like VS was loading an older version of a specific unknown file that rebuilding the solution/project would not replace. Make sure to make a copy of your solution/project before trying this. Good Luck!
Make a copy of your "Debug" folder within your project's folder, then delete every file in the original "Debug" folder. As additional measure if you had your visual studio already running with your project loaded, close it after deleting Debug's contain and reopen it before re-build the whole project, theoretically this action will create new copy of symbol files and the rest needed to debug your code.
I found out this problem occurred to me when I moved my files to other computer and try to compile and debug my code from there, although all folder and drive names were the same, some how the IDE was unable to use the previously created symbol files.
Hope this work around works for some one else !.
VS2015 C++
I ran into the same problem after cancelling the loading of symbols whilst attempting to debug my application in VS2015. After this, VS2015 refused to load the symbols for the project I was interested in (multiple sub projects in a solution with C# calling C++ DLLs). Solutions above did not work for me, but this did.
For Visual Studio 2015 (C++):
Right click on your project that your break point is in and select
properties Expand C/C++
Select General under C/C++
Change the Debug Information Format to any other option
Click Apply
Change the Debug Information Format back to its default "Program
Database for Edit And Continue (/ZI) (or whatever you prefer)
Click Apply
Now rebuild your project
Hope this helps.
Alan M
1) Right click on the project you want to debug.
2) Select [Properties]
3) Select the [Build] tab
4) Make sure [Define DEBUG constant] and [Define TRACE constant] are checked
5) Click the [Advanced] button at the bottom of the Build tabpage
Make sure that [Debug Info:] is set to [full]
6) Click [OK]
7) Rebuild the project
In my case, "use library dependency inputs" in "linker->general"should be set to yes, then the problem is solved.
None of the above helped me...
At the end I changed from Debug\X64 to Debug\win32, this helped, probably it's some configuration which isn't the same in both. Maybe this will help as a
workaround for someone...
Hope that could help anyone.
I'm debugging a WIA driver, and came across this similar problem.
I noticed this log :
DLL named C:\Windows\System32\WIA\wiadriverex.dll cannot be loaded (LoadLibraryEx returned 0x0000007E). Make sure the driver is installed correctly
Then I realized that it is due to DLL dependency. Then I copied required DLLs to System32, the problem is gone. Pay attention, copy to System32, or it won't work for me.
It helped in my case:
Debug -> Attach to process
Scroll down to w3wp.exe
Check "Show processes from all users
After refresh scroll again to w3wp.exe
Select new one with type x64, Managed (Native compilation)
Try disabling /GL option if it has been enabled in C/C++ / General / Optimization / Whole program optimization.
Initially, I had no issue with debugging my program but after tweaking here and there the issue that OP says began to arise.
The module and its symbols were loaded and nothing in this guide seemed to correspond to my problem. Turning /Zi to /Zl also didn't help.
I'm not sure why, but, it's sort of a compiler behavior I haven't been experienced before. FYI, /GL option is not a default in the C++ projects in VS2017.
In my case, the error was due to the fact that part of the code was connected as an external library. In order for debug process to work also when going into the code of the external library, it was necessary to add not only its headers, but also the implementation files - folder Source Files of Solution Explorer.
In my case it was debugger type.
I used remote windows debugger, changing it to local solved an issue.
Debugger options:
I'm having a weird problem with Visual Studio. Whenever I change my code and build, even though I get the notification that the built was successful (and if any, it also shows errors in code and doesn't build) the executable is actually the previous build. This is getting really annoying and frustrating.
If I put a breakpoint on the new lines, the breakpoint gets disabled and it says
The breakpoint will not currently be hit. No executable code is
associated with this line. Possible causes include: preprocessor
directive or compiler/linker optimization
If I put a breakpoint on old lines of code, it stops processing but shows me this message
The source is different from when the module was built. Would you like
the debugger to use it anyway?
I never had this problem before and the source code in on my laptop's hard drive. It saves right away. The only way to get around this to Clean the entire solution manually every time, instead of basically pressing F5.
Thanks everyone for their suggestions. My mistake was that I defined the classes inside .cpp files, this somehow caused the linker to do weird (caching probably) stuff and link the old objects. I renamed the file to .h and everything's working as expected.
Perhaps your code is not built, or is built in a way you don't expect.
You might check by inserting a #error foobar preprocessor directive somewhere. If no error shows when building, you know you are in trouble!
But I never used Visual Studio (I'm only using Linux) so I cannot help more.
It might be that you have set main project some other project and building that.
make your project that you want to work on as "Main Project " by set main project available in menu bar.
I think you are using source files from another project (ex: if you are using a dll say, my.dll (which was built using some source files say, mycpp.cpp ); in your current project).
When you debugged into the file (mycpp.cpp), maybe you modified it.
Hence you need to rebuild the dll (my.dll) first in the project in which you created my.dll .
Or
Maybe you have opened a instance of mycpp.cpp in a window & debugging in another window.
you should rebuild the dll.
If you are not using files from another project, then I cant guess the cause...but still I would recommend using rebuild rather than clean & build.
please clarify your Question a bit.
#David expecting a reply from you...
I was looking for an answer to this issue since I was also stuck with it. A colleague of mine just gave me a solution that works. Yes, it seems really stupid, but it did the trick for me.
Our solution has many projects. He told me to select the project that I wish to break into and set it as the startup project (right-click on the project name and pick "Set as startup project"). I was desperate, so I tried. To my amazement, it works.
Since I have this window opened, I thought I'd share it in case someone else is stuck with the problem.
I faced the same problem. But reason was not as yours.
Then I just restarted the visual studio and it ran as expected.
I've noticed that when generating a new C++ project using MS Visual Studio 2008, the Release build contains debugging symbols - specifically the following settings are enabled:
The C++/General/Debug Information Format is set to Program Database.
The Linker/Debugging/Generate Debug Info setting is set to Yes.
I have never noticed this on earlier releases of Visual Studio.
So, other than generating a larger EXE file, is there any downside to leaving these settings enabled?
We have turned on those settings in our commercial releases for years now with no apparent downside. The upsides are enormous,though.
We have integrated a crash dump packager that packages the dump along with some other information and emails it (with the user's consent) to a company inbox. This has helped us find problems that would have taken us forever to reproduce and find otherwise.
Although it's slightly off topic, here's a link to an excellent contribution someone made that gives you an easy way to include a crash reporter to a C++/Windows app:
http://www.codeproject.com/KB/debug/crash_report.aspx
Note: It would be wise, though, not to include the PDB file with your release. That said, you must keep the PDB file that matches your released version so that you can correctly debug the problem in the future. If a PDB file is used that wasn't built with the same code that built the exe, the stack you see when you try to debug the dmp will be wrong.
They're turned on by default because:
If you don't create them now, you can't create them later.
You need them.
Enabling debug info in Visual C++ causes a small entry to be added to the binary header, identifying the PDB for this binary. It's too small to be of any size concern, and doesn't contain any useful secrets that you might be concerned about sharing.
(The header entry is labeled RSDS: who can guess why?)
Of course, those PDBs will use more disk space on your build machine / in your backups. Deal with it. You need those PDBs when it comes time to debug something.
Well, you might deliver this debug information and someone might use it to disassemble your code. For some fearful people this alone might be a reason not to leave it this way.
Personally, I think sometimes it's helpful to have debug information available for the release version - this way it is far easier to analyse a crashdump, that will be stored by Dr. Watson in case of application crashes.
I did find some really obscure bugs this way.
Having these options on do not necessarily make your executables bigger. Debug information is stored in a separate file, with the extension PDB. Having debug information available is never a bad idea, unless you're really really short on free storage space.
Perhaps that's why they're on by default: they don't harm your executables. Release builds do use optimizations such as function inlining and generating optimized code, which makes it harder to step through, while Debug builds have these options turned off.
No downside here.
Dave
Add the /Zi switch does make a larger .exe file in addition to the PDB. However you can seperately link with /OPT:REF to keep the .exe file size to a minimum.
The .exe will be slightly larger due to a reference to the .pdb file (i.e., an extra path). That's about it.