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.