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)

Answer 1

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.

Answer 2

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.