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.
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 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.
When I open a dump file in WinDbg, it looks for pdb files in c:\code\appV1 folder
When I open the exe file directly in WinDbg, it looks for the pdb files in c:\code\appV2 folder.
This is driving me crazy because in both cases, windbg is debugging the same exe which is at c:\MyApp\app.exe
The c:code\appV1 make sense to search in, this is path where pdb files were generated by the exe but why does it search in c:\code\appV2 which has no connection whatsoever with the dump file or the exe?
I did extensive digging into this, created a demo project and simulated crash and tried various combinations. The answer is that dump file seems to have an overriding effect on the executable when it comes to default search paths (pdb).
Here is how you can reproduce this scenario:
Create project called App1 at say c:\code\App1 and build it.
Copy the above project and rename the main folder as App1Clone and build it, say in c:\code\App1Clone
Now first copy App1 to say c:\test folder and run it. It will crash and create dump file.
Now copy the App1 from App1Clone folder to c:\test folder and run it. It will crash and create dump file.
Now both dump files are linked to c:\test\app1.exe but if the wrong app1.exe was present (=search paths didn't match) it will apparently pick the paths supposedly stored in the dump file. I don't know if dump files even store this path but this appears to be the case based on my experimentation.
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.
When debugging a c++ solution in Visual Studio 2010, It says "No symbols have been loaded for this document." And when I check in debug / modules / <dll I cant debug>.dll / symbol load information It is looking for a pdb with the wrong name.
So, where can I set the name of the symbol it is looking for? I looked all through the command line options, and I can't find such a name anywhere.
I've tried to do a rebuild, a clean + build, but neither helped.
There are two places in which .pdb information is collected
1) C++/Output Files/Program Database Filename
2) Linker/Debugging/Generate Program Database file
By default, 2 is set but 1 is normally set to v100.pdb (for VS2010). If both these files are set to point to the same file, then you should get the symbolic information.
Try searching all PDBs (and .idb) and manually delete them.
The reason some include path is set to that library's directory that contains your PDBs, its .pdb file seems to be used by the VS debugger.
The solution is to delete these .pdb files or to rebuild all libraries.