Re: WinCE 5.0 RegFlush on Cold Boot

Right. So, you have to multiply by the number of blocks that you expect to
have free in the part. There's no clean way to prevent the flush, *if* it's
the one that I asked about before, from happening, short of getting the
Premium Windows CE source code and reconstructing the Filesys component.
You might be able to arrange to replace one particular function definition,
but, again, you'd have to short-circuit the build of filesys.exe. *Is* it
the one I mentioned previously (yes, you'll have to arrange to get debug
messages)?

You'll also, even if you arrange to do this, have to verify that this
operation is not *required* to properly maintain correct registry
information in the hive. Microsoft has carefully added that flush *only* in
this one case, which suggests to me that it's intentional and needed (and
they only flush HKEY_LOCAL_MACHINE, not HKEY_CURRENT_USER, again, indicating
that something specific is in their minds, I think).

Paul T.

"Peter K" <anonymous@xxxxxxxxx> wrote in message
news:udvkzmXfIHA.2448@xxxxxxxxxxxxxxxxxxxxxxx
If you do take the worse case of erasing and then writing to a block once
per second it would take:

1000000 / (60 * 60) = 27.77777 hours (just over a day) to wear out a
block.

even once every 10 seconds

(100000 / (60 * 60)) * 10 = 277.7777 hours.

I know that this is not what is happening and I'm sure this registry flush
at boot would not wear out a flash block for years. But like I mentioned
this has become a focus for others and I would like to stop the OS from
doing the flush at boot.

From my log files the RegFlush performs 1017 writes to the flash for a
total of 210635 bytes written and one block erased. That is one sector
(not always the same one with the wear levelling) of flash written and
erased on every boot for no reason.

"<ctacke/>" <ctacke[at]opennetcf[dot]com> wrote in message
news:ep4irNXfIHA.968@xxxxxxxxxxxxxxxxxxxxxxx
Typical flash life is > 100,000 writes in a sector. If we assume that
wear-levelling isn't used (and it is) then even if they restarted the
device once every second, 24 hours a day, 7 days a week, it would still
take over a year to fail. Most devices I know of can't boot in under 10
seconds, so that means if you cycled it as fast as the device allowed
constantly it would still last a decade before you had a failure.

And still, a failure is most likely to just cause the bad sector to be
quarantined and no longer used, and your FSD would then start writing to
another sector for the next decade.

I'm thinking you might want to spend your time worrying about other
possible failures. What happens if power is cut while any write
operation is happening? There's a lot more risk there than what you're
looking at now.


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com



"Peter K" <anonymous@xxxxxxxxx> wrote in message
news:eIqku5WfIHA.5280@xxxxxxxxxxxxxxxxxxxxxxx
I would have to load a debug image and look for the messages you have
mentioned.

I am sure that the periodic flush is not enabled, this was one of the
first things I looked for when I saw this behaviour.

Our devices are Data Terminals in Taxi cabs and they cold boot every
time. There is some concern that the extra writes to the flash may cause
premature failure to flash blocks in the device. So the many writes to
the flash at boot up has become a focus. I am sure that 1 or 2 boots a
day would not be a problem, but user will try all sorts of things to
cheat a system and one of them is rebooting the device.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message news:unLGJsWfIHA.536@xxxxxxxxxxxxxxxxxxxxxxx
Is there a debug message associated with the registry operation?
Something like "Finalizing registry", for example, maybe just before
the "This device has booted <x> times" message? You're sure that you
don't have the periodic flush thread enabled?

On the assumption that this *is* the intended behavior, what problem is
it causing for you?

Paul T.

"Peter K" <anonymous@xxxxxxxxx> wrote in message
news:Os0FiYWfIHA.5996@xxxxxxxxxxxxxxxxxxxxxxx
I'm using RAM and ROM File System. The nk.bin is loaded into flash
above the bootloader and is XIP.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message
news:OND4HXWfIHA.4728@xxxxxxxxxxxxxxxxxxxxxxx
What filesystem type are you using, RAM/ROM or ROM-only? How is
nk.bin loaded? Flashed into linear flash? Loaded by the bootloader
into RAM from somewhere?

Paul T.

"Peter K" <anonymous@xxxxxxxxx> wrote in message
news:eJJh$SWfIHA.4144@xxxxxxxxxxxxxxxxxxxxxxx
Paul,

I have 2 volumes on the device, one that is bootable and hidden
where the Hive registry files reside and the other for file storage.
The debugging I added shows which volume is being written to.


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no
spam DOT com> wrote in message
news:%23aBmeMWfIHA.2448@xxxxxxxxxxxxxxxxxxxxxxx
How do you know that the command corresponds to a registry write?
It's a hive registry. Any write to the 'disk' would generate some
writes.

Paul T.

"Peter K" <anonymous@xxxxxxxxx> wrote in message
news:%23kWImBWfIHA.5280@xxxxxxxxxxxxxxxxxxxxxxx
Hello,

I have a WinCE 5.00 OS with IPSM 4.0 set up with Hive Registry,
does anyone know how to stop the OS from backing up the Registry
on a cold boot. I believe that it is doing a RegFlushKey when it
update the BootCount in the registry but I can not find any
reference to this in the OS source code.

I have check all my device drivers to see if any of them might be
calling RegFlushKey and they are not.

The reason I know that there is a backup of the registry at boot
up is because I added debugging in the OALIoCtlPsmFlashCmd
function to show when writes and erases occur in the IPSM.

Thanks for the help



















.

Relevant Pages

  • Re: WinCE 5.0 RegFlush on Cold Boot
    ... the highest risk when using flash is full corruption due to power ... I know that this is not what is happening and I'm sure this registry flush ... at boot would not wear out a flash block for years. ... constantly it would still last a decade before you had a failure. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: WinCE 5.0 RegFlush on Cold Boot
    ... I know that this is not what is happening and I'm sure this registry flush ... at boot would not wear out a flash block for years. ... a failure is most likely to just cause the bad sector to be ...
    (microsoft.public.windowsce.platbuilder)
  • Re: WinCE 5.0 RegFlush on Cold Boot
    ... Typical flash life is> 100,000 writes in a sector. ... Our devices are Data Terminals in Taxi cabs and they cold boot every time. ... Something like "Finalizing registry", for example, maybe just before the ...
    (microsoft.public.windowsce.platbuilder)
  • Re: WinCE 5.0 RegFlush on Cold Boot
    ... flash chips to avoid repeatedly writing to the same sectors. ... I suppose that, item 2, you could use a RAM-based registry, which I don't ... Paul T. ... Our devices are Data Terminals in Taxi cabs and they cold boot every time. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: File System
    ... Is there any way to ask the PM not to flush registry upon suspend? ... I found that the time is spent doing read, write and flush to flash. ... program/erase flash while suspending. ...
    (microsoft.public.windowsce.platbuilder)