What does setting up a symbol server give me?

Question

I read through this article: Setting up a Symbol Server, which goes into details on how to set up a shared symbol server for my team.

The thing I'm wondering about is adding my own symbols into the store.

My question is this: What exactly is it that I gain from this?

Let's assume that I have the following build process:

1. I commit changes into my Subversion repository
2. A TeamCity CI tool picks up those changes and does a build + unit testing
3. The binaries are committed to a different Subversion repository (for referencing by applications I make)

If I add to the third point above, the ability to add the built files into the symbol store, what does that give me?

If I create a program, and reference the binaries committed to the repository, I get both .dll's, .pdb's and .xml's (intellisense support), so my stack traces already seem to contain everything I need.

Is this a replacement for distributing .pdb's?

Or is it just for when I need to open a .DMP file into WINDBG and analyze its stacks, where I presumably don't have the executable files at all, only the .DMP file provided by someone else? (that is, the exectuables are perhaps from an older version, and I was only given the .DMP file)

Stepup

Answer 1

Not to be obvious: the symbol server gives you symbols. So you can debug the minidumps you get back from your customer when your code crashes and burns. It is absolutely crucial to do post-mortem analysis on real problems that your customer is experiencing. Because by the time your several month old version of your code gets an opportunity to crash on your customer's machine, you've already progressed a couple of versions.

The real effort is not in setting up a symbol server, it is making sure it has the right pdb files to give you a good debugging opportunity. Controlling the build process is a crucial part of that equation.

Rooney

I think this is my answer then. For my team, and our testers, and users, a normal crash report already contains everything we need, but lately I've been looking at some high memory usage problems, using WINDBG, and if I get a dump file back from our client that is more than one intermediate-version old, I won't have the files locally. Which means that this is the area I can use the symbol server for. – Stepup

Answer 2

If you have users who may find issues with the code but do not have access to your Subversion repository, how would you get them the symbols they need? For example, if you were developing an application for the accounting department and wanted them to try out an early version of the code, one you know might traceback on them, would you require they have a Subversion enlistmant?

A symbol server is simply a single network location where the symbols are made readily available to anyone who might need them.

There is no alternative to .pdb files if you want symbol information.

Strapping

In order to get useful stacktraces in our support tools, we already distribute .pdb files with our application. Hence my question. Basically, for every .dll (that we build ourselves), we also ship the corresponding .pdb file. The stack traces we are sent through the built-in crash report function already contain file and line number information. Does this mean that in this context, there isn't really a use for this symbol server? If the program crashes on a tester machine, how would I go about fetching symbols for libraries that aren't ours, from this server? The article doesn't say. – Stepup

I would say that in the situation you describe, a symbol share would not be necessary. The big advantages of a symbol server are (1) minimizing the number of files included in the distribution/size of the distribution and (2) creating a canonical location for the symbol files (you don't have to keep track of versioning). It sounds like you're dealing with these issues in other ways. – Strapping

Answer 3

Take a look at this blog post: Source Server and Symbol Server Support in TFS 2010

It's about the Symbol Server & Source Server features specifically in TFS 2010 but you can take a lot of the information and apply it to other build and source control systems as well.

Petulancy