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...

******** 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...

This post explains how to find the X++ call stack that caused an AOS crash - 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...

This post explains how to find the ax user that caused an AOS crash - 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...

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...

Yes you can. It is perfectly acceptable (and supported) to install just the kernel part of a rollup, so you can for example have your application version on 5.0.1000.52 (original SP1) or perhaps 5.0.1500.2985 (rollup 5) and have the kernel version on anything above 5.0.1000.52, such as 5.0.1500.3761...