I am interested in which symbol file is used when we analyze dump file using Windbg or Visual Studio. Suppose my application is using a utility library, and the utility library has related private symbol file. When there is crash dump in my application, I need the symbol of the utility library to analyze the full call stack. But sometimes the build/runtime/debug environments are installed with different versions of the utility library — which are (for sure) of different versions of utility library symbols.
Suppose we have a version (e.g. version A) of utility library (and related symbol) for build (link) my application, using another version (e.g. version B) of utility library (and related symbol) in runtime when there is crash, and using another different version (e.g. version C) of utility library (and related symbol) in Windbg when I analyze the crash dump.
My question is, when the crash is genarated in runtime, version B symbol is used to generate the crash dump (to fill the dump with symbol information)? But when using a different version of symbol C in Windbg debugging environment, there will be symbol mis-match issue? And which version of library is used to build does not matter? Are my understandings all correct?
thanks in advance,
George
Best Answer
It sounds like you want to use a Symbol Server so that WinDBG or VS can pull down symbols that correspond to the build of the library you're debugging. If it's a third party component and you have private symbols you can either put them symbols in your own server or see if the third party has a public symbol server.
Windbg won't load symbols if they don't match the dll you're debugging, you can use !sym noisy to see more about the symbol loading process. If you choose not to use a symbol server you can manage all the pdb's by hand and load them manually into windbg (use lm v to get detailed information about a module loaded in your process)