We have source server enabled, and source indexing is implemented according Using SrcSrv (MSDN). Debugger intelligently Copies the file from the server to the local cache. This works fine on developer machine.
Using IdebugSymbols Interface, we are able to retrieve information from pdb files. We have IdebugSymbols API functions for retrieving file name, source line number, module name etc.
Reference: IDebugSymbols interface (MSDN)
My query is whether we can retrieve Source File revision number from .pdb file using some Microsoft API?
Please let me know if the problem is not understood or you require some more inputs from my side. Thanks :)
I found one more general approach using Microsoft tools called "pdbstr.exe"and "Srctool.exe". These tools can be found at this location %PROGRAMFILES%\Debugging Tools for Windows (x86)\srcsrv
(from: Source Server (MSDN))
These tools simply interacts with pdb symbols file and fetches the information. So I was interested in fetching following info and yes that answers my question.
- What are all files which are Indexed with their revision number?
Related
when building my application some PDB files are generated which are useful during debugging. Now when a user experiences a crash, I get the dump-file and using this I can analyse the problem.
Unfortunately for this the version of the PDB file needs to fit to the build the crashdump was generated from - or in other words, for every release I build I need to store the related PDB in order to have them available for later analysis.
Now I know that MS offers a product named "symbolserver" which does the complete job of storing and managing the PDB files of a build. Unfortunately this is a way too complex solution for me.
So my question: is there an easy to use and simply to handle alternative available for storing multiple versions of a PDB files in order to have them available for crash dump analysis?
Thanks!
Note that you don't need a symbol server, just a directory. See also How to set up a symbol server. With symstore, you only need to set up your symbol path once, save it in the WinDbg workspace or in Visual Studio and you're ready to go.
The alternative is to manage create a folder with version number of your build and move all PDBs there.
The debugging then goes like this (WinDbg):
lm m <yourapp>
to find out the version number
.sympath C:\path\to\symbols\<version>
Similar in Visual Studio: you need to find out the version and then change the symbol path. It's always 2 steps instead of 0.
I want to read the file properties like File Description , Product name , Copyright of a exe file. Is there any Windows API for it?
Yes. It may not be evident to find it because the Version Information chapter is hidden below Menus and other Resources. The rationale for that is that it is stored is the executable files (including DLL) as a VERSIONINFO resource that was originally intented to help install tools to know whether the version to install was more recent than an existing version.
You will find examples for using it in the linked page to the MSDN and also in SO in different places, for example here
Those values are stored in the file's version info resource. You can use GetFileVersionInfo() and VerQueryValue() to read them.
I'm working on a custom symbols/source server.
I've been able to produce pdb files which reference our sources. The most of our sources can be retrieved by Visual Studio. But sometimes, SRCSRV fails to retrieve them.
If I inspect the Visual Studio output window, I can get the following message
SRCSRV: Source server cannot retrieve the source code for file 'e:\SoftwareFactory\Projects\Product.Net Trunk\WorkingDirectory\Services\ErpWebServices\ErpServiceLegacyHost\Threading\ErpTransactionsSynchronizationContext.cs' in module 'C:\Program Files (x86)\Product\ProductCommon\ePgiStarterCS\server\Product.Erp.Services.LegacyHost.dll'. Données non valides.
The web server hosting the sources hasn't received any request for such file. So this must be an issue in the record concerning this precise file.
Is there any way to get more information by SRCSRV?
Apparently the answer is no: there is no way to obtain more information from srcsrv.dll.
The Microsoft forums moderators have told me that the message "Données non valides", "Invalid data" is possibly related to the length of the path of the file to be downloaded.
This path is combined to the temporary symbol path you've specified in the Visual Studio/WinDBG settings.
e.g. If you've specified
%APPDATA%\Symbols
as local symbol storage, and you're downloading a source file hosted by an HTTP server at the address
http://nightlybuilds.int/sources/get.svc/path/file.cs
the path
%APPDATA%\Symbols\sources\get.svc\path\file.cs
shall not be longer than 255 characters.
Other factors that can affect the behavior of SRCSRV:
The presence of characters invalid in a classic dos PATH (i.e. other than [0-9 A-Za-z\.])
The client debugger settings. (e.g. In the Native mode, the symbols for Managed code won't be downloaded. The Modules window will give you some hint about the symbols currently loaded.)
This is where SymChk can help. Using the /v switch, you get detailed output on how the symbols are resolved and what the symbol server responds with. Use this in conjunction with a tool like Fiddler which captures HTTP traffic, and you can analyze where your server is not responding with the expected protocol.
i have a Win32 compiler which, for years, has been able to create a DBG debug information file.
This has allowed debuggers, and tools like Process Explorer and Process Monitor to have access to symbol information:
i recently learned that Visual Studio's debugger no longer accepts DBG files, only undocumented Program Database (PDB) files:
Since Microsoft keeps the PDB format secret, i assume they have a tool that will allow me to convert existing debugging information to a PDB (so i don't learn the secrets of their file format).
Bonus Reading
cv2pdb: how to use to convert other debug formats to pdb?
Undocumented
Even though Microsoft has a GitHub repository for PDB, the spec remains completely undocumented. The files on their repository are incomplete. There are missing types and declarations.
And even though i've created a PDBViewer:
It doesn't get me anything - because Microsoft doesn't explain what any of it means.
The point isn't just to look at a PDB - we need to create one. And for that we need to know:
what goes in it
where
and what format
PDB is not documented, but you can collect very detailed information about the content of PDB files programmatically using the appropriate interfaces See Sample
The PDB format is now documented-through-code by Microsoft in a GitHub repository. LLVM also have a great overview, partly based on Microsoft's documentation.
That's not a complete answer because you'll still need to write the tool to do the conversion...
LLVM developers documented the PDB file format in order to make clang and lld able to read and produce PDB files. Microsoft's PDB Github repository was put up, in part, to support that work.
PDB is primarily a container for CodeView debug info, which is documented by Microsoft.
LLVM provides libraries for working with PDBs and COFF debug info, as well as command line tools for inspecting and generating them from YAML.
I am trying to understand how a debugger uses PDB file. It would probably be a small file system in itself. Could someone help me understand the structure of the PDB file?
According to this blog post, the actual file format is kept secret by MS. However, I recommend you read that post as it has a lot of useful information what a PDB file is and how it's used.
According to MSDN, its impractical:
Because the format of the .pdb file generated by the postcompiler
tools undergoes constant revision, exposing the format is impractical
A debugger would use the DIA SDK to access the data inside them, meaning you don't really need to know its structure.
As a matter of fact, the format of PDB is not documented, but you can collect very detailed information about the content of PDB files programmatically using the appropriate interfaces See Sample