emeadaxsupport: What to do if you have a crash

[Blog bot]

Источник: http://blogs.msdn.com/b/emeadaxsuppo...e-a-crash.aspx
==============

This post is designed to give a simple set of steps to follow if you ever have a crash situation and you're not sure how to troubleshoot it.

To identify the cause of a crash the most important piece of evidence or log is a memory dump file - you need to set something up before the crash to collect a memory dump in the event of a crash. It is really important to do this, if you have a crash and there is no memory dump then in most cases you are unlikely to identify the root cause. It is therefore a great idea to set up memory dump monitoring before a crash occurs as a kind of "insurance policy", so if the worst should happen you can do something about it.

If you haven't come across the use of "memory dumps" before then a short explanation is that these are a snapshot of the application at the moment of a crash, it is as if the process is paused for a moment as it crashes and a picture is taken - analysing this afterwards allows you to see what was running at the time, and which line of code we crashed on.

There are various different options for collecting memory dumps - here I will explain the ones we recommend and why we recommend them:

1. The simplest option if you have internet access from your AOS machines is to check the "For all AOS instance inthis computer, automatically send reports about fatal errors to Microsoft" in the AX Server Configuration Utility (from administrative tools).

This will upload a minidump file to us, anonomously, if your AOS crashes, at the same time it will log an event 1001 to your event log. If you then contact us through a support case we can take the "bucket id" from your event 1001 and retrieve the minidump. We also proactively review all of the files uploaded through this route, even if you don't contact us, and address the issues they show us.

However as they are anonomous we can't contact you about them as we don't know who they came from - so you have to contact us if you want us to take specific action.

2. If you have Win2008 or above (Win2008, vista, Win7 Win2008R2) then you can configure WER - Windows Error Reporting to capture dumps.

This uses a feature of Windows - it just means setting a few registry keys and then your AOSes will be permanently monitored and if anything happens a full dump file will be generated.

This contains more information than the mini dump above, and it won't upload itself anywhere on it's own - you can retrieve the file and use it for analysis or contact us through support for help analysing it.

Steps for setting up WER are available at this post, just scroll down it until you see the heading "Windows Error Reporting (WER)":

http://blogs.msdn.com/b/emeadaxsuppo...processes.aspx

3. If you have Win2003 - and it's 32bit/x86 then you can use the Debug Diagnostic tool to collect dumps.

This is a graphical tool you install on each AOS, it doesn't require a restart, you configure a rule to monitor your AOS (using a wizard so its pretty straightforward) and then it runs as a service so you can leave it there running permanently just in case it's ever needed. The performance overhead of doing this is negligable.

Steps for Debug diagnostic are available at the same post, just scroll down to the heading "Debug Diagnostic Tool v1.1 (DebugDiag)":

http://blogs.msdn.com/b/emeadaxsuppo...processes.aspx

Why not another tool?

The reason we are not recommending the use of procdump or adplus here is that they are command-line tools that mean you have to leave a session running on the machine with the tool sitting there running - if you log off the machine they will terminate, and they will also terminate any applications they are monitoring - so if you set one up and log off your AOS will suddenly stop! They are great tools and there is a place for them, but because of the risk of accidental termination we wouldn't recommend them for long term usage.

The tools above (WER and debugDiag) can be set up and left running in the background and you can log off and carry on with your work without worrying about them.



If you're interested in doing more with AOS crashes or to see what's going on inside your AOS, there is a series of posts which explains more about how you can work with memory dumps for AX:

http://blogs.msdn.com/b/emeadaxsuppo...t-s-doing.aspx

We also have a more detailed post explaining further about what to do if you have an AOS crash here:

http://blogs.msdn.com/b/emeadaxsuppo...processes.aspx




Источник: http://blogs.msdn.com/b/emeadaxsuppo...e-a-crash.aspx