There is an intriguing error in the scheduling engine – “A CLR error occurred while invoking the scheduling engine.“
The infolog message is not very descriptive…at first sight. However, if you focus on the message text above the error, you will see the details of the error in the bottom pane:
That may work for you, but in order to enhance the user experience, you may want to make a small change to the ProdUpdScheduling class, and handle the CLR error elegantly to show the error to the user.
We have encountered a CIL compilation issue for a custom class which referenced a custom VS project in the AOT.
The errors gave no indication as to the cause and looked as follows:
Cannot create a record in Compiler information (TmpCompilerOutput). Path: Classes<class><method>, Warning: No proxy found. Type FileIOPermission found on the stack. This code in Class: <class>, Method: <method>.
The record already exists.
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
The interesting thing is, that the class in question compiled fine. However, when we looked at it in the AOT, right after the CIL generation failed, and hovered over the method’s signature line, we saw a context error message stating: CIL generation: Error: .NET Cast Type Name not found. Type System.String found on the stack. This code in Class/Table: <Class>, Method: <method> may not work in CIL run time.
In order to resolve we copied the Microsoft.Dynamics.AX.Xpp.Support.dll assembly from the Server/Bin to Client/Bin, which produced a clean CIL compilation.
Received the following error when deploying a model store to a destination environment:
“…Binary stream ‘178’ does not contain a valid BinaryHeader….”
As part of the deployment, we exported the modelstore from the source environment, then copied the exported *.axmodelstore file over to the destination server, and imported the modelstore to the target environment. Turned out that the file was getting corrupted during the copy operation between the servers. The solution was to export and import the modelstore to/from the same network location.
Received the following error when consuming a custom AIF service, over Net.Tcp, from SharePoint 2013 :
The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was ’00:59:59.9780837′.
We had successfully consumed the service from other clients, such as a test VS project, ASP.NET page, as well as from the SharePoint’s timer job. The issue occurred only when making the call to the service when executed by the interactive SharePoint users. Turns out this has something to do with the user context/privileges. The solution was to force the SharePoint to execute the call under its application pool’s identity. Wrap the call to the service in SPSecurity.RunWithElevatedPrivileges:
We have received errors during the ‘Create tables’ step in the AX2012 Upgrade checklist. The errors were of the following format, and exceeded 10000…
[Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near ‘?’.
INSERT INTO SQLSYNCINFO (TEXT,TABLENAME,ID,PARENTID,LOGTYPE,MESSAGETYPE,SEQUENCE,
SYNCTABLE, WARNINGOK,RECVERSION,RECID) VALUES (?/*’/* block */’*/,?/*”*/,?/*0*/,?/*0*/,?/*1*/,?/*0*/,?/*1*/,?/*0*/,?/*0*/,?/*1*/,?/*5637172525*/)
The AX Server configuration was configured with the ‘-internal=comments –internal=nocursorreuse’ command. This setting is recommended by Microsoft for the duration of the upgrade, however, it needs to be set prior to executing the bulk copy scripts. The system errors out, if the setting is present during the ‘Create Tables’ step.
Removed the -internal=comments –internal=nocursorreuse command from the AX Server Configuration. (*added it back at a later stage in the upgrade process)
You may encounter this error when launching the Live Preprocessing or the Delta processing scripts, for the AX2012 Upgrade checklist in AX2009, even though you have successfully completed the Upgrade Readiness scripts.
We have encountered this error in the following scenario:
- Ran the Upgrade Readiness scripts. All scripts completed fine.
- Ran the Live Preprocessing scripts. All scripts completed fine.
- Opened the Upgrade Readiness scripts form to review the results; and closed the cockpit form without running the scripts again.
- Tried to launch the Delta Processing scripts > encountered the error.
When the Upgrade Cockpit is opened, it loads all the scripts, for the current stage, into the ReleaseUpdateScripts table. When the form is closed, it checks whether all the scripts have completed. If they have, the logic deletes the records from the ReleaseUpdateScripts table. The records in ReleaseUpdateScripts do not get deleted if the scripts, for the current run, have not completed.
The reason for the error was that when we closed the Readiness cockpit, the records in the ReleaseUpdateScripts table did not get deleted.
Delete all the records from the ReleaseUpdateScripts table.
We have faced an interesting issue with the upgrade cockpit, executed in AX2009 as part of the AX2012 upgrade. There appeared to be a disconnect between the upgrade cockpit and the batch job – the cockpit showed the script as finished, while the batch job showed it as failed. This turned out to be an issue with the upgrade framework logging.
The cockpit shows the job as ‘Finished’:
However, the corresponding Batch Task is failed:
In this particular case the table in question, DEL_AddressStateUpgrade, was in fact populated properly – providing the indication that the upgrade script has completed successfully. Therefore, it appears the cockpit status was in fact correct, while the batch job was not. So what was going on?
It turned out the issue had to do with the way the upgrade framework monitors the state of the scripts’ execution. As scripts are executed, their statuses get written to the ReleaseUpdateControlData table. This table tracks the last record executed by the script. This information is stored in the ControlData container field, and typically holds the RecId of the last record processed. This enables the upgrade cockpit to pause, resume and restart, making sure each record is processed only once. Every time you re-open the upgrade cockpit, all of the scripts are added to the batch job, regardless of their status. This means that each script is re-executed every time the upgrade cockpit is re-launched. The ReleaseUpdateControlData logging is what makes sure that only the data that hasn’t processed previously is operated on, each time the script is executed. (By the way, this means that you can’t simply update the batch job status to ‘Complete’; nor can you update the records in the ReleaseUpdateScripts table – as these statuses do not prevent the scripts from re-executing).
What caused the issue in our case, is the fact that for some reason the record in the ReleaseUpdateControlData, for the script in question, wasn’t updated with the correct ControlData (last record ID). The RecID stored in the ControlData field, was smaller than the greatest RecID in the source table (AddressState in this case).
- Delete the ‘corrupt’ record from the ReleaseUpdateControlData table
- Delete the script’s target tables – in our example the tables populated by the script are ‘DEL_AddressStateUpgrade’ and ‘LogisticsAddressState.’
- Re-launch the data upgrade cockpit – which reruns the upgrade script successfully
*We have seen a flavor of this issue, where the ReleaseUpdateControlData record didn’t get written at all. The solution in this case is similar: delete the target tables, populated by the script and rerun the script. This procedure may need to be executed every time prior to re-lunching of the cockpit, as from what we saw the record never got created for the script in the ReleaseUpdateControlData table. Manually creating a record in this table didn’t resolve the issue.
We have encountered the following error while generating a full CIL as part of a CU1 upgrade of AX2012 R2:
Could not load file or assembly ‘Dynamics.Ax.Application, Version=18.104.22.168, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. The system cannot find the file specified. —> System.IO.FileNotFoundException: Could not load file or assembly ‘Dynamics.Ax.Application, Version=22.214.171.124, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. The system cannot find the file specified.
Turned out, the AOS account permissions were modified, and the account no longer had full access to the CIL assembly folder – “..ServerBINXPPL”. The solution is to restore the full control rights to the folder for the AOS account.
If you receive the following error when running an SSRS report –
“An exception of type MetdataException has occurred while performing the operation.”
– the issue most likely has to do with the AX datasource metadata. One such possible cause is an incomplete definition of a relationship on a table. For example, we ran into this issue when printing the Project Invoice Journals report. The report was not customized, but it turned out that the datasource table was customized by a previous implementation partner. A table relation was added to the ProjInvoiceJour table, which contained no lines. Fixing this relationship resolves the metadata issue.