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.
Related
I am working on a c++ project using Microsoft visual studio 2017. We use boost::stacktrace::stacktrace() API to generate a functions stacktrace when the application crashes.
Recently I noticed on Release build that when a PDB file is generated, its absolute path is embedded into the exe/dll file. IF the PDB file exists at that path and the application crashes, the generated stacktrace is decoded, i.e., consists of actual function names. If the PDB file is not at that path, the stacktrace is encoded, i.e., it just consists of some hexadecimal stack addresses.
Then I have found that we can remove the PDB directory path in the exe/dll file and keep only its base name, i.e., the PDB file name, using the linker option /PDBALTPATH:%_PDB%.
I used the previously mentioned linker option and made an experiment by putting the PDB file without changing its name next to the exe/dll file in the same directory, and I expected that a decoded stacktrace will be generated because the new PDB path in the exe/dll file should be interpreted as a relative path. But when the application crashes now, the generated stacktrace is encoded.
Why was not the PDB file found by boost:stacktrace::stacktrace() in the previously mentioned case?
I am receiving crash while i run the application in (say Connection.dll)
Prior to crash the following assertion comes in C:\Program Files\Microsoft Visual Studio 11.0\VC\atlmfc\include\atlcom.h on line no: 4735(see below)
ATLASSERT(pdispparams->cArgs == (UINT)info.nParams);
Now client has supplied pdb file of the Connection.dll.
But client has not provided the source code of Connection.dll.
I want to find out the root cause(function name atleast in the Connection.dll) giving the issue.
Any help regarding this will be greatly appreciated.
Thanks,
Sandip Pawar
If you can get VisualStudio to load the PDB it will show you the function names, stack and parameters so that'll give you some clues. Putting the PDB alongside the DLL may work, or you may need to add it to the symbol path. If the PDB doesn't exactly match the version of the DLL it usually refuses to load it, which is a PITA.
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.
I am compiling a DLL project with the additional option /PDBALTPATH:%_PDB% which should only emit the file name for the pdb file without path information. Looking at the DLL with a hex editor only "MyDLL.pdb" is emitted.
In code I copy the DLL and pdb from MyProject/Debug/MyDLL.pdb to MyProject/Debug/Temp/MyDLL.pdb and use LoadLibrary to load it. The problem is the debugger uses the MyProject/Debug/MyDLL.pdb file instead of the one in the Temp dir. If I delete the pdb file in the Debug dir the debugger uses the one in the Temp dir which is what I want.
What can I do to get the desired behavior without deleting the pdb in /Debug/ which causes the linker to do a full link every build.
We have gone through the points listed on MSDN WRT to this error ( except for #5 ). Three different people on different machines are getting the same problem. The PDB is created, but fails somewhere in the middle.
Details:
67 static libraries
4.27 GB of static libraries
1048575 bytes - size of PDB when linker fails
The last couple of megabytes of the PDB are null ( zero's )
Release build succeeds & produces a PDB ( we have it turn on, with no debugging info in the exe )
Release build PDB is just under 1 GB.
We have disabled virus scanners. Watched with procmon.exe and saw no suspicions interactions with the PDB when the linker failed.
Related question suggests ~1 GB limit on PDB's - anyone/way to confirm that?
UPDATE & SOLUTION:
#Barry and the chromium team have come up with the solution. Here is the patch to the Chromium build system that implements the resolution.
Details
The PDB uses a virtual filesystem internally: MSF. When the linker creates the PDB file it defaults to an ( apparently non-configurable ) 2 kB page size. Apparently & fortunately when the compiler creates its PDB it defaults the page size to 4 kB. This compiler PDB can be hoisted and used as a base for the linker PDB.
Better solution
As a Pre-Link Event on the project that is linking your exe or dll we can hoist the compiler to generate our required initial PDB:
cl -c "dummy_empty.cpp" /Zi /Fd"$(TargetDir)$(TargetName).pdb"
Original Solution
Make a C++ static library project with an empty cpp file, configure the 'Porgram Database File Name' to output something other than the default. Use some project build events ( I used 'Pre-Link Event') to copy in the previously created PDB into wherever you linker is expecting ( see Linker->Generate Program Database File ) to create its PDB. Fortunately the linker will adopt the copied in PDB and use its 4 kB page size. This will buy some time, and some space allowing up to a 2GB PDB.
There is indeed a max limit of 1GB for the pdb size.
There is some trick to extend this to 2GB (more info about that can be found Here). Basically you have to generate the initial pdb file yourself instead of the compiler.
Other things you could do is do some active hoisting on your template code as this might effect your pdb sizes also.
I put together a test program with 1000 cpp files, each cpp with one function, that instantiated 500 unique template types.
Link.exe failed when the PDB file reached: 1048575 KB.
Appears to be some sort of hard limit at 1 GB in the PDB format or in LINK.exe.
Have you tried to reduce the number of parallel builds. A setting sometwhere in the IDE. On VC9 we had a similar problem and our only solution was to reduce the number of local builds.
Could it be a memory problem as well? Are you using VC 10 SP1?