If you are one of the unfortunate souls who have been forced to support AX2012R2 in a Windows Server 2012 environment, especially on an all in one development machine, than you may have experienced the current problems (as of this date 3/7/2014) with the AX client having random troubles compiling with Windows Server 2012. What’s worse is that as usual, documentation is severely lacking on this issue. Let me explain what is happening and how to fix it. Disclaimer: the following methods are how I fixed it and got things working for a client when nothing else worked for them. These methods may not work in your environment as there really is no documented official fix right now. This is one of those issues where an experienced AX troubleshooter just feels it out until he/she finds a solution.

Basically, when you start a compile from the client, you end up with a big, nasty fat client crash after the client compiler has ran for several hours getting your hopes and excitement up at seeing how AX works with your newest updates or after a fresh install. You repeatedly uninstall and reinstall only to have your heart broken again and again with crashes.

I ran into this recently both on a client site and in my personal development environment. I’m going to spare you the details of what my old school MFC/AFC tool yielded but basically I was getting an Access Violation.

Access Violations are really hard to troubleshoot because they could mean everything. Here it means that the AX client was trying to access memory that somebody else was using. To find the somebody else would have actually taken a lot longer in debugging, and I couldn’t do that because my client was paying for the hour and this sort of thing is considered a Microsoft error. My client may have got upset at me if I spent hours debugging a problem that Microsoft will eventually have a working hotfix for. So, I tried out a few things.

Using some logical inference, I began to think about it… Who could be using memory that little, old poor Dynamics AX client wants?

Deciding to knock out two birds with one stone, I did something. I first disabled all SharePoint Services while the client compile ran on my development machine. My local Dev machine has everything on it but I would never do that in production. In production, I would have simply paused the crawler from running on my environment during compile time:

Finally, I did what I really believe to have fixed it. I downloaded and installed all updates for Windows 2012

That fixed it… and my compile completed with 4 warnings related to something else. I’ll fix those later. The important thing is that the compile completed in Windows Server 2012. I did still notice what looked to be like memory leaks, but I had enough ram on my machine to outlast the leak process until the compile process finished. Would have loved to verify this further, but time was an issue and clients don’t want you diving into Microsoft code bugs during work hours.

So, my simple advice until Microsoft comes out with a hotfix(3 hotfixes have been released so far from what I hear with bad results) that works to stop this bad memory problem.. Either client compile on a server with WINDOWS SERVER 2008R2 on it and export the modelstore to different computers. Or make sure that you completely update your Windows Server 2012 with all the available Windows updates.