I need to get a stack frame of a function from any PDB (All in/out arguments and their types). I have the function name and address of a certain function from PDB, is there a way to get all of the parameters (in/out) of that function from the PDB file?
The functions are written in unmanaged code.
Regards,
Usman
You have a mess of concepts. PDB as any other file doesn't contain stack or stack frames, because it is something that is created during execution. .net exe/dll contains metadata for classes so you can peek at methods signature. You can get stack frames in your code (google class StackFrame/StackFrame) but still you can't all data from the stack like parameters values.
It is not possible to get a stack frame at compile time. The stack is a run time concept.
To extract function names, address and arguments types from a dump, you can use the dia2dump program. It is available as a sample of the Debug Interface Access SDK (dia-sdk). You can find it with Visual 2008 or 2010 under C:\Program Files\Microsoft Visual Studio (your version)\DIA SDK\Samples\DIA2Dump
Related
We are often in a situation while debugging in Visual Studio where we need to analyze a call stack that may contain many different layers of C#, python (eg. python27.dll, so actually C) and other native code (Delphi). There can be multiple layers of each technology calling each other. If we look at the call stack in the Visual Studio Debugger we don't see the names of the Delphi methods. If we look at the call stack in the Borland debugger we don't see the .net stack frames.
So we thought it should be possible to create a minimal PDB or DBG file from the .map file that the Delphi build chain produces. We are ready to write a tool that reads the map file line by line and writes the content via an API to a PDB or DBG file. However we wouldn't like to write the code that writes the exact file format 'byte by byte' but rather have a high level API, preferably by writing C# code. If there is still an easier way - even better.
Having that PDB or DBG file we would then see the method names of all layers (C#, Python and Delphi) and that would make us happy. For Python, we would of course only see the 'native' stack inside the python.dll - that is exactly what we want.
Is it possible to write a dbg file from a map file? (The map file seems to contain at least the segments and the addresses of all methods).
What we already tried:
many different open Github repositories (map2dbg, tds2pdb, etc): they
all did produce output that visual studio would not read and it
doesn't look like its worth investing time (IMHO)
looking at microsoft.diasymreader: looks exactly like the API we are looking
for. So far it seems we would need to analyze the Roslyn code to find
out how to use the DiaSym writer
What is the easiest way to do that? Is there any good example we could look at?
I have .pdb file, downloaded from MS symbols server. I need to fetch list of symbols (functions, arguments, anything it has). There is a tool on CodeProject, but it only reports modules. There is DbgHelp API, but it only could be attcahed to running process. How can I read .pdb file offline?
Good News for anyone still looking,
The information you seek is now open source!
https://github.com/Microsoft/microsoft-pdb
Some real interesting stuff there. Like this pdbdump.cpp file,
with its dumpPublics function or its main flow controls. Good documentation too
You can also use Visual Studio's Dia2Dump sample program to dump human-readable output from a PDB file, including its public symbols.
Be sure to build it as a 32-bit application though, or you might run into some problems with it. (See dia2dump: CoCreateInstance failed - HRESULT = 80040154)
I have been working on an application(Windows) on Visual Studio 2010 and encountered a crash. So for the same i asked for help from an expert and he asked me to submit a symbolized call stack of crash. Can anyone explain me what exactly is this symbolized call stack and how to get that from VS. The application i am building is using CEF(Chromium embedded framework). I have downloaded binaries and modifying it to my needs.
I think he is asking for a call stack with symbols available (as opposed to just call offsets like this - libcef.dll!11357796() Unknown).
Assuming you are developing with a binary distribution of CEF, go back to https://cefbuilds.com/ and find the distribution you used and the exact build number. At the end of the row you will see an additional link for Debug or Release Symbols. Download these and unzip them if zipped.
Now go back to your Visual Studio project, run until you hit your crash. Double click one of the unresolved symbols like "libcef.dll!11357796() Unknown". You will get a dialog asking you to locate the debug symbol file. Navigate to where you extracted the pdb files in the previous step, and it should find the symbols. It will then try to load the source file, which you don't have unless you downloaded CEF and Chromium sources, but you don't need that for a symbolic stack track. Just cancel and in your call stack you should now see symbols for all of libcef. Copy and paste and pass on to the person helping you.
It's one that has function names (and ideally filenames and line numbers) rather than plain hex addresses.
If you have debug symbols for your build, the call stack you get in the Visual Studio debugger's Call Stack window should be symbolized.
I built test.exe which will crash and generate .dmp file using MinidumpWriteDump, and parser.exe is used to read and print information from that dmp file.
In parser.exe I use StackWalk64 to get all stack traces of all threads in that dmp file.
But now I found that I can only get less stacks than that visual studio did.
I've tried all solutions I could find in google、stackoverflow、codeproject, nothing changed.
The following is what parser.exe do:
SymInitialize
MiniDumpReadDumpStream to read all information
SymLoadModuleEx & SymFindFileInPath to load pdb/exe/dll specified in .dmp file
Initialize STACKFRAME64 and call StackWalk64 in loop.
I want to know how to get the same count of stack as visual studio.
I could paste more code here if needed.
Any help will be appreciated.
StackWalk64 isn't robust enough to follow the full stack trace, especially through frames that have been optimized. (For example, see this stackoverflow question here).
The best approach is to actually use the debug engine supplied with WinDbg. Here are a couple of blog posts that show how to use the debug engine API:
Getting the Stack from a .DMP File (Automating Crash Dump Analysis
Part 2)
MiniDumps and "Bad" Stacks
I have heard using PDB files can help diagnose where a crash occurred.
My basic understanding is that you give Visual studio the source file, the pdb file and the crash information (from Dr Watson?)
Can someone please explain how it all works / what is involved?
(Thank you!)
PDB files map an assembly's MSIL to the original source lines. This means that if you put the PDB that was compiled with the assembly in the same directory as the assembly, your exception stack traces will have the names and lines of the positions in the original source files. Without the PDB file, you will only see the name of the class and method for each level of the stack trace.
PDB files are generated when you build your project. They contain information relating to the built binaries which Visual Studio can interpret.
When a program crashes and it generates a crash report, Visual Studio is able to take that report and link it back to the source code via the PDB file for the application. PDB files must be built from the same binary that generated the crash report!
There are some issues that we have encountered over time.
The machine that is debugging the crash report needs to have the source on the same path as the machine that built the binary.
Release builds often optimize to the extent where you cannot view the state of object member variables
If anyone knows how to defeat the former, I would be grateful for some input.
You should look into setting up a symbol server and indexing the PDB files to your source code control system. I just recently went through this process for our product and it works very well. You don't have to be concerned about making PDB files available with the binaries, nor how to get the appropriate source code when debugging dump files.
John Robbins' book: http://www.amazon.com/Debugging-Microsoft-NET-2-0-Applications/dp/0735622027/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1222366012&sr=8-1
Look here for some sample code for generating minidumps (which don't have to be restricted to post-crash analysis -- you can generate them at any point in your code without crashing): http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx