******** Latest update 11-July-2011 ******** Scripts now allow class and table name resolution ********
This post explains how to find the AX user and the X++ call stack that caused an AOS crash - by using special scripts for WinDbg - before reaching this stage you need to first have captured a memory dump, and then set up WinDbg ready to do some analysis, we have posts which explain both of those steps: Capturing memory dumps: http://blogs.msdn.com/b/emeadaxsupport/archive/2010/05/12/possibilities-to-create-memory-dumps-from-crashing-processes.aspx Setting up WinDbg: http://blogs.msdn.com/b/emeadaxsupport/archive/2011/04/10/setting-up-windbg-and-using-symbols.aspx Once you have your memory dumps and have set up WinDbg, just open WinDbg, go to file- open a crash dump, and open the *.dmp file you created.
Note: these scripts are only currently compatible for AX2009 x64. For AX4 32 bit or AX2009 32 bit you will need to follow the manual way described in this post:http://blogs.msdn.com/b/emeadaxsupport/archive/2011/04/10/finding-the-x-call-stack-that-caused-a-crash.aspx
Attached to this post are three *.txt file scripts (in a zip file at the end of the post). These need to be saved to the same folder on your machine where WinDbg.exe is (which is typically something like C:\Program Files (x86)\Debugging Tools for Windows (x86)). These will enable you to retrieve some information from dump, even if you don't find any symbols.
The three scripts are:- AxUser.txt - this will find the AX user, their current company and their client machine name. - AxStack.txt - this will find the X++ call stack. - ThreadUserStack.txt - this will run both AxUser.txt and AxStack.txt at the same time and gives nicer output for running across all threads.
To run a script for the current thread enter $$><“script name”, for example:
Run the script as above when you're analysing a dump taken from a crash. When you load a crash dump in Windbg it will automatically switch to the thread which caused the crash, so just run the script and it'll return information relevant to the crash.
To run a script for all threads, you can run:
Run the script as above when you're analysing a dump taken from a hang - or any a manual dump that was nothing to do with a crash. When you load a manual dump in WinDbg it will default to the first thread, zero, so to see what the AOS was doing you will need to run the scripts across every thread and see which users and which pieces of X++ were active.
The output you see from the AxStack.txt script will look like this:
What you are seeing here is the kernel C++ call stack, and the scripts is picking up when there is an X++ call being made and extracts the details, the lines you see like "---------------------- X++ Stack frame: 0x20c :: mainOnServer ()" are the X++. The "0x20c" part is the class or table ID in hex, the quickest way to convert it to decimal is to enter "? 0x20c" in WinDbg.
Once you have the decimal value of the class/table ID you can run "info(classId2Name(524));" in an X++ job to find out the name.
If you have any questions or problems with the scripts please post a comment to this post and we will reply.
15-April-2011 - Attached scripts updated - added ability to pick up X++ stack frames relating to X++ kernel classes. /Tariq
26-June-2011 - Attached scripts updated - class IDs now converted to decimal instead of hex. /Tariq
11-July-2011 - Attached scripts updated - class and table IDs now converted to show names when public symbols are available (will still show only IDs when no symbols available).