We have different versions of binary kept in SVN. We also keeps the pdb files corresponding to the binaries. Sometimes the developers check-in the wrong pdb files. This creates problems when an issue is reported by a client at a later point.
Is there any tools to check whether a pdb file corresponds to a binary?
Use this tool - ChkMatch. This both checks the match and also allows you to forcefully match(i.e. allow you to use wrong pdbs as long as they are not too different from the actual ones). Read through this page.
Related
I know that I should avoid it as long as possible but let's talk about urgent cases.
What's the chances that .pdb file generated from the same source code with the same libraries produces different result on every build?
Yes, I know that it will differ in GUID but I can change it manually.
Suppose that I don't have a corresponding .pdb file but I know which source code was used to compile the specified product's version.
What I know that you could find the mismatched information for different pdb files with the same source code like this blog except the GUID:
https://blogs.msdn.microsoft.com/junfeng/2007/11/05/mismatched-pdbs-why/
A thread also shared some information about the timestamp which should be match here:
Compiler PDB file and the Linker PDB file
I have a project built in VS 6.0, now I have to debug it remotely in VS 2010.
I am able to browse the source correctly, create a breakpoint and trace through lines, inspect simple types, but not complex data types. It looks as it didn't load them.
I had been able previously to debug with WinDbg, there I can read complex types, but have another (not really understand what) problem with inspection...
I have also tried to debug in VS 2013, where I can't even open PDB, it says that PDB can't match executable.
I must say that PDB is exact match of an EXE recently made, but in VS 6.0.
So I'm asking if someone have experience debugging with PDB, am I missing something? Is it possible that I'm using an old PDB which don't have type information?
Update:
When I open pdb file in Notepad, it looks that the symbols that debugger cannot find is really missing from pdb. So it happen that, from the same source file, some global variable names appear in pdb, and some not. Plus the debugger says that it cannot find symbol for complex type, even if it exists in pdb. The source code is not written in respect to new C++ standard, so it cannot be compiled in VS 2013, maybe that have effect.
The modules window (Ctrl-D, M) is a good place to understand whats going on.
Right-click the module/dll that you expect its pdb to be found for and select Symbol Load Information
It should look in the same directory as your dll to begin with and if it finds the pdb will either load it or tell you that the pdb file doesn't match the dll.
I hope it will help you solve your issue.
I'm trying to read the header of a PDB file in order to know if it matches my EXE file.
Is there a nice way to read the signature of the PDB file (maybe using dbgHelp)?
I need to obtain the fields of the header in the PDB file that indicate in which build the PDB was created.
thanks :)
I don't believe either the Debug Help API nor the Debug Interface Access SDK provide access to any information that would solve your problem. About the only way to detect the build information using either of those would be to check the path of object files included during link time.
The PDB file does contain information about the options passed on the command line for both compiling object files and linking (libs, dll's, exe's) which is probably what you are looking for. Unfortunately I know of no documented way to access it. It may be buried deep in one of the tables available in the PDB file but I was unable to find any references for accessing it.
That said, if having the information you requested is an absolute necessity and you're willing to deal with some frustration have a look at the PDB Parser by Sven Boris Schreiber. It contains a lot of useful information although it may not support newer PDB versions
you can use the Pdb Inspector tool to view GUID and other basic details of you PDBs. This tool uses the Debug Interface Access (DIA)
I ported an application from VC6 to VS 2008. I rebuilt the application in release build. The Pdb file is available in the folder where exe is located. But when I loaded the application and put break point I am getting the following message
"The breakpoint will not currently be hit.No symbols have been loaded for this document"
What would be the cause of the issue?
The debugger could not find either the application or the PDBs.
When you start the program, exactly which binaries are loaded are shown in the Output window. Make sure the right files are being loaded. When everything loads properly, the output looks something like this:
'hacks_vs10.exe': Loaded
'C:\Users\john\Documents\Visual Studio
2010\Projects\hacks_vs10\x64\Debug\hacks_vs10.exe',
Symbols loaded.
When the PDB is not found, instead of saying "Symbols loaded" it says:
Cannot find or open the PDB file
Make sure that you are first running the correct version of your application (check the running path), and then make sure that the PDB is in that directory. You can change where the PDB is generated to by tweaking "Project>Properties...>Linker>Generate Program Database File"
The debugger could not find code associated with the source location you put the breakpoint at.
There can be a number of reasons for this. The one I've most often found was a section of code that was truly not compiled in. (either because of preprocessor conditionals or dead-code removal).
I imagine there can be other reasons too (e.g. inlining, though in theory, the compiler could generate the proper mapping for all the inlines. I don't know what VS2008 does here).
Are you sure you're putting the breakpoint in a code path that is supposed to be executed ?
The PDB file you mention is probably not related to the release build,
Debug information is normally absent in the release build (though you can enable it if you have to but should anticipate surprising effects due to compiler optimizations).
Therefore, you can only set breakpoints on known DLL entry points (possible via the Module List view - it has been a while since I used Visual Studio intensively) or directly on assembly instructions.
Note that you could perhaps compile part of your application with debug symbols.
I have just solved a similar problem
I re-referenced all my DLL's
went to (Tools->Options, "Projects and Solutions", "Build and Run") and set "On Run when projects are out of date" to 'Prompt to build'
I'm not sure which of these fixed the problem, but it did!
Assume i have a custom service written in VC++ 6.0 and i have shipped it as part of a particular release. Unfortunately i did not take the pdb while building the binary.
At a later point of time my customer reported a crash and i had to get the pdb to identify the crash cause. Will a pdb that i take now be enough to identify the point of crash.
In other words i have taken binary and pdb separately however i did not make any changes to the sourcecode after taking the binary.
My understanding is that even thought he symbols wont match in terms of date and time when they were built but in terms of the content it will match.
Is my understanding correct?
You'll need to make sure you compiled with exactly the same compiler version (patches could change code generation and addresses), set of compiler/linker options, the same library versions as well as the same source to make sure the addresses match. If you're able to do that then you should be able to take a pdb generated later.
However even if it doesn't match exactly it's possible that it gets you close enough to see the bug by inspection.
Yes, that should still work without a problem (though, if memory serves, you can expect a warning about the mismatched time-stamps).
The .pdb and the binary should be able to work together perfectly if the were built from the same source code even if not at the same time. However you will not be able to load this in any debugger. For example, the Visual Studio debugger will refuse to load it because it will say they are mismatched.
You need a debugger that can accept mismatched symbols such as WinDbg. To load with mismatched symbols type the magic command symopt +0x40.