What are Microsoft's public symbol servers useful for?

Question

Hi,

Until now I've always used the ASP.NET MVC framework source for debugging ASP.NET MVC. On my laptop I just tried a different approach, namely bringing up the "Modules" window in VS while I am debugging and right-clicking System.Web.Mvc, then select "Load Symbols From" > "Microsoft Symbol Servers".

VS seemed to actually load something since the symbols file for the System.Web.Mvc assembly was reported as loaded. Also, all lines belonging to System.Web.Mvc in my call stack have gone from grey to black. However, I still get the "Source Code Not Available" error message when trying to step into code belonging to System.Web.Mvc.

So, I loaded the symbols, but still no source code. Not a big problem since I can still debug it the old way. But I am wondering what the Microsoft Symbol Servers are useful for then?

Answer 1

They make stack traces work properly for native DLLs - without symbols, your stack traces often only go as far as the nearest Windows DLL and then stop. With symbols, they continue through the Winodws DLLs. You can see the function names, but not the source code (obviously).

Debugging a native Windows program, you often get stack traces like this:

  mydll.dll
  mydll.dll
  some_windows_dll.dll
  some_windows_dll.dll
  some_other_windows_dll.dll
  some_other_windows_dll.dll
  myexe.exe
  myexe.exe

Without the symbols for the Windows DLLs, you'll find that the stack only gets this far:

  mydll.dll
  mydll.dll
  some_windows_dll.dll

and you don't get to see all the way back to the start.

Answer 2

I haven't found the symbol server to be useful for managed DLLs -- you still get managed stack traces without them. I think the main value in managed symbols is line number information, but what are you going to do with that?

I couldn't live without symbols for debugging native code, however. And the source server is very useful indeed.

Answer 3

In my experience symbol servers are useful for both managed and unmanaged debugging as they provide much needed details. Others have already covered why this is important for native code, so I'll stick to managed code.

I do a fair bit of debugging of managed code using WinDbg+Sos and I need to dig into the native part on a regular basis. Remember that to the OS a managed application is no different from an unmanaged application. Eventually a managed application is going to call into the Win32 dlls. To inspect those you need proper symbols.

E.g. if you need to find out details about a specific managed call, you really need to look at the native code. One example could be when you see Monitor.Enter in you managed stack. You can't really tell from looking at the call it self if the call was just issued or if the thread is actually waiting (*). By dumping the native call stack, you can tell if a call to WaitForMultipleObjects were issued.

(*) The state flags of the !threads command will help you here, but if you want the details a dump of the native stack is still very useful.