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
Related
I have no prior experience with .dll or .lib files and I need to see the code of a function in these files. I don't know which one to look at, searching around in stackoverflow led me to dumpbin, and I can use dumpbin /EXPORTS to see the headers and the functions are there. But how can I see the actual code? Can I do it just via the console or do I have to download a separate program?
P.S: I use Visual Studio and these are C++ functions.
Any help would be appreciated.
Seeing the source code from a compiled file such as a .lib or .dll is nearly impossible since it is basically a compiled file.
By compilated the source code you will lose some information as comments and most code structure. So your library file don't have those informations anymore. However a few options are still possible.
Obvious first, if your library come from an open-source project you may find the source code by asking our dearest friend.
Depending of what you really want to do with this library, tools such as dumpbin, objdump or else can give you more information on your existing file by reading and decoding some part of the file (headers, table name).
Eventually, you can try to transform your binary into something more readable like assembly or pseudo source code using something like a disassembler or a decompiler although its result will not be the original code source.
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.
I have a question regarding the verification of executable files, compiled with visual studio, using a checksum:
If I build a project from src, I end up with an executable, call it exec1.exe, that has some metadata in it.
If I later rebuild the same exact src, I get another executable, say exec2.exe, it also has its own metadata section.
If I create a checksum for each of the two files, they differ since the metadata information between the two files is different.
Does anyone know of a way to bypass the metadata when I do a checksum of the files, so that regardless of the metadata, doing a checksum of the two files will result in the same checksum value? Or how to compile the binaries, such that as long as the src is identical, I end up with the same executables?
Thanks in advance for your input,
Regards
There is no guarantee that Visual C++ will generate the same binary image when building the same source files on successive builds. The checksum is not intended to be used in this manner, and after a bit of research it seems that this is difficult to achieve. Rather, resources such as this kb article can help in comparing files.
Checksums are usually used to find errors resulting from sending/storing data, not to compare versions/builds of an executable.
If you have the pdb file as well you can use the DIA sdk to query all the source files that were used to build the executable. Basically enumerate all the IDiaSourceFile and each IDiaSourceFile has a get_checksum method. You can generate a master checksum that is combination of all the checksums of source files that were used to make the executable. If any of the checksum of any source file has changed you can kind of assume that the executable has changed as well.
This is the same mechanism that Visual Studio uses to determine if a source file is in sync with the pdb so that it can be stepped into for debugging purposes.
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)
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.