Home > Citrix, Debugging, XenApp, XenDesktop > Debugging for Starters – III

Debugging for Starters – III

December 13th, 2011 Leave a comment Go to comments
 

Debugging for Starters – III

First two blog posts in this series are -> http://blog.lkctx.com/debugging-for-starters-i

http://blog.lkctx.com/debugging-for-starters-ii/

We already discussed different terminologies, different types of dumps, tools to create dumps and also, how to check if they are good for analysis or not. In next couple of articles, I will document steps require to open a dump in Windbg. I will also try to document  steps require to troubleshoot some common issues related to :-

  1. Application\Server crash
  2. Application\Server hangs
  3. CPU Spikes, etc;

and will add some more tools as and when require.The main tool that we are going to use is Windbg.

http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx

The installation of Windbg is pretty simple, anyone who has ever installed any software on Windows , can do it. However, before opening the dump, you need to configure the symbol server.

Symbols – In simplest way, Symbols (.pdb files, generated during application compilations) convert 01010101 to ‘human readable’ English. There are more technical definitions exist on internet but this is the simplest I can think of. Symbols are provided by the application vendors, usually they have their Public facing Symbols server. For example: -

How to configure symbol Server ­

So let’s start and open -> Windbg (Start-> Programs -> Debugging tools for Windows) and configure ‘Symbol’ server location in Windbg.

SRV*c:\symcache*http://msdl.microsoft.com/download/symbols;SRV*c:\symcache*http://ctxsym.citrix.com/symbols

If you don’t do this and try to open a dump file inside Windbg, you will see following: -

So now, once you have Symbol server configured properly, we can start first step to open a dump in Windbg.

I also find it difficult to follow theory without any example, so I will cover the analysis part with some real-world example.

Disclaimer – Please note that the issues described in my posts may not be actual issue you are facing and should not be consider as issue with specific application or software. I have forced some of this issues to happen, with the help of different tools, for the sake of this tutorial. However, the steps mentioned can be used while dealing with similar issues with any application.

How to read the Open and read the Dump

Opening a dump is very simple if you have write symbols (as mentioned above). File -> Open a Crash dump and then select the dump file. Some of the important things to notice are: -

  1. Types of dump
  2. System\Process uptime
  3. Symbol search path

You can do the basic analysis with just one simple command: – !analyze –v

Usually, it will return and highlight the module that is culprit, however, don’t always believe it as it will, by default, seems to look for any 3rd party non-OS components and point it (as OS components are pretty stable). The most important part is the stack it is pointing to, some of the rules are: -

  1. Read from bottom and go up
  2. Check all the components involved
  3. Check the last components called

Above is an example of a stack and different components involved. This crash is generated using SystemDump utility, therefore, SystemDump components is on top on the stack and culprit for this crash. The same technique can be used to analyze most type of dumps.

I think this is enough for today’s post. From my next post, I will start covering some common scenarios and will give some example to show how easy is to do the basic analysis.

Please let me know your feedback and any topic that interest you.

  1. March 14th, 2012 at 02:19 | #1

    I’m searching to get a proficient author, extended time in this area. Outstanding write-up!

  1. No trackbacks yet.