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.
Related
We are having some issue in customer site. So we generated the dump in their site.
Now to find out the issue we are loading the dump file from visual studio.
I had given the correct symbol path also.
Error which i am getting
A matching symbol file was not found in this folder
Error msg (Eventhough pdb is present is same loaction )
Even though the pdb is present it is saying "A matching symbol file was not found in this folder "
Should the time stamp and date should be same for dll and pdb ? ( In my case pdb and dll source code is same , but date which both are built are different )
In my visual studio in options i have disabled the source code must be same check box also.
My source code is in c++.
Is the time stamp mismatch is the issue ?
Is so any workaround is there for this ?
Or any thing which i am doing wrongly ?
I tried to debug using both Visual studio 2013 and Visual studio 2019
Thank you for your time....
Thank you.
There was a signature mismatch b/w my dll and pdb .I used Chkmatch tool to check , and i corrected the pdb using the same tool .And it worked .
Link for the tool http://www.debuginfo.com/tools/chkmatch.html
Commands :
chkmatch -c ExeFile/dll DebugInfoFile(pdb)
--> This command will tell whether your pdb and dll matches
chkmatch -m ExeFile/dll DebugInfoFile(pdb)
--> This command will correct your pdb. So this pdb can be used for debugging purpose.
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 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.
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?