Try Microsoft Edge
A fast and secure browser that's designed for Windows 10
Here is what i have found in the event log.
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
Faulting application name: Ax32.exe, version: 6.0.1108.670, time stamp: 0x4fe8e851
Faulting module name: MSVCR90.dll, version: 9.0.30729.6161, time stamp: 0x4dace5b9
Exception code: 0xc0000005
Fault offset: 0x0003ae7a
Faulting process id: 0xfb44
Faulting application start time: 0x01ce00eb2321ce79
Faulting application path: C:\Program Files (x86)\Microsoft Dynamics AX\60\Client\Bin\Ax32.exe
Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.dll
Report Id: 67cc990c-6cde-11e2-91f0-d4ae5290231b
Can anyone point me in the right direction?
You need to check the configuration file on the client. This is caused by a number of things, but it usually concerns these settings. I'd see if ithe client was pointed at the right server first.
Go to Start > Control Panel > Administrative Tools > Microsoft Dynamics AX 2012 Configuration, and start comparing settings to users with working accounts. You'll probably find something.
Try clearing usage data and deleting user cache
Thank you for that suggestion. Clearing out the .auc file from the users profile fixed the problem.
How do you do this? "Try clearing usage data and deleting user cache" (AX32 is on a citrix server) other users are not having this issue....Thanks in advance....
Usage data is held within AX.
Login as the user. Go to File > Tools > Options > Usage data and click the Reset button to delete all usage data. Then log off and log back in.
Clearing the cache is a bit tricker, becuase where it is depends a bit on the operating system. You're looking for files with a .auc extension and they're probably in something like C:\Users\xxxx\AppData\Local
Is there any option to clear this cache automatically? I have more than 10 users that same symptom, and I always clear it each of them every month. Thanks.
What version of AX?
We have just gone live on AX 2012 R2 CU6. There were a lot of client crashes caused by End user form personalisation. We cleared the 'Form pre-loading enabled' option at System administration > Setup > System > Client performance options and that solved the issue, but I have heard that the underlying issue is fixed in CU7.
Tim, we are running AX2012 R2 with no cumulative update (version 184.108.40.206), and yes we have a lot of user forms customized.
This error shows only in branch office with Citrix XenApp, users in HQ never get this error.
I am gonna try as you said Tim, let's see next month.
This solved my problem I cleared usage data and the error is gone. Thanks TIM
Thanks for the information.
It also works to me.
We were able to find the files in C:\Users\xxx\AppData\Local\Microsoft\Dynamics Ax\ <look through all files>
This was also an issue for us after upgrading to AX 2012 R3
Is there any other solutions?
We already tried to clear the *.auc several times but still got the same error.
The error is a little bit different:
Exception Info: System.DivideByZeroException
The error is not "System.AccessViolationException" but "System.DivideByZeroException".
Tried accessing from two different computer, both got the same error.
Our kernel and client version is the same 6.3.2000.326
Have you tried resetting usage data for that user (not the AUC file, but the data stored in SysLastValue for the account)? It is possible that there are some old values packed in the SysLastValue table for the user, and somewhere it does a divide with the unpacked blank/zero value which causes the crash.
Alternatively you could collect a crash dump (.DMP file), and upload it on the LifeCycle Services sites' Crash dump analysis tool to get some ideas that from where does your error come from.
Thought to share a way to fix (or more of a workaround) on this issue as well. I seen this two times in the last months, and in both cases for some users AX worked while for others it did not.
Truncating the SysLastValue (of course try this if you can lose all the setup for all users) didn't worked, as well as deleting all the *.uac and *.kti files.
The obvious answer was the some particular settings in the UserInfo table (or possibly in the SysUserInfo) were different, so I went into SSMS and start comparing two users (one working and one not). For sure you will get a meaningful difference.
In my case, the result: both times the difference was the Language used. Setting the language to a working one fixed this (if you are not using two languages you could try just set another one like en-different one) and see if the client starts.