Understood.

Can someone please take a look at the latest attachment and comment. Comcast temperature is high.

This forum is a low priority method of communication between ECRT and CIC.  It's intent is to track and archive questions and answers.  It is not intended to replace the SPR process. Please capture the data from Comcast.  Define the problem.  Get the reproduction steps.  Reproduce the problem in-house.  Then open an SPR. If the problem can not be reproduced in-house, then have a discussion with ECRT about waiving that requirement.

Thank you. I will ask customer for this.  I know he will ask me this question, so let me ask; What can I tell the customer is the reason the files I have posted here cannot be analyzed, or are not sufficient?

Because there's no data telling us of the time of failure, so where in the logs should we look?

I have some further info from Comcast: I still do not have, nor will I until next week, the memmap or process files. However, there is significant activity and errors showing in the attached files at 9:02 am 4-7-09 which I was notified from our Blairsville office was the time of an incident. Please forward them on to the engineer for analysis if he will. I’m not looking for a cure, I’m looking for an “oh yea, there is definitely a problem here” then we’ll move forward and I’ll be able to get anything he wants. I don’t want to spin my wheels in a direction if it isn’t worth it.

The dump files Gene is referring to are available on any of our windows mobile devices and are created when an exception is thrown (you will usually see a popup asking if you want to send a report to MS).  They are located in \windows\system\dumpfiles by default and you will have to select show all files to see them.  You will need to pull them off before you dismiss the dialog because they are removed after they are sent to MS.

Thanks, John. To Gene:The complaint is not of a 'hard crash' but unit seem to experience these lock-ups more frequently as the day goes on. The customer claims this is not the RAM limitation issue. He states he has sifted through numerous logs and tried to send us only the logs that he himself believes gives some evidence of the problem. Customer temperature is getting hot...he would really appreciate if someone could view the logs and provide him some feedback. If you cannot view the logs please let me know hat else he specifically needs to provide. Thanks.

lets ask for the entire /application/symscript folder or /application/emscript folder (depending on what tool they are using) as well as any dump files and SS/RIL logs (if he got them). In addtion a time stamp of when they experineced the problem will help us know where to look. We can set up a brief meeting to review talk if/when we get the data if you like.

Thanks, Gene and George. I will push back on the customer and engage Tom Panierello, their TA, regarding your findings and see where we stand. I am out of the office today with no access to e-mail, but will post back when I have more details.

Thanks, Gene and George. I will push back on the customer and engage Tom Panierello, their TA, regarding your findings and see where we stand. I am out of the office today with no access to e-mail, but will post back when I have more details.

Gene, is that 'hidden dump file' a Comcast image add-on or is that on the default OS as well. In any case where can that be found?

As per the customer, EM Script caused his units to crash, even a clean/blanked unit. Customer (and Tom Panierello) seems to think the SS-Logs will reveal the problem. I informed customer , he may need to send unit to me for analysis if the logs he provided do not yield anything significant.

This ZIP file contains EMScript as well has SSLogs.  What is the time of failure for the terminal that these logs came from?

A couple of points here: 1) These logs appear to be from Symscript and NOT emScript. This is/was an intermitttent issue where Symscript would cause assert on a particular version when a process snapshot was taken (tpyically on 30 min intervals). emScript does not have this issue. 2) The logs attached here are not complete. We can work with the Symscript logs but the subfolders under sysmscript folder are needed. 3) A few weeks back we worked with comcast on their mc7x and well agreed that they were exhausitng the RAM limitations on the device. Please try to confirm that this is not a factor. 4) If there is a hard crash there should be a hidden dump file on the device. This file should yield the call stack to inidciate where the crash occured. hope this helps...

Why are we assuming that the lockup is caused by WAN?  Has the standard EMScript been used?