Partager via

Fix: time stamp mismatch on celog.rel

  • Article

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:
    1. Turn off IMGCELOGENABLE and IMGAUTOFLUSH.
    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

  • Anonymous
    February 06, 2007
     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?
  • Anonymous
    February 07, 2007
    The comment has been removed
  • Anonymous
    February 07, 2007
    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?