I've seen many folks in our ISV community use the _NT_SYMBOL_PATH environment variable to set the path for symbols loading in VS.  They often set this with symbol server included.  Due to the current architecture, the environment variable is actually consumed at a pretty low level, so the debugger UI does not have any control in switching off paths etc.  My suggestion for those using primarily VS is not to use _NT_SYMBOL_PATH, but instead to use the Tools->Options->Debugger->Symbols dialog.

This dialog affords you much tighter control over when and where you are loading symbols.  In large scale apps, my suggestion is to leave entries in the symbol list (Microsoft symbol servers, your own companies symbol shares or symbol servers), but to check the box that says "Search the above locations only when symbols are loaded manually".  Although this is a little wordy it is accurate.  With this box checked, the debugger will continue to load symbol files that are either exactly where they were built, or the matching symbol file is right next to the exe or dll.  It's then a trivial matter to go to the callstack window and load symbol files for when you need them (like kernel32.dll and ntdll.dll are on the stack).  With a trimmed down set of symbols loaded, you will also find things like setting breakpoints are considerabley faster, and Devenv's memory use is down.

In coming releases, we are going to focus on continuous improvements in this area, as symbol loading is a perf and usability concern for us.  You'll see the first changes in the Service Pack for VS2008. Any feedback you have on what you'd like to see in this area, please let me know with a comment here.

Happy bug slaying,

John