I previously logged a problem with accessing the OData interface on our Azure DEV instance on Dynamics 365 for Operations. (https://community.dynamics.com/ax/f/33/t/237419). I have received no replies indicating what the problem with this is, but, as it didn't seem to affect the UI, I've continued to use the instance for testing configuration. Specifically, I've configured the SMTP service on the VM and tested workflow notifications.
Today, I decided to start looking at the OData issue, and, with no changes, now find that attempting to connect to the OData service actually kills the AOSService and, after a few attempts, disables it altogether resulting in a "Service Unavailable" response.
Looking in the VM's system error log, the first Warning from WAS is an Event ID 5011: "A process serving application pool 'AOSService' suffered a fatal communication error with the Windows Process Activation Service. The process id was '8532'. The data field contains the error number." The data contains 0x8007006D, which a search indicates is "Broken Pipe". This warning gets repeated 5 times , with differing process IDs, until WAS reports an Event ID 5002: "Application pool 'AOSService' is being automatically disabled due to a series of failures in the process(es) serving that application pool." Rebooting the VM allows the UI to be active, but accessing ".../Data" initially gets the "key has already been added error" and attempting to access a custom data entity will crash the AOSService again. Simply restarting the AOSServer application pool, the UI attempts to start, but fails, reporting lost connections 5 times followed by "Service Unavailable"; the System Event Log records the same set of five 5011 events followed by the AOSService application pool being disabled.
Since this system was working prior to refreshing the data from our UAT instance using a BacPac copy, I assume there is something wrong in the database, but am currently at a loss to know where to start. As mentioned before, I have used Visual Studio to do a complete rebuild and resynchronise database, but this hasn't fixed it.
My next step will be to build a local VM and refresh it with the same data to see if it has the same problem. If it doesn't I can just delete/redeploy the cloud instance, however, if it has the same error, then I am not sure how to proceed, since there don't seem to be any pointers as to what the issue is.
Obviously, I would prefer to simply fix whatever data is causing this, since building a new instance will take significant time, but without some indication of where the problem is, I'm stuck.
Any help would be gratefully received.
Thanks
