End of mainstream support for Microsoft Dynamics AX 2009, 2012, and 2012Mainstream support for Dynamics AX 2009 Service Pack 1 (SP1), Dynamics AX 2012, and Dynamics AX 2012 R2 ended Oct. 9, 2018. After that date, only security hotfixes will be provided for these three versions through the extended support period that until Oct. 12, 2021. Read more
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
We are experiencing a really weird issue with some of our consultants using Windows 10 on their laptops. When trying to execute the client from a Terminal Server session we get this:
Faulting application name: Ax32.exe, version: 6.3.5000.138, time stamp: 0x582a2117Faulting module name: clr.dll, version: 4.7.2053.0, time stamp: 0x58fa6bb3Exception code: 0xc0000005Fault offset: 0x0045138dFaulting process id: 0x1dccFaulting application start time: 0x01d3477e50b44820Faulting application path: C:\Program Files (x86)\Microsoft Dynamics AX\60\Client\Bin\Ax32.exeFaulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dllReport Id: 8ff1b6a7-b371-11e7-80f7-00155d015e68Faulting package full name: Faulting package-relative application ID:
Now, if I take control of the session from a Windows 8 laptop (no logout or anything, simple takeover). I can run the AX client normally.
Kernel version and App version are fine. I'm assuming this is a UI presentation issue with Windows 10.
Has anyone experienced this? If so, how did you solve it? So far, the only way we found to solve the issue is to restart the laptop where Terminal Server Client is being executed.
Thanks in advance.
You can read more about your issue in this link: blogs.msdn.microsoft.com/.../what-to-do-if-you-have-a-crash
Thanks for your feedback. However, AOS is not an issue here. In my opinion is Windows 10 rendering capabilities. When terminal server is initiated from windows 10 and you start the AX Client it crashes immediately, it never reaches the AOS. I already traced this. Now, the user doesn't sign out, the same user comes into my Windows 8 machine initiates terminal server and takes over the session he/she had in terminal server seconds ago. Once it double clicks the AX client it opens without a problem.
This is telling me Windows 10 is the issue, or the Terminal Server Client that comes with Windows 10. Once the user restarts Windows 10 and takes over control of his/her session (just like we did with Windows 8) AX runs perfectly.
I'm trying to see if anyone knows a fix without the need to restart the user's computer.
Did you ever find a solution? We have been experiencing similar issues on a terminal server session with Windows 10 PCs. As you noted, I can take over the session from a windows 7 pc and the issue goes away. In addition to the message you posted, we also have seen this even.
Faulting application name: Ax32.exe, version: 6.3.6000.4444, time stamp: 0x5a804dcb
Faulting module name: KERNELBASE.dll, version: 6.3.9600.18666, time stamp: 0x58f32841
Exception code: 0xe0434352
Fault offset: 0x00015608
Faulting process id: 0xe28
Faulting application start time: 0x01d3b49a71f150ff
Faulting application path: C:\Program Files (x86)\Microsoft Dynamics AX\60\Client\Bin\Ax32.exe
Faulting module path: C:\Windows\SYSTEM32\KERNELBASE.dll
Report Id: 6343ddc7-2091-11e8-80d9-001dd8b71c95
Faulting package full name:
Faulting package-relative application ID:
Hello Kevin & Gustavo,
If you have already verifies that the client and AOS are running on the same version. Go to the user profile and delete the .auc & .kti files from C:\Users\Username\AppData\Local. This should be done on every RDS server the user has a profile on. There is most likely a mismatch in the versions of the local files and by delete these files it will rebuild the new ones with the correct version.
Thanks for your response. The issue started for us after windows updates on the server (.net updates were part of it). Part of our first steps were to delete usage data in AX as well as the kti, auc, and dat files for the users experiencing the issue. Later we realized that it was only an issue for Windows 10 PCs. The same user could login from a previous version of windows and it worked ok. Since, we have also updated the AX kernel to the latest update across all instances installed with no luck.
I had opened a ticket a while back with Microsoft and they verified it was something in the UI (debug diag logs), but since we were having the issue with 1 of 2 RDP servers it was brushed off as a conflict with something else installed. Since then, we have seen it on both servers.
Is there a documented way to tell the client to use an updated version of .net? I have edited the ax32.config file to specify .net 4.5 and was done yesterday and are still testing. I'm not sure if the config edit is correct or not.
this is what i set, not sure if correct or not.
<supportedRuntime version="v4.0.30319" sku=".NETFramework,Version=v4.5" />
<requiredRuntime version="v4.0.30319" safemode="true"/>
Could you solve the problem ??
Business Applications communities