WinCE

The usual bootup time for the development board was around 30-35 seconds, but as we were adding new drivers , the bootup time went up by minutes. The booting was really slow. So I took up this issue.

As i analyzed the booting up process, it was clear that the Boot phase 1 (loading of FMD) was getting over without any hickups. And slow down seems to have been occuring while drivers are getting loaded and initialized.

We can follow two strategies for pin pointing this issue:

Remove each driver one-by-one.
If we are not clear with the source of the problem, then individually eliminating each component one-by-one and observing the behaviour is a straight forward but time consuming way.

When you are debugging on a standalone system (i.e. which is not connected to platform builder, using corecon), you may need to get the celog CLG file and review the performace data for the session in Kernel Tracker. 

But the file which you are getting will not have the thread information, it will only have the identifiers for each thread instead of the names. The names of the thread can be acquired using the Readlog utility. First copy the CLG file you obtained from the system into the build release directory and execute the following command :

Fixing Thread Names With Readlog (http://msdn.microsoft.com/en-us/library/aa935935.aspx)

Its one of the most helpful tools that I have used in WinCE BSP development. Celog is an event-tracking tool that logs a set of predefined ( I think configured or filtered would be an apt word) for this) CeLog collects the data given by various sources such as applications or drivers in a location configured in registry.

Using tools such as CeLogFlush.exe, we can periodically collect the data and can be analyzed in a development workstation.

A Special Thanks to Sue Loh, for posting a really helpful and detail documentation in her blog in MSDN for using CeLog along with tools such as kernel tracker.

While working on the wrist pc project, we were experiencing some unexpected slow of system while booting up and running applications and we were pondering in dark just to figure out the cause of the snail's pace performance. Then I came across the tutorial given by Sue Loh in her microsoft blog on using CeLog on a standalone machine.

Previously I had used Remote Kernel Tracker, which is built into the platform builder for connecting to a development board using CoreCon and use CeLog to gather Kernel Data (such as interrupt, thread switching, events and other information), on a real time basis (well pretty close to real time). But for this the board needs to be connected to over ethernet or serial to a development work station.

Most of the times problems will arise while testing under real scenarios. So debugging such issues, I came up with a solution. I made a CAB file with the following things:

• celog.dll
• celogflush.exe
• ITaskMgr_arm.exe (A free task manager I found in net, http://urana.info/mobile/wince/itaskmgr/index.html)
• oscapture.exe

(Also added shortcuts in start menu to launch the exes too, just for the ease of use)

I distributed this cab file among my team and asked them to install in all the boards that we were using. So at any point of the system is showing any slowness, start the 'CeLogFlush.exe' application, which will periodically dump the performance data on to a file. After significant data is gathered, they can use the ITaskMgr_arm.exe to kill the CeLogFlush flush instance and then take the dumped file.

This file can be opened in Kernel tracker to view the information.

In later posts I will explain in detail about CeLogFlush and other tools for performance monitoring.

Regarding how to analyze the performance data, Sue has put up a detailed tutorial in her blog.