Post to Twitter |
Comments (2) |
Views (2577) |
Today I learned that Citrix posts its XenApp build debug symbols to a publically accessible symbols server. Cool! This is mostly to make life easy for the Citrix support folks, but what ever the reason, this means that the symbols are in a place that you can see them!
If you are familiar with WinDBG or Debugging Tools for Windows, then you know that the Microsoft Symbol server is a welcomed item in understanding the state of any machine you are inspecting. Microsoft posts all the symbols for every component of every released version of Windows to msdl.microsoft.com/download/symbols. Set up the _NT_SYMBOL_PATH environment variable and the debugger does the rest to fetch Windows symbols from the internet. Yeah, old news.
I recently learned that Citrix also posts the XenApp symbols! And to this I say, down right neighborly of us!
Here's the link that says how to set it up, CTX118622.
What are symbols?
When building a program, the compiler does its thing and then the linker does its thing to actually create the executable content. When putting the program together, one of the things that the linker does is produce a table of program symbols and their location in memory (symbols). Programmers use these to figure out what's going on where they can then see nice "strings" rather than hex numbers. I say programmers, but it is really the debugger that does the work.
There are two choices in symbols, the "FULL" and the "STRIPPED". Simply put, the "full" ones are better, much like source code access. The stripped ones though are still very helpful and it is these that are on the Microsoft download server ... and the Citrix download page.
Neat thing of today, I've been writing code at Citrix for a long time and never known that the symbols were available to the outside. NEATO. This sure beats debugging stack traces with only hex locations of functions.
If you're not debugging systems on a regular basis, you may still find this useful for analyzing crash dumps. One of the first things you do after a failure is windbg -z memory.dmp and then !analyze -v. Give the debugger symbols and you can get a more precise location of a failure. Good stuff.
Joe Nord
Comments (2)
Jun 01
Jim Moyle says:
Your link looks like it goes to a Citrix page which the general public has no ac...Your link looks like it goes to a Citrix page which the general public has no access to, I think you probably mean http://support.citrix.com/article/CTX118622
Jun 01
Joseph Nord says:
Thanks. I updated the post to have the correct link.Thanks. I updated the post to have the correct link.
Add Comment