Yes, more info is really needed. On the surface it looks like you have a page that is manipulating a table and it encountered an error that was not handled, so IIS reset the worker process (handled your exception for you). Hwo do you troubleshoot? There are a number of ways, but the one I am most familiar with and use most frequently is to attach the debugger (cdb or windbg), set a BP on the exception that is occuring and then wait. You can then use the debugger to determine the page that is failing and anything more you want. To learn more about this process I'd recommend a book by John Robbins:
If you're on a Windows OS, a great resource for this would be "Debugging Applications for Microsoft .NET and Microsoft Windows" by John Robbins:
(or even the older edition: "Debugging Applications")
The book has has a chapter on how a debugger works that includes code for a couple of simple (but working) debuggers.
Since I'm not familiar with details of Unix/Linux debugging, this stuff may not apply at all to other OS's. But I'd guess that as an introduction to a very complex subject the concepts - if not the details and APIs - should 'port' to most any OS.
A Symbol Server is simply a file share that contains the debug information (.pdb files) and executables and DLL's in a specific folder structure so a debugger can easily and quickly find the executable/DLL and debug information.
It is perfectly explained in the Debugging Windows book of John Robbins (see http://www.amazon.com/Debugging-Applications-Microsoft-Windows-Pro-Developer/dp/0735615365)
This book is honestly the best I've read about debugging, especially when you are beyond the normal debugging situation. It contains many tricks and is fun to read with all the "true story". If you are working with a big amount of code that you haven't written yourself, especially if it's crappy, this book is a must!
alt text http://ecx.images-amazon.com/images/I/51RQ146x9VL._SS500_.jpg
If you're looking to be more generic about the paths embedded in a pdb file, you could first use the MS-DOS subst command to map a particular folder to a drive letter.
subst N: <MyRealPath>
Then open your project relative to the N: drive and rebuild it. Your PDB files will reference the source files on N:. Now it doesn't matter where you place that particular set of source files, so long as you subsequently call the root directory "N:" like you did when you built it.
This practice is recommended by John Robbins in his excellent book, Debugging Applications for Microsoft .NET and Microsoft Windows.
I think this really depends on what you are trying to debug. Two possible things to look at are the Reflection and StackTrace classes. That said when your program is compiled, the compiler and runtime do not guarantee that that names need to be consistent with the original program.
This is especially the case with debug vs. release builds. The point of the .PDB files (symbols) in the debug version are to include more information about the original program. For native C/C++ applications it is strongly recommended that you generate symbols for every build (debug+release) of your application to help with debugging. In .NET this is less of an issue since there are features like Reflection. IIRC John Robbins recommends that you always generate symbols for .NET projects too.
You might also find Mike Stall's blog useful and the managed debugger samples.
There's an excellent book written by John Robbins which tackles many difficult debugging questions. The book is called Debugging Applications for Microsoft .NET and Microsoft Windows. Despite the title, the book contains a host of information about debugging native C++ applications.
In this book, there is a lengthy section all about how to get the call stack for exceptions that are thrown. If I remember correctly, some of his advice involves using structured exception handling (SEH) instead of (or in addition to) C++ exceptions. I really cannot recommend the book highly enough.