Fix: time stamp mismatch on celog.rel

Posted by: Sue Loh 

Posting a full explanation of this error from CE 5.0.

Error: Mismatched time stamp on .rel file for module celog.dll requesting
kernel fixup.  Valid .rel file is required for kernel fixups.

It happens if you set the IMGCELOGENABLE build option (“enable event tracking during boot”), use some of our remote tools, and try to make an image again.

When you connect the CE5 Remote Kernel Tracker or Remote Call Profiler to a device, the tool copies celog.dll from under c:\program files\common files\microsoft shared\windows ce
tools\platman\target (I’m not sure if it’s under wce500 or just directly under target, sorry) to your release directory, regardless of whether there’s already a celog.dll there or not.  If you already had celog.dll and you were including it into your image with IMGCELOGENABLE, then the problem is then that celog.dll and celog.rel in your release directory don’t match.  celog.rel will be from your old build of celog.dll while celog.dll will be from the platman target directory.  celog.rel is used to figure things out about the DLL when putting it into the “MODULES” section during makeimg.  So your options are:

  1. If you don’t need to collect CeLog event tracking data during boot, then turn off IMGCELOGENABLE.  You can still connect Kernel Tracker without having that variable set.  Unsetting that variable will remove celog.dll from your image and get rid of the makeimg error.

  2. Setting IMGCELOGENABLE starts collection really early in boot, before most of the kernel and file system initialization.  If you don’t really need it that early, but still want to collect data for what happens during boot after the kernel and file system are initialized, do this:


    2. Look at common.bib and common.reg to see what those variables do.  Copy those settings (perhaps to platform.bib and platform.reg), except make sure that celog.dll is in the FILES section instead of the MODULES section.  Putting celog.dll into MODULES makes it load automatically really early, and makes it require the .rel file.  Moving it to FILES means that something else will have to load it — probably CeLogFlush.exe, which is where the IMGAUTOFLUSH settings come in.  Changing it from MODULES to FILES gets rid of the requirement for the .rel file, and will get rid of the makeimg error.

  3. If you really want to set IMGCELOGENABLE in order to get early boot data, then rebuild your own celog.dll so that it matches the .rel file.  You can do a full rebuild (sysgen) to get it, but the quick version is:

    1. From the Build menu click “Open Release Directory”

    2. Type “sysgen celog” to rebuild celog.dll from the command line.

    3. Verify that the timestamp on celog.dll and celog.rel now match

    4. Now you should be able to make an image

    5. Note that every time you connect Kernel Tracker or Call Profiler it’ll overwrite this file.  You can also copy your newly rebuilt file to the platman\target directory listed above, so that Kernel Tracker / Call Profiler use YOUR build of celog.dll which matches celog.rel.

This problem is fixed in CE 6.0; Kernel Tracker and Call Profiler will use the build of celog.dll from the platman\target directory without overwriting the file in your release directory.


NOTE: this post is specifically about the mismatched timestamp error on celog.dll, not on other modules.  If you are getting this error on some other module then you’ll probably have to do your own debugging to figure out why the .rel file doesn’t match.  You will probably have to rebuild the module or take it out of the MODULES section of your image in order to get around the error.


Comments (3)

  1. Rui says:

     Sue, I know this is not a correct way to post a file system question here, but all the file system threads are not accepting comments anymore. So I have to post it here. I know you are the expert to deal performance.

     My question is:

     How to improve the performance to read large files with 2 pointers?

     This comes as a requirements when we deal with large media files that have audio and video data that are not interleaved. As a result, we need to have 2 positions to read video and audio data.

     One way is to seek back and forth, how the performance is really awful.

     We’ve been trying otherways like to create 2 file handles (both by using CreateFile or CreateFileForMappings) for audio and video respectively. And it didn’t improve the seek schemem much either. It seems that the underlying filesystem is really inefficient in dealing this kind of situation.

     Is there any effectively method that we can deal this with decent performance?

  2. ce_base says:

    The more I think about my answer, the bigger of a reply it becomes, but here’s the short version.  Maybe I or someone else on the file system team will post a new blog entry with a more complete description of file system caching soon.

    I am assuming you’ve already read Ariane’s post,

    For spinning disks, you want to lay out the file sequentially on the disk and then read a whole bunch of it all at once, to minimize seeks.  For flash, organization doesn’t matter much, and as long as your reads are in increments of the block size, you don’t get much benefit from larger reads.  But for both cases, if you’re just reading once then you might want to consider turning off any caching that could be going on, by setting FILE_FLAG_NO_BUFFERING.  If you’re not reading constantly (if you’re reading in multiple bursts instead) you can probably get a performance gain by doing some read-ahead in the background.

    Ideally the file system would be set up to recognize your access pattern and do the read-ahead for you, but so far we don’t have anything that sophisticated yet.  I recommend using 2 handles so that someday when we do have something, it’s easier for a simple algorithm to figure out that these are 2 sequential reads instead of one read that randomly skips about.  It can’t hurt to set FILE_FLAG_SEQUENTIAL_SCAN either, though that won’t change anything today.  (Unfortunately the FILE_FLAG_NO_BUFFERING will probably get in the way of that flag, but FFNB is what will benefit you today.)


  3. Rui's friend says:

    Do you mean if I set FFNB, the underlying buffers in FAT filesystem of WinCE will be disabled?

    I’m wondering why the seek operation hurt the throughtput so much. In my understanding, the seek implementation is very simple in file system, maybe it will cause FAT buffer flush for subsequent file read. Is that correct?  If it’s true, how can I use different internal buffer chain for different file position? I’ve tried open the same file twice and operation on the two handles individulally, but no performance gain. Any suggestions?