Geek Answers Handbook

What are Microsoft public symbol servers for?

So far, I have always used ASP.NET MVC source code to debug ASP.NET MVC. On my laptop, I just tried a different approach, namely, popping up the “Modules” window in VS while I debug and right-click System.Web.Mvc, and then select “Download Symbols from”> “Microsoft Symbol Servers”.

VS seems to have really uploaded something, since the symbol file for the System.Web.Mvc assembly was registered as uploaded. In addition, all lines belonging to System.Web.Mvc in the call stack have switched from gray to black. However, I still get the "Source Code Unavailable" error message when trying to enter code belonging to System.Web.Mvc.

So, I loaded the characters, but still do not have the source code. Not a big problem, as I can still debug it the old way. But I wonder, what are the useful Symbian Symbol servers then?

+4
source share
3 answers

They do the correct stack traces for native DLLs - without characters, your stack traces often go only to the nearest Windows DLL, and then stop. With characters, they continue through the Winodws DLL files. You can see function names, but not the source code (obviously).

Debugging your own Windows program, you often get stack traces as follows:

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 characters for a Windows DLL, you will find that the stack only gets this far:

  mydll.dll mydll.dll some_windows_dll.dll

and you won’t get to the very beginning.

+4
source

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

I am doing the honest part of debugging managed code using WinDbg + Sos, and I need to paste it into the source part regularly. Remember that for an OS, a managed application is no different from an unmanaged application. In the end, the managed application will call the Win32 DLL. To check those, you need the correct characters.

eg. if you need to know the details of a particular managed call, you really need to look at your own code. For example, you can see Monitor.Enter in a managed stack. You cannot tell, looking at the call yourself, if the call was just issued or if the thread is really waiting (*). By dropping your own call stack, you can see if a WaitForMultipleObjects call has been issued.

(*) The status flags of the !threads command will help you here, but if you need details, dumping your own stack is still very useful.

+2
source

I did not find the character server useful for managed DLLs - you still get managed stack traces without them. I think the main value in managed characters is the line number, but what are you going to do about it?

I could not live without characters to debug my own code. And the source server is very useful.

+1
source

More articles:


All Articles