Tech Forum

The file "/ces2mls" is badly formed and cannot be processed. Contact your stake . . .

In our recently formed YSA Stake, most of the wards are getting the above quoted message after completion of a send and receive. It seems to have started with installation of MLS 3.2.2. It is not preventing a normal send and receive, but any error message with an MLS send and receive gives me a little "heartburn" I have not yet called Headquarters about this error message. Does anyone have insight about this message and the resolution of it? Thanks in advance.

Ralph Bair
Stake Financial Clerk
Logan Utah YSA 4th Stake

I did not see anyone reply to this. Is there a solution?

RKB wrote:The file "/ces2mls" is badly formed and cannot be processed. Contact your stake . . .

In our recently formed YSA Stake, most of the wards are getting the above quoted message after completion of a send and receive. It seems to have started with installation of MLS 3.2.2. It is not preventing a normal send and receive, but any error message with an MLS send and receive gives me a little "heartburn" I have not yet called Headquarters about this error message. Does anyone have insight about this message and the resolution of it? Thanks in advance.

Ralph Bair
Stake Financial Clerk
Logan Utah YSA 4th Stake

It's possible that someone in the forum may have a resolution, but I would suggest that you make contact with your Stake Technology Specialist and him contact the MLS service desk for assistance (801) 240-3500

'Malformed' to me indicates a corruption of the file at some stage in the creation or migration of the data from the CES system into the MLS system, then to you, or improper delimiting of the data in the file. I assume this is Institute enrollment info or something like that (given it has CES in the filename), so I am thinking something more has to be done at the CHQ level to fix this one.

The error message specifically states:

The file "/ces2mls/" is badly formed and cannot be processed. Contact your stake clerk for assistance. The stake clerk should contact support if he needs assistance to resolve this problem.

I have gotten this error on every unit I have tested this morning (4 so far). I contacted support and was given the following solution:

• Exit MLS. It must be completely closed, not just logged out.
• Navigate to C:\Documents and Settings\All Users\Application Data
  • -You may have to change your folder view options if you can't see the Application Data folder. To do this, in the menu bar navigate to Tools > Folder Options.
  • A pop-up window will appear. There should be several tabs at the top. Click on the tab that says "View".
  • Under "Files and Folders" > "Hidden Files and Folders" select the option "show hidden files and folders"
  • Click OK. You should now see the folder Application Data.
• Delete the udx folder

Log back in to MLS and send/receive.

IMPORTANT: It appears this will unauthorize your computer, meaning you will not be able to transmit. As part of the process, then, you must contact Local Unit Support and have them reset your security token on their end so that you can send/receive again.

The analyst I spoke with needed to have the unit number of each unit that received the error so he could reset the security token for me.

crislapi wrote:As part of the process, then, you must contact the GHD and have them reset your security token on their end so that you can send/receive again.

I thought that security resets were done by Local Unit Support, not the Global Service Desk (which is what I think you meant by "GHD").

You are correct. I have updated my post.

As a follow-up, I have checked a couple other units (still not all, however) and those units did not receive the error. So from what I have observed, the only units that received this error are the ones that meet in the afternoon and were therefore affected by the MLS server outage. I don't know if they are in fact related, but seems so to me.

The error only appeared on the first send/receive. Subsequent transmissions did not deliver the message. It would therefore be nice to have some way of testing to determine what units, if any, did not report the message but still have the problem. Anyone have any ideas?

crislapi wrote:As a follow-up, I have checked a couple other units (still not all, however) and those units did not receive the error. So from what I have observed, the only units that received this error are the ones that meet in the afternoon and were therefore affected by the MLS server outage. I don't know if they are in fact related, but seems so to me.

The error only appeared on the first send/receive. Subsequent transmissions did not deliver the message. It would therefore be nice to have some way of testing to determine what units, if any, did not report the message but still have the problem. Anyone have any ideas?

I don't think they are related since I have been getting the error for about three weeks. Only on the first transmission after a cold boot. My stake clerk is working on the issue so I will pass on the above repair suggestion to him.

After performing this fix during the week, one (and only one) of the units had this error message re-appear yesterday. I'll try the fix again, but if the error shows up again, it may be time to contact Local Unit Support again for a more permanent repair.

As a reminder, deleting the udx folder de-authorizes your computer, so don't attempt the fix on Sunday. There is no one there to help you reauthorize your computer. As an aside, restoring from the Recycle bin should you happen to do this on a Sunday does return your send/receive capability. Yeah, I tried to fix this yesterday before I remembered all that.