Analyzing Data Loss With Remote Kernel Tracker (Windows CE 5.0)
If data loss occurs during the event tracking process, Remote Kernel Tracker pops up a small window with a count of lost bytes. However, the popup provides no additional information, such as what data was lost or what was occurring when the data was lost. To be able to identify the data that is lost, it is helpful to study the output of Remote Kernel Tracker, and identify exactly what span of time was lost.
When data loss occurs, the display in Remote Kernel Tracker looks as if interrupts and thread switches suddenly stopped, and one thread took over. While this display does show the actual thread pattern, it does not show the underlying activity that caused it. This pattern occurs when the CeLog RAM buffer filled completely, and new incoming data began to be discarded until space was freed up in the buffer. The thread that happened to be running at the point the buffer filled is shown as if it kept running throughout the period of data loss.
A different pattern is characteristic of data loss that occurs because the RAM buffer is full. The period of data loss shown in Remote Kernel Tracker is always followed by activity in the buffer-flushing process. If the buffer is flushed by RTH.EXE, the device-side component that copies data to Remote Kernel Tracker, then RTH.EXE activity appears after the period of data loss. If CeLogFlush.exe flushes the buffer, then CeLogFlush.exe activity appears after the period of data loss. The Remote Kernel Tracker display, or the CeLog log file, show flushing activity after data loss because a flushing application frees up space in the RAM buffer as it flushes. As soon as space in the RAM buffer is available, CeLog resumes recording events, catching the last part of the flush.
See Also
CeLog Event Tracking Overview | Remote Kernel Tracker | Readlog Viewing Tool
Send Feedback on this topic to the authors