Windows CE.Net Problem

I have been having a BIG problem with debugging an application on CE.Net.  This is NOT a standard problem.  Basically I have an application that is collecting data from a TCP/IP port and then transforming this into web pages and logging the data to a CEDB on a CF Card.  There are wireless drivers for the Cisco wireless card on the build but there is no card in the device at the moment.  (This we think is inconsequential... as it fails with or without the wireless card). 

The problem is after 4 and a half days (between 320 million and 370 million ticks using GetTickCount()) the entire CE platform crashes.  There were no reported exceptions and no unhandled exceptions from our code.  The memory was not any where near it's limit and there was no excessively high processor load.... We just can't figure it out.  We thought at one point that it was wireless related... but the devices fell over either way.  We tried removing the wireless drivers and Zero Config (because we heard that there are issues here!) from the build and that has kept 2 out of 4 devices running but 2 fell over still.

We have tried running the database on it's own and done multiple writes... it kept on running over the 4 and a half days... we tried removing the database from the code base and outputted to a UDP logger, and this kept running over the 4 and a half days... What? Why???!

We removed all unmanaged code from the code base and re ran the same tests... Still no joy... the code still fell over.. so that area isn't causing the problem.

So the question is?  Do we have a problem with wireless?  Do we have a problem with CF Card writes?  Do we have a genuine CE.Net issue? 

It takes us 4 and a half days to get the results of any test that we do... any ideas on how to speed this process up would be appreciated and ANY help from the MS CE team would be more than greatly appreciated at this time!  At the moment we have the developers and the OEM working on this problem but noone has been able to identify where the real issue lies.  It is like trying to find a needle in a haystack!!! HELP!

Let me know if you or anyone you know has had similar issues and how you resolved them.  I would really really appreciate it.

Sarah

posted @ Tuesday, June 14, 2005 3:16 PM

Print

Comments on this entry:

# re: Windows CE.Net Problem

Left by Minh at 6/15/2005 5:13 AM
Gravatar
How about multiplying the value you get back from GetTickCount() to "accelerate" time. For example

x = GetTickCount() * 1300;

will make 4.5 days go by in 5 minutes. If it's tick count related, this may show the problem quicker.

# re: Windows CE.Net Problem

Left by Mike Dimmick at 6/16/2005 12:02 AM
Gravatar
We have a thin-client application in use at New Look, which is now rolling out across all their stores. The server application logs all device restarts. Some of the devices haven't been restarted for more than two weeks - the rollout has only recently started in earnest, so there are a lot of more recent events.

We're now using Symbol's MC3000 hand-helds (based on CE 4.2). This wasn't New Look's original choice. Their original choice, who I won't name, had lots of unpredictable odd behaviour. They eventually traced this to incorrect synchronisation code protecting (or not, in fact) the use of their power routing chip. They claimed to have fixed this and released new firmware only a couple of weeks after telling us about it. The problems still occurred with the new firmware, and at that point New Look decided to ditch that OEM.

Symbol nearly stuffed up the contract by releasing the MC3000 with firmware that had some network driver issues and constantly reported that the backup battery was critically low. Thankfully they actually were able to fix this reasonably quickly (although if you now look at their developer website, they don't admit that this previous firmware version ever existed).

On a previous Symbol unit, we discovered an issue where, if you had the GPRS radio enabled, and wrote to Flash, the GPRS radio stopped working until the device was rebooted. Again, it was a power issue - the Flash write left the power line in a high-voltage state, leaving too little power for GPRS to function correctly.

We're currently having a problem with another customer where warm reboot commands are actually resulting in cold boots, i.e. some settings are lost. The warm boot operations were to work around an issue where WinInet FTP operations won't cancel if the underlying connection has gone down - we've opted to leak the connection rather than lock up the device.

If you have alternate hardware you can try this software on, I suggest doing so. That might help indicate where the problem lies. Presumably you've tried placing the database on on-board RAM rather than a CF card?

# re: Windows CE.Net Problem

Left by Sarah Blow at 6/21/2005 3:53 PM
Gravatar
Thanks for all your help we tried speeding up the tick count but it didn't really get us anywhere. We have also gone into more detail on the Wireless stuff and tried removing the drivers and zero config. The system became a bit more stable but some units still fell over.

We have now changed from the CE database to an SQLite database and so far it hasn't fallen over. It has now been running for 5 days without any fall over. We will be more confident if all 8 of our test units running this particular version of code don't fall over after 2 weeks of testing. Fingers crossed we have solved our little problem all by our selves.

Thank you to the developer who pointed out to me that the CE database is useless when it comes to running it off of a CF card... All I can say right now is thank goodness for SLQite!!!!

No thanks to Microsoft who were about as much help to me as... um.... an empty water bottle on the London to Brighton bike ride!

Your comment:



 (will not be displayed)


 
 
 
 
 

Live Comment Preview:

 
«November»
SunMonTueWedThuFriSat
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345