Home > Debug Symbols > The first key for a successful debug on Windows : the Symbols

The first key for a successful debug on Windows : the Symbols

I have long pondered about the subject of my first post. Debugging subtle bugs on Windows can be easy or not, but one thing is sure: it is really a pain to understand what happen in a software (at least a native one) without the Symbols. There is lot to say about it, and you can find lots of article on the internet describing the contents and the benefits. My approach will be much more practical: a short description, and why you definitely have to create and use them.

What is a symbol file?

A symbol file has the extension “.pdb” (Program DataBase) on Windows systems. Every compiler that I know can generate it for you (Visual C++/.NET, Delphi, even VB6 IDE). Even if it can be a large file (especially with C++), they are worth being generated for each piece of dll/exe, because they are the difference between be able to fix your issues, or stand in front of a customer issue without having the first clue about what happened.

ALWAYS generate symbols for ANYTHING that can be executed. Don’t think. Do it. And keep them in a safe place (I will soon write a post about symbol servers, a handful way to manage them).

I generated once a symbol file for my dll. Do I have to recreate it each time?

Hell yes. A symbol file is closely related to its executable file. It contains a unique ID that matches your dll/exe, and changes every time you compile it. WinDbg have a few commands to bypass this check (but by doing it, you’re not sure of the behavior, I warned you), but Visual Studio cannot. Just remember that you cannot use a symbol file that has not been generated while you compiled your code.

Ok, I generate my symbol files each time I compile. What can I do with them?

Any decent debugger on Windows (Visual Studio, WinDbg, etc.) can use symbols to retrieve useful information about your live application, or from a crash dump. You will have a callstack, you will have the value of each local variable (well, most of the time). You will also have the file and the line matching each single assembler instructions if the guy who compiled the binary chose to insert them. Nice, isn’t it?

An easy way to make a debugger load the symbol is…copying it next to your binary. That’s all. Even with complex configurations of your symbol directories, every debugger that I know will always have a look right next you exe/dll.

Well, I’m not convinced yet

I wrote a very simple and dumb program in C++, whose main feature is to trigger a division by zero exception. Here is my debugger view (Visual Studio 2010) without symbols:

All you can see is a bunch of assembler code. Pretty sad. But with symbols, you have this:

Your code, a decent call stack (with function names!) and….the local variable. Convinced now?

Categories: Debug Symbols
  1. Benoit Nesme
    October 28, 2010 at 4:25 pm

    Dear BugSlasher,

    nice blog and nice first post ! Looks very promising :)

    I’d be quite happy to fin a post on how to debug an executable running remotely.
    I know it’s possible installing Remote debugging tool on the remote machine.
    However, how could I debug on a remote machine I can only access using a soft such as teamviewer.
    A proxy machine could be the solution but does this exist ?

    Any idea how to achieve that ?

    • October 30, 2010 at 3:25 pm

      Hello Benoit
      Best and easiest solution is always to debug on the target computer (because of potential trouble finding the right mscordacwks, see this post). As the debugging tools for windows does need any installation process, you can just pick up the zip provided in this post (be careful to choose the right version, here is another post to help you).
      Of course it is WinDbg, and maybe you want to use Visual Studio, even it is a far less powerfull debugger :). In that case you have to install the whole Visual Studio package I guess.
      For remoting debugging, you can use the pair cdb.exe/windbg.exe, as explained in this post. I never did this through a distant network, but I think the TCP server mode should do the trick if you open the address and port on the distant computer.
      I almost never use the visual studio remote debugging feature, but I think this article and this article on the msdn should help you to setup it.
      Let me know if it works !

  2. November 7, 2010 at 10:44 pm

    Hello Benoit
    I think I found THE solution to your issue, tks to John Robbins : http://wintellect.com/CS/blogs/jrobbins/archive/2010/06/15/vs-remote-debugging-across-workgroups-or-domains.aspx

  3. December 17, 2011 at 6:40 am

    Too many compmelints too little space, thanks!

  1. October 7, 2010 at 10:56 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: