Hard shutdown in XP Embedded

[Guest]

Hi all,

I want to know if we can implement hard shutdown (switching power off) in XP
embedded using windows RAM Disk driver so that the system can have a safe
switch off with out causing any harm to the OS running and hard disk in case
if boot option is selected as hard disk.

Regards
Roshan.

 

[Sean Liming \(eMVP\)]

The best solution is to use EWF (RAM or RAM REG overlays) or FBWF. They
protect the harddrive with all writes being sent to RAM.When you power off
the system everything in RAM is going.

If you need to save information to the disk duing normal operation, FBWF is
the way to go. There is some architecting that needs to be done, but this is
what XPe was made for.


Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
XP Embedded Book Author - XP Embedded Advanced, XP Embedded Supplemental
Toolkit

 

[Guest]

I have tried to use FBWF in this scenario. Unfortunately, I write data to the
registry during normal operation, so the registry file needs to be
unprotected. Also unfortunately, from experience, it is the registry file
that is most often corrupted during a reboot, meaning that in my situation
FBWF is still not fool proof. I could not find a way to protect (or
unprotect) individual branches within the registry.

John

 

[KM]

John,

The best if you move all your important registry updates to some files. If you happen to have source codes of your embedded apps
then you can certainly do that. But if you don't have it, it may be a problem.

Also, how about using EWF and protect the entire system partition including registry hives. Then, if you feel the changes need to be
persistent, you can set up EWF commit launched automatically (HKLM\...\Run key, for instance) and that will commit all the session
disk changes at graceful shutdown. If no graceful shutdown performed (e.g., sudden power loss and etc.), the image will lose all the
changes, since they are not committed to the disk, but you still have working disk with valid data on it (current to the previous
session, though).

 

[Guest]

Thanks for the response,

John,

The best if you move all your important registry updates to some files. If you happen to have source codes of your embedded apps
then you can certainly do that. But if you don't have it, it may be a problem.

Yes, This seems to be part of the solution, however with my coding hat on it
appears messy to me (I thought the registry was supposed to be for this type
of data)

Also, how about using EWF and protect the entire system partition including registry hives. Then, if you feel the changes need to be
persistent, you can set up EWF commit launched automatically (HKLM\...\Run key, for instance) and that will commit all the session
disk changes at graceful shutdown. If no graceful shutdown performed (e.g., sudden power loss and etc.), the image will lose all the
changes, since they are not committed to the disk, but you still have working disk with valid data on it (current to the previous
session, though).

Unfortunately we have been using flash cards that do not appear as fixed, so
have been unable to implement EWF (cannot create multiple partitions). Also
as we are continuously collecting data, the time required for a reboot to
commit changes means a loss of coverage that would be unacceptable. We also
have to write to the registry as components of the system are installed (and
the executables registered) based on the enviroment the system finds itself.


I suspect that the solution is going to be a mixture of the above (FBWF with
registry protected, data files for changing data that is required by the app
after a sudden reboot, Automatic installers that do a commit and reboot after
an install (we particularly wanted to avoid this step but it seems
unavoidable) and using a flash card that appears as fixed (transcend appear
the best option we have seen so far).)

It all adds up to a fairly substantial set of changes, and means that our
system will no longer be backwards compatible. We either bite the bullet and
go forwards, or live with the occasional failure caused by hard reboots.
There is no current evidence that the above solution would result in a
substantially more robust system. We have found in tests that failures are an
order of magnitude more likely to be caused by faulty flash cards than any
other cause (i.e. flash cards that appear to have degraded performance from
the outset) (we have tried several types).

John

 

[Andy Allred [MS]]

Hi Roshan,
From quickly just scanning through the thread it appears you're a good
candidate for also using Registry Filter in conjunction with FBWF. It
was thoroughly tested for two very specific scenarios as indicated in
the documentation but has been sanity tested on many keys and works for
most OEM's scenarios.

If you haven't looked into it yet, this might be a lot of help to you so
you can continue to protect the the hives yet still persist the keys of
interest to your application or scenarios.

Here's a blog article on how to leverage it outside it's normally
documented usage:
http://blogs.msdn.com/embedded/archive/2006/11/19/registry-filter-tips.aspx

Here's the msdn doc page:
http://msdn2.microsoft.com/en-us/library/aa940857.aspx

 

[Guest]

Thanks Andy,
I could not find this information when I was trying to set up my tests and
so did not use the registry filter.

From my point of view, the registry filter would be useful if:
1: you could set whole branches of the registry to be write through (or
protect whole branches).
2: Commiting any changes required (eg registering interfaces or classes)
without having to reboot the machine.

Are either of these possible at the moment?

John