Once you have collected a dump file, to analyse it you need to use a tool called WinDbg. In this post I am going to explain how to set up WinDbg so it's ready to debug a memory dump taken from a Dynamics AX process. If you're not sure how to create a dump file, just take a look at the post below, scroll down to the subtitle "What do I need to create a Crash Dump?" and you'll find what you need there:
Getting WinDbg set up is a fairly straightforward task, just download and install the Windows debugging tools from the link below. You might need to install both the 32bit and 64 bit versions – if you are looking at dump files from a 32bit operating system then use the 32bit tools, and if it’s from a 64bit operating system use the 64 bit tools.
32-bit OS: http://msdn.microsoft.com/en-us/windows/hardware/gg463016.aspx 64-bit OS: http://msdn.microsoft.com/en-us/windows/hardware/gg463012.aspx
If you’re not sure which OS a particular dump file came from (and it's always good to check just to be sure) then when you open a dump file, with either version of WinDbg it will tell you which operating system it was taken from, here’s an example, with the important part highlighted in yellow:
Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Temp\Ax32Serv.exe.4408.dmp] User Mini Dump File with Full Memory: Only application data is available
Executable search path is: Windows 7 Version 7600 UP Free x64Product: Server, suite: Enterprise TerminalServer SingleUserTSMachine Name:Debug session time: Thu Dec 30 11:26:55.000 2010 (GMT+0)System Uptime: 0 days 23:42:28.537Process Uptime: 0 days 0:21:20.000................................................................................Loading unloaded module list......This dump file has an exception of interest stored in it.The stored exception information can be accessed via .ecxr.(1138.c3c): Stack overflow - code c00000fd (first/second chance not available)ntdll!NtWaitForSingleObject+0xa:00000000`779efd9a c3 ret
Before you start to use WinDbg you also need to configure the symbol path – just go to file->symbol file path and the path you need to enter for the Microsoft public symbol server is: http://msdl.microsoft.com/download/symbols If you haven’t come across the concept of symbols before, then a short explanation is that the symbols are used to decode the information held in the memory dump file which allows you to see the function names in the call stack, to give an example of what you might see with and without symbols: With symbols:
As you can see in the above example, without symbols it is not possible to read the call stack. Each specific version of an application has a unique symbol file – as they related directly to the source code for that application, so if one line of source code is different inside the application then a new symbol file is generated to match it.
You can run the command “lmv max32serv” in WinDbg to find out which kernel version the AOS is running (if it’s a dump taken from an AOS) or “lmv max32” to find out which version a client is from a client dump. The output in Windbg will look like this:
Sometimes there might be a problem loading symbols for the specific version of AX that you are running – in that case there are some WinDbg commands which can help you, first you can turn on “noisy” symbol loading prompts so that WinDbg will give information about where it is trying to find the symbols and what the result was (like “file not found” or something like this), there are two commands you need in Windbg to do this:
The .reload command will attempt to reload symbols, and the “!sym –noisy” will turn on noisy prompts. You can also force WinDbg to load a mismatched symbol file – if you can’t find the exact matching file for your version, the command to do that is:
Now you're ready to do some analysis and extract some interesting information from the dump file, to do that see the following posts: