eMessage Agent-Specific Status Messages in the Application Log

Troubleshooting SCM > eMessage Agent-Specific Status Messages in the Application Log

A delivery target may fail terminally (exhaust all of its retry attempts) leaving only a non-specific error message in the Application Log of ThingWorx Platform. For example, the following message might appear:

Error downloading package to: MyAxedaThing : Marking target asset status as failed.

In this case, if you have access to the Data Table that stores the delivery targets (TW.RSM.SFW.SoftwareManager.DeliveryTarget), check the delivery target there to determine what the StatusMessage field says.

If the StatusMessage is not clear, consult the following table for the meaning:

Meaning and Possible Root Causes of Status Messages
StatusMessage	Meaning	Possible Root Cause(s)
ec = 12	This error code is from an Axeda agent, saying that there was an Archiving error.	The machine where the Axeda agent is running does not have enough disk space for the agent to complete the download.
ec = 14, xc = 500	This error code is from an Axeda agent, saying that it received an unexpected HTTP status code.	There are many potential root causes for this message. If you encounter this error, additional log entries in the Application Log can help. Refer to the rest of the topics in this section for more information about errors in the Application Log. Alternatively, consult the log of the eMessage Connector for any related error messages.
ec = 21	This error code is from an Axeda agent, saying that after a file was downloaded, the checksum verification failed.	There are multiple possible root causes: • Temporary issue (network?) • File was modified some time after the package was last updated or published. ◦ Check to make sure the file was not updated after the package was last saved and that its contents are correct. ◦ If the contents of the file are correct and a modification of it was intentional, save the package again. If the package has already been published, create a new one. • During a test deployment, the order of instructions or the details of a Download instruction in the package being deployed were changed. • Man-in-the-middle attack.

If consulting the Delivery Target table is not an option, the logs of any Connector being used or of the agent itself may be helpful.

Alternatively, set up a subscription on the DeliveryTargetStatusChange event of the TW.RSM.SFW.SoftwareManager Thing. Record the value of the StatusMessage field that the event provides when failures occur (based on the value of the Status field). The stored status message can then be reviewed later and resolved against the above table, if necessary.