Ever been in a situation where your AOS crashed? And all you had to show for it was a lousy event log message 1000 which didn’t tell you anything except that it crashed?
Or perhaps you’ve just wanted to see what your AOS is actually running at a given moment in time? It could be very useful to have the ability to take a snapshot and see what’s going on inside the AOS process.
Well now this is possible. We have the first of a series of posts out now which describe the steps you need to get up and running with generating memory dumps from your AOS and analysing them using WinDbg. The posts are linked below, with a quick description to show the steps required:
First you need to generate a memory dump to analyse, the post below explains the different options you have for that:
http://blogs.msdn.com/b/emeadaxsupport/archive/2010/05/12/possibilities-to-create-memory-dumps-from-crashing-processes.aspx
Next you need to install the tool “WinDbg” on your machine which will be used to analyse the dumps:
http://blogs.msdn.com/b/emeadaxsupport/archive/2011/04/10/setting-up-windbg-and-using-symbols.aspx
After that you can start pulling information from the dumps, these two posts explain how to find the X++ call stack and the AX user:
http://blogs.msdn.com/b/emeadaxsupport/archive/2011/04/10/finding-the-x-call-stack-that-caused-a-crash.aspx
Finally this post shows how to run scripts which we’ve created for you to enable you to pull information very fast from dump files, and to pull information even when no symbols are available:
http://blogs.msdn.com/b/emeadaxsupport/archive/2011/04/10/finding-the-ax-user-and-the-x-call-stack-from-a-memory-dump-the-easy-way.aspx
Happy analysing! Any questions/comments/problems just post a comment on the relveant post and we will reply.
–author: | Tariq Bell |
–editor: | Tariq Bell |
–date: | 10/04/2011 |