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 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.
Hi I'm new to programming. So in Visual Studio, there is an option of running in debug mode. I only have a general idea that this mode will create some pdb files, present errors in the output and help to debug your program, but I am not sure that except for those error information, how can those pdb files be used? Or a more general question, except for using the error information the output gives, are there some other efficient ways to debug?
You can set breakpoints at certain line of code you want to inspect during debugging and check the values of variables and such. You can step through the code to see how they are executed and in which order. Just a very quick information. Try out yourself.
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
Are there any VC++ settings I should know about to generate better PDB files that contain more information?
I have a crash dump analysis system in place based on the project crashrpt.
Also, my production build server has the source code installed on the D:\, but my development machine has the source code on the C:\. I entered the source path in the VC++ settings, but when looking through the call stack of a crash, it doesn't automatically jump to my source code. I believe if I had my dev machine's source code on the D:\ it would work.
"Are there any VC++ settings I should know about"
Make sure you turn off Frame pointer ommision. Larry osterman's blog has the historical details about fpo and the issues it causes with debugging.
Symbols are loaded successfully. It shows the callstack, but double clicking on an entry doesn't bring me to the source code.
What version of VS are you using? (Or are you using Windbg?) ... in VS it should defintely prompt for source the first time if it doesn't find the location. However it also keeps a list of source that was 'not found' so it doesn't ask you for it every time. Sometimes the don't look list is a pain ... to get the prompt back up you need to go to solution explorer/solution node/properties/debug properties and edit the file list in the lower pane.
Finally you might be using 'stripped symbols'. These are pdb files generated to provide debug info for walking the callstack past FPO, but with source locations stripped out (along with other data). The public symbols for windows OS components are stripped pdbs. For your own code these simply cause pain and are not worth it unless you are providing your pdbs to externals. How would you have one of these horrible stripped pdbs? You might have them if you use "binplace" with the -a command.
Good luck! A proper mini dump story is a godsend for production debugging.
If your build directly from your sourcecode management system, you should annotate your pdb files with the file origins. This allows you to automatically fetch the exact source files while debugging. (This is the same proces as used for retrieving the .Net framework sourcecode).
See http://msdn.microsoft.com/en-us/magazine/cc163563.aspx for more information. If you use subversion as your SCM you can check out the SourceServerSharp project.
You could trying using the MS-DOS subst command to assign your source code directory to the D: drive.
This is the procedure I used after some trouble similar to yours:
a) Copied to the production server all the EXE & DLL files that were built, each with its corresponding PDB to the same directory, started the system, and waited for the crash to happen.
b) Copied back all the EXE, DLL & PDB files to the development machine (to a temporary folder) along with the minidump (in the same folder). Used Visual Studio to load the minidump from that folder.
Since VS found the source files where they were originally compiled, it was always able to identify them and load them correctly. As with you, in the production machine the drive used was not C:, but in the development machine it was.
Two more tips:
One thing I did often was to copy an EXE/DLL rebuilt and forget to copy the new PDB. This ruined the debug cycle, VS would not be able to show me the call stack.
Sometimes, I got a call stack that didn't make sense in VS. After some headache, I discovered that windbg would always show me the correct stack, but VS often wouldn't. Don't know why.
In case anyone is interested, a co-worker replied to this question to me via email:
Artem wrote:
There is a flag to MiniDumpWriteDump()
that can do better crash dumps that
will allow seeing full program state,
with all global variables, etc. As for
call stacks, I doubt they can be
better because of optimizations...
unless you turn (maybe some)
optimizations off.
Also, I think disabling inline
functions and whole program
optimization will help quite a lot.
In fact, there are many dump types,
maybe you could choose one small
enough but still having more info
http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx
Those types won't help with call stack
though, they only affect the amount of
variables you'll be able to see.
I noticed some of those dump types
aren't supported in dbghelp.dll
version 5.1 that we use. We could
update it to the newest, 6.9 version
though, I've just checked the EULA for
MS Debugging Tools -- the newest
dbghelp.dll is still ok to
redistribute.
Is Visual Studio prompting you for the path to the source file? If it isn't then it doesn't think it has symbols for the callstack. Setting the source path should work without having to map the exact original location.
You can tell if symbols are loaded by looking at the 'modules' window in Visual Studio.
Assuming you are building a PDB then I don't think there are any options that control the amount of information in the PDB directly. You can change the type of optimizations performed by the compiler to improve debuggabilty, but this will cost performance -- as your co-worker points out, disabling inline will help make things more obvious in the crash file, but will cost at runtime.
Depending on the nature of your application I would recommend working with full dump files if you can, they are bigger, but give you all the information about the process ... and how often does it crash anyway :)
Is Visual Studio prompting you for the
path to the source file?
No.
If it isn't then it doesn't think it has symbols
for the callstack. Setting the source
path should work without having to map
the exact original location.
Symbols are loaded successfully. It shows the callstack, but double clicking on an entry doesn't bring me to the source code. I can of course search in files for the line in question, but this is hard work :)