Multiple MC9063 lockups at Kroger
1) 08:45/02-27-2009 2) ASAP 3) MC9063 4) WM03/DCP1.5 5) 1831481 I have attached a SymScript log sent to me by TA Kevin Horgan. His customer, Kroger, reports multiple lock-ups on MC9063/Verizon units within their application. They recently updated the terminals to DCP1.5 in an effort to resolve the issues. They are now beginning to report lock-ups occurring again. I am awaitng further details from Kevin, but he is requesting if someone can take a look at the attached log and reference the note below from Kroger personnel: Any assistance is greatly appreciated.
Yesterday evening, after spending an hour plus in Stage, I did a cold boot, sync to Production and it froze while ‘Updating Channel’
PROCESSSNAPSHOT_5.TXT.GZ is the log when It froze.
PROCESSSNAPSHOT_6.TXT.GZ and PROCESSSNAPSHOT_7.TXT.GZ were created after I warm booted it twice after it froze. (notes : Each warm boot create a new PROCESSSNAPSHOT_*.TXT.GZ file )
I'm guessing that the lockup occurred at 6:13 PM. Couple of interesting things. The first is that there seems to be a memory leak in the application. I notice that the memory load steadily decreased as the user navigated. This should not have led to the lockup since there was still 9M available. Also, I noticed the application pegged at 100% CPU utilization from time to time. Especially at 6:13. Unfortunately, the closest process snapshot was taken quite a while BEFORE 6:13PM.
George, thanks for your response! Here is the response to you from the end user, BTW, does this appear to be the customers application issue? or a WAN networki issue? It looks like the unit froze and then the backlight went off, when it was put in cradle? Any idea
When it froze, there were no key clicks when I pressed the keys.
My active sync is not working until now even though a few cold boots were attempted but Michael’s one is working fine. So I guess something wrong with my laptop active sync.
Before Process snapshot 5 occurred, I was in Stage environment kiwi.kroger.com for more than 30 mins, made a few transactions, it was working great. Then I performed a cold boot which took me to Process snapshot 5.
Process snapshot 5 was taken immediately after a cold boot. (Then I sync to Production environment grape.kroger.com) . Then an outgoing call was made to #777 and there were a couple of window focus changes. Finally ending on a Synchronization window (This synchronization window froze while ‘Updating Channels’, then I put it into the cradle) . Oddly enough the backlight went off. Then the terminal was warm booted (This warm boot was performed manually by me while It was in the cradle) .
Snapshot 6 was created and the terminal was placed into a cradle and warm booted again.
(This warm boot was performed manually by me when It was in the cradle)
Snapshot 7 was created a bunch of window focus changes - a suspend/resume - finally ending on a copy file dialog box. The terminal did not stop processing throughout the log that I can see.
TA Kevin Horgan has sent another SymScript log, which I have attached here. This is a log from a "good sync" from custom application. Kevin asks if you can compare this to the previous 'bad sync' logs which you analyzed previously, and see if you can pick something up that may be significant.
Process snapshot 5 was taken immediately after a cold boot. Then an outgoing call was made to #777 and there were a couple of window focus changes. Finally ending on a Synchronization window. Oddly enough the backlight went off. Then the terminal was warm booted. Snapshot 6 was created and the terminal was placed into a cradle and warm booted again. Snapshot 7 was created a bunch of window focus changes - a suspend/resume - finally ending on a copy file dialog box. The terminal did not stop processing throughout the log that I can see. I agree that much more information is needed. Reproduction steps, more precise time of failure, definition of "lockup" or rather a better definition of the failure. Does activesync stop? Do they hear key clicks when the press keys?