This morning I had an open discussion with a customer regarding symbols and their importance in our job (our intended also as a developer, not just as a support specialist). This customer sent in a dump for a memory leak problem he has in his web site (ASP.NET with COM components, calls to Web Services etc...).
I have to admit that a few times in the past I went through a dump without any symbols for the application (luckily I always have access to both internal and external symbol server for the OS, .NET Framework etc...), and even sometimes I've been able to find the cause of the problem anyway (sometimes it's quite obvious, it you have memory fragmentation, debug="true" in web.config, too many dynamic assemblies caused by XML/XSLT stuff etc...), but there are occasions where the call stack is completely messy and the real problem quite hard to discover.
Also more important is to have matching symbols: debugging with non-matching symbols could be much worse than debugging without symbols at all, and the analysis could take a completely wrong direction, wasting time and efforts without helping sorting out the problem... and you'll get a bad support experience when you'll call us to ask for support.
To give some background to the ones who don't have much experience on this topic, here are a couple or links which may help you:
So, take good care of your symbols! :-)
CheersCarlo
I already touched this topic a while ago , but since it's an important part of the debugging process