Symbols in Microsoft Debugging Tools for Windows?

What is the need / use of "symbols" in the Microsoft debugger ?

I spent some time figuring out the debugger a while ago and was never able to get it to make any sense (I was trying to debug server hangs ...). Part of my problem was missing the proper "symbols".

What is it? And why do I need them? Am I not looking for text?

Are there any better links to use than How to Resolve Windows System Crashes in Minutes ?

+2


source to share


3 answers


You need characters to translate addresses into meaningful names. For example, you have places on your stack every time you call a function:

0x00003791
0x00004a42

      

Symbols allow the debugger to map these addresses to methods

0x00003791 myprog!methodnamea
0x00004a42 myprog!methodnameb

      

When you build a debug version of a program, the compiler produces symbols with the .PDB extension. It also contains string information so you can debug source code, etc.

You need to set the symbol search path correctly for the debugger to select it. In the command window, you can do



.sympath c:\symbols;c:\temp\symbols

      

so that it looks for .PDB in those directories. It will also appear in the same directory from which the executable is executed.

It might also be helpful to use Microsoft's public symbol server so that you can resolve OS binaries like NTDLL, GDI, etc., with this path at the beginning:

.sympath SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols;c:\symbols

      

First you need to create c: \ websymbols.

+6


source


In the Windows binary architecture, debugging information (function names, file and line numbers, and so on) is missing from the binary format itself. Rather, they are compiled into a PDB (Program DataBase, .pdb file extension) that the debugger uses to correlate binary instructions with the kinds of information you are likely to use while debugging.

So, to debug a server hang, you need a PDB file for both the server application itself and possibly the Windows binaries your server calls on.



As a general note, my experience with WinDbg is that it is much more difficult to learn to use compared to GDB , but that it was much more powerful once you figured out how to use it. (Contrary to the usual case with Windows / Linux tools, interesting.)

+2


source


If you only have a binary file, the only information you can usually get is the stack trace and possibly binary or IL (in .NET) instructions. The presence of symbols makes it possible to actually map this binary / IL command to the corresponding line in the source code. If you have the source code, it also lets you plug in a debugger in Visual Studio and walk through the source code.

0


source







All Articles