Jack W. Crenshaw has written an article for Embedded.com which is titled “Time to re-evaluate Windows CE?” – Jack looks at a specific API, GetTickCount( ); which returns an unsigned int, this value is incremented every millisecond. The unsigned int can stand to be incremented 4,294,967,296 times before it rolls back around to zero. That's equivalent to:
4,294,967.296 s = 71582.78827 min = 1193.046471 hr = 49.7103 days
The article asserts that GetTickCount could be the cause of operating system crashes, which in turn could cause problems for an embedded system based on Windows CE.
I think this issue is pretty well documented. The general Win32 documentation is pretty clear about the use of GetTickCount, and the Windows CE 5.0 documentation also contains information about the rollover. Windows CE does have API’s like SystemTime which can be used as a absolute value as well as the SystemTimeToFileTime() apis if you want to convert it to a 64 bit value.
Information about GetTickCount( ) can be found in the Microsoft Product Support Knowledge Base
Interestingly, if you build a debug Windows CE operating system image the return value for GetTickCount( ) is set to roll over within the first two minutes of running the operating system, this of course gives you, the developer, the chance to debug your applicaiton on the operating system under the rollover condition (which is much better than waiting 49.7 days!).
Is this an issue – potentially, yes, this could be as much of an issue as not testing the return values from memory allocations, getting a null pointer and trying to use the memory – if you understand the issue, and test for the condition then you don’t have a problem.