I've got a C++ project in MSVS 2013, which causes problems when debugging: whenever I run a debug session, a message box shows up, saying "No Debug Information -- Debugging information for 'xy.exe' cannot be found or does not match. Cannot find the PDB file. Do you want to continue debugging?" This is a common issue and the question was asked several times, however, none of the answers I found so far apply to my case.
Project Properties -> Configuration Properties -> C/C++ ->
Optimization -> Optimization is disabled
Project Properties -> Configuration Properties -> Linker -> Debugging -> Generate Debug Info is turned on
Path and filename are correct; Project Properties -> Configuration Properties -> Linker -> Debugging -> Generate Program Database File is "$(OutDir)$(TargetName).pdb" (Output File is "$(OutDir)$(TargetName)$(TargetExt)", so there's no misconfiguration here either)
I tried deleting the file manually, restarting Visual Studio, cleaning and rebuilding. From the file timestamp I see it is indeed the PDB file just created, and both exe and pdb are built to the very same folder and are named correctly.
Someone suggested doublechecking the task manager and see if devenv.exe is still running in the background -- indeed, it was. I killed it, deleted PDB files, restarted, cleaned, rebuilt, no luck.
I switched the startup project to a different one and back, as a poster suggested [1]. No luck.
Somebody reported having this issue when the local PDB file of the main project has the same name as the final PDB file for the entire executable [2]. This is not the case here.
When I open the Modules Window [3], I see that for my exe, in the "Symbol Status" column, it says "Cannot find or open the PDB" file. When I try to right click -> Load Symbols, I see they are right there (e.g. xy.pdb for xy.exe). When I select them, a message box says "A maching symbol file was not found in this folder."
Interestingly, none of the projects in this solution work. Other projects, however, work withouth any problems. I tried to compare each and every setting in the project properties with the ones that work, but I cannot find any differences.
Any more ideas?
[1] https://stackoverflow.com/a/15378106/4508058
[2] https://stackoverflow.com/a/21640745/4508058
[3] https://stackoverflow.com/a/540599/4508058
Okay, a hint to future readers: now it is finally working. I noticed that the project shared it's intermediate directory with another project. However, just changing this, cleaning, rebuilding, even deleting the intermediate directory manually didn't help. But after some builds it finally worked, so it might have had something to do with it (?). So I don't have an absolute solution to the problem, but maybe it helps.
I sometimes still get the Linker error I mentioned in my comment above, though (LNK1209: program database 'D:\work-coding-\Projects\vrtheater\LoadingApp\bin\LoadingAppD.pdb') so there still might be something wrong...
The c++ compile also needs generate debug info /Zi. If that is also set, use windbg with !sym noisy to see where it is trying to load symbols.
Related
I am using VS2015 debugger on my C++ app. When I start the app, debugger gives the message
Loaded 'C:\MyDir\Working\x64\Debug\MyApp.exe'. Cannot find or open the PDB file
As a consequence, I cannot set breakpoints.
There is a .pdb file in the same directory as the .exe, but it doesn't match, according to VS debugger, and also according to WidDBG Symchk. Symchk does not provide the reason for the mismatch, even with /v option.
Complete rebuild does not make this problem go away. It is only occurring for debug build, and it just started today. Before today, there was no problem with mismatched pdb's, either for debug or release builds.
The VS options I am using are:
C++: Debug Information Format=Program Database (/Zi), Program Database File Name=$(IntDir)%(Filename).pdb;
Linker: Generate Debug Info=Optimize for debugging (/DEBUG), Generate Program Database File=$(OutDir)MyApp.pdb, Generate Full Program Database File=Yes.
The pdb files for the individual objects appear in the intermediate directory, and MyApp.pdb appears in the output directory, along with MyApp.exe.
Now, here's the weird part: when delete the existing MyApp.pdb and then relink, a new .pdb file appears in the output directory with a current mod time. While the linker is running, the pdb file grows to be large (~70 MB), but as the linker completes, the pdb file suddenly becomes small (~4 MB), and the mod time changes to a few hours earlier today. This is very suspicious, and probably accounts for the pdb mismatch.
The linker's final output lines are
Finished searching libraries
MyApp.vcxproj -> C:\MyDir\Working\x64\Debug\MyApp.exe
MyApp.vcxproj -> C:\MyDir\Working\x64\Debug\\MyApp.pdb (Full PDB)
How can I force VS to produce a matched and correct pdb file for the debug build?
UPDATE: The problem was that there is a pdb file MyApp.pdb created in the intermediate directory (it is the pdb file created by the compiler for MyApp.cpp). For some reason, the linker replaces the "real" pdb file with this one at the end. Since they have the same name, MyApp.pdb, Symchk doesn't show a name mismatch (although there may be a timestamp mismatch that isn't evident).
It is not obvious how the debugging info for MyApp.cpp can be included in the final MyApp.pdb.
I want to be able to dynamically load and unload DLL projects at runtime. For this to work I have to make sure that each time I rebuild my project in Visual Studio the .pbd file generated has a pseudo-random generated name as (random file-path valid string).pbd.
This is because the debugger forces me to abort debugging before rebuilding otherwise.
I first tried creating a custom pre build tool that ran a .bat file that created a system enviroment variable like this:
set TIMESTAMP=%DATE:/=-%#%TIME::=-%
set TIMESTAMP=%TIMESTAMP: =%
setx buildrandomvar %TIMESTAMP%
And that worked fine, I checked the registry. But no matter what I did I just could not reference "buildrandomvar" as a part of the .pdb file name. The result was just an empty ".pbd".
My Program Database File Name setting is: $(OutDir)$(TargetName)$(buildrandomvar).pdb
I would really appreciate any help at all with this issue because I just can't get this to work.
I found the answer and I'll just put it here in case anyone ever needs it.
In Visual Studio, right click your project, go to Properties -> Linker -> Debugging -> Generate Program Database File and enter
"$(OutDir)$(TargetName)-$([System.DateTime]::Now.ToString("HH_mm_ss_fff")).pdb"
This should generate your pdb with a timestamp in the file name which is technically pseudo-random.
I am trying to figure what the issue is with VS2010 not finding the executable i just built. When I hit F5 to execute it pops up an error saying it cannot find the executable.
Wouldn't that be under Properties->Configuration Properties->Linker->Output file?
Why doesn't VS just execute whatever that path is? I'm confused. What am I missing?
Would really appreciate somebody helping me understand how this works in VS.
Thanks.
You have to change
Configuration properties -> General -> Output Directory,
Configuration properties -> General -> Target Name
and
Configuration properties -> General -> Target Extension
OK, I got it.
PenkajM's answer helped lead me to the resolution. To add to that answer, Output Directory is mapped to $(OutDir) macro. But under Linker->General->Output File I used the $(OutDir) macro and added to that path something like $(OutDir)\..\bin\$(Configuration)\myapp.exe.
This caused the build to put create the exe in one place but when running it VS looked for the executable in another place.
The solution was to modify Output Directory under General to what I want, then under Linker->General->Output File set it to $(OutDir)\myapp.exe
I had a VC2008 project very complicated.Inorder to understand it's inner workings I tried to simplify it and now I am getting 289 errors of the following type for most of the files:
Error 5 error C2471: cannot update program database 'c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\debug\vc90.pdb' c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\mediainfo\file__analyze_buffer_minimizesize.cpp 1 CLI
Error 6 fatal error C1083: Cannot open program database file: 'c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\debug\vc90.pdb': No such file or directory c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\mediainfo\file__analyze_buffer_minimizesize.cpp 1 CLI
My system : win7/VS2008
Solution 1: Locate *.vcxproj file in your solution, open in a text editor and search for 'DebugInformationFormat' and set it to 'OldStyle'. Reload your project and build. If you have multiple projects in your solution, this change needed for all the *.vcxproj files.
< DebugInformationFormat>OldStyle< /DebugInformationFormat>
Solution 2: From Visual Studio, on every project in your solution right click and open Properties. Expand 'Configuration Properties' > 'C/C++' > 'General'. Change the 'Debug Information Format' to 'C7 compatible (/Z7)'. Then build your solution.
This worked for me. (YMMV = Your mileage may vary:)
I've seen the same behaviour when converting a VS2003.Net solution to run on later IDEs. My guess is that your solution contains multiple projects which point to the same intermediate directory. In VS2005 and later, projects that don't depend on each other can be built in parallel so that if the same working dir is used, you can get file conflicts like this.
Check this as follows. In Solution Explorer, right click on one of the failing projects and select Properties. In Configuration Properties -> General section, make sure that every project has a different 'Intermediate Directory'. Try your build again using 'Rebuild Solution' to clean everything out.
Most of the times when I get "C2471: cannot update program database" it's because the PDB file is locked for some reason. Usually in my case that turns out to be because I have the program running in some other window, which loads the PDB file in to memory.
When that's not the reason, I find doing a rebuild-all magically fixes the problem.
I've encountered the same type of error myself with no end of frustration.
I finally fixed it by applying the Microsoft hot fix found in this knowledge base article: http://archive.msdn.microsoft.com/KB946040
This worked for me.
Kill mspdbsrv.exe and reload Visual C++
MSDN
You can delete the *.obj file and rebuild the solution again, This problem might solve. Below link might be helpful for you-
https://social.msdn.microsoft.com/Forums/vstudio/en-US/0ceac3c6-62f6-4fdf-82e1-d41e1b4fcd20/vs2008-c2471-cannot-update-program-database?forum=vclanguage
I have used vtune several times in the past, usually without too much trouble. Unfortunately the gaps between each use are often so long that I forget some aspects of how to use it each time. I know that the line number and symbols information needs to be stored somehow. I thought that all that was required was to compile your exe with "Program Database" (/Zi), but I have just done a sampling and found that vtune reports there are no symbols available.
Is there anything I missed?
There are two options for debugging (check $> cl /?):
/Zi enable debugging information
/ZI enable Edit and Continue debug info
Make sure that you have .pdb and manifest file (if generated).
It's not related but maybe turn off optimizations as well.
Like Bua mentioned, you definitely need to be compiling with debugging information enabled. If the pdb files are in the same directory as the exe that you're profiling, then it should be able to find them. If not, you can also try explicitly adding the path to the pdbs in config -> options -> directories. alt text http://software.intel.com/file/21331 Add an item with your symbols directory. You might also want to add a symbol server and symbol cache, because then you'll get symbols for all of Microsoft's public binaries. The image above shows how to add a symbol server with a symbol cache at c:\websymbols. Generally, the format for a "symbol server" is a string of the form:
an example:
SRV*C:\MySymbolCache\*http://msdl.microsoft.com/download/symbol
of the form:
SRV * [CACHE] * [SYM SERVER PATH]
Hope this helps!
The problem has been solved: It turned out that it was a mistake in setting the working directory; "/Zi" appears to be all that is required after all. I don't need to switch off optimization.