We are getting into the fine details of how we want our EWF Disk overlay
protected XPE system to work. Basically I am trying to protect my XPE
volume from corruption when the device is not shutdown correctly. The EWF
for C: drive is enabled.

So, when the device boots, I was calling the following:
ewfmgr c: -Restore

So that if anytime the power is pulled from the unit, the default action was
going to be to restore it. But if the user indicates that he wants to
shutdown nicely, then I execute
ewfmgr c: -NoCmd
which essential means we want to retain the changes on the disk overlay.

1) That sounded like a good plan until someone asked "Does the EWF commands
execute on shutdown or reboot?" I don't know. If the execute on shutdown,
and the power is pulled - they never get a chance to execute. But if they
execute on startup - then it may work.

2) Then another question from the group came up - what happens if an active
overlay becomes corrupted? Is that even possible? What happens?

Thanks,
Scott

I did a little more testing... and it appears the EWF commands execute on
startup. But if anyone can confirm this I would appreciate it.

Thanks,
Scott

Hi Scott,

You are asking similar questions for third time.

Using 1GB for disk overlay can mean only two things:
1. You know exactly what you are doing. (In this case you would not ask so
many questions)
2. Your design is probably bad, and you should probably think some other
solution.

In your first post you have divided disk in three parts, that is ok.

Keep all your binaries in protected partition.
Keep all your application data in unprotected partition.
Use RAM EWF.

If it is impossible to configure application to use such division, only then
you need to make such solution that you propose.

Answer to this questions:
1. Does your application change registry every time XPE is started?
2. Do you need access to write to protected partition?
3. If you need 1 or 2, is it acceptable to commit EWF and restart device?

If you can make positive answer to all three questions then you can use RAM
EWF protection, and stop worrying.

I must say that I don't use disk based overlay.

> 1) That sounded like a good plan until someone asked "Does the EWF
commands
> execute on shutdown or reboot?" I don't know. If the execute on
shutdown,
> and the power is pulled - they never get a chance to execute. But if they
> execute on startup - then it may work.

Commit must execute after the FS dirty flag bit is cleared. That means after
the file system is unloaded (during shutdown). MS could implement this
differently but then every time you start device XPE would try to scan for
errors because FS was not closed properly.
Other commands are irrelevant to you.

> 2) Then another question from the group came up - what happens if an
active
> overlay becomes corrupted? Is that even possible?

Everything possible:
HDD bad block for example.

> What happens?
Use your imagination


Best regards,
Slobodan

Hi Scott,
> I did a little more testing... and it appears the EWF commands execute on
> startup. But if anyone can confirm this I would appreciate it.

True, but little more testing, would not hurt.

Try for example commit.

What about that command?


Slobodan

Slobodan,

Sorry to keep repeating myself - I don't mean to. The answers/questions may
seem obvious to you and may not even make sense - but to me they are new and
fresh... :-)

Oh well...let me try an clarify things..

- Since I have a ton of disk space and only 128meg RAM (for the # of apps
running - it isn't much), it seemed like using a DISK overlay was the way to
go. And since I have so much disk, I decided "1 gig" was a nice easy number
for me to remember. In a few testing cycles, my overlay never got above 0.7
% usage - so I think 1gig is certainly overkill - but that is just what I
started with. I didn't really see any downside to it.

- I avoided RAM overlay because I DID NOT want to loose the OS changes -
unless I have to loose them. Does that make sense? In other words, with the
RAM overlay - if I DO NOT committ the changes before a shutdown, then I
loose them. For me and my application, I would rather keep changes on an
overlay until the overlay because bad and then I throw them all away.

To answer your specific questions.

1. Does your application change registry every time XPE is started?
Answer: No

2. Do you need access to write to protected partition?
Answer: Yes. If the user changes the IP address of the machine (stored in
the protected partitions registry file), then I need for it to stick on the
next reboot.

3. If you need 1 or 2, is it acceptable to commit EWF and restart device?
Yes - as long as I can be 100% that the committing of the RAM EWF will occur
without corruption. What happens if the OS is in the process of committing
the RAM and power is turned off? Bad things? Good things? Who knows.

After reading your helpful responses, and given the problems I am having
with cloning the drive, I will probably try a RAM overlay and add in some
code to the Shutdown Script so that it commits the RAM overlay on shutdown.

By the way - do you know what happens when the RAM overlay is full? I think
I read that any new changes are thrown away. True?

Thanks for your continued support. I'll try not ask the same questions
again. :-)

Scott

"Slobodan Brcin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi Scott,
>
> You are asking similar questions for third time.
>
> Using 1GB for disk overlay can mean only two things:
> 1. You know exactly what you are doing. (In this case you would not ask so
> many questions)
> 2. Your design is probably bad, and you should probably think some other
> solution.
>
> In your first post you have divided disk in three parts, that is ok.
>
> Keep all your binaries in protected partition.
> Keep all your application data in unprotected partition.
> Use RAM EWF.
>
> If it is impossible to configure application to use such division, only
then
> you need to make such solution that you propose.
>
> Answer to this questions:
> 1. Does your application change registry every time XPE is started?
> 2. Do you need access to write to protected partition?
> 3. If you need 1 or 2, is it acceptable to commit EWF and restart device?
>
> If you can make positive answer to all three questions then you can use
RAM
> EWF protection, and stop worrying.
>
> I must say that I don't use disk based overlay.
>
> > 1) That sounded like a good plan until someone asked "Does the EWF
> commands
> > execute on shutdown or reboot?" I don't know. If the execute on
> shutdown,
> > and the power is pulled - they never get a chance to execute. But if
they
> > execute on startup - then it may work.
>
> Commit must execute after the FS dirty flag bit is cleared. That means
after
> the file system is unloaded (during shutdown). MS could implement this
> differently but then every time you start device XPE would try to scan for
> errors because FS was not closed properly.
> Other commands are irrelevant to you.
>
> > 2) Then another question from the group came up - what happens if an
> active
> > overlay becomes corrupted? Is that even possible?
>
> Everything possible:
> HDD bad block for example.
>
> > What happens?
> Use your imagination
>
>
> Best regards,
> Slobodan
>
>

Hi Scott,

> Sorry to keep repeating myself - I don't mean to. The answers/questions
may
> seem obvious to you and may not even make sense - but to me they are new
and
> fresh... :-)

No need to be sorry, but this info you gave would be helpful before.

> - I avoided RAM overlay because I DID NOT want to loose the OS changes -
> unless I have to loose them. Does that make sense? In other words, with
the
> RAM overlay - if I DO NOT committ the changes before a shutdown, then I
> loose them. For me and my application, I would rather keep changes on an
> overlay until the overlay because bad and then I throw them all away.

Well it make sense. But if only thing you need is to change IP, and probably
some other minor settings.
Consider remembering those settings in unprotected partition in some your
config file.
And every time while starting XPE set those changes. So this way you don't
need to commit at all, and you are very safe. If you lose your config you
can always create new one.

Or when you change IP settings, call commit, and when you finish all
settings restart your device.

> 1. Does your application change registry every time XPE is started?
> Answer: No

Excellent.

> 2. Do you need access to write to protected partition?
> Answer: Yes. If the user changes the IP address of the machine (stored in
> the protected partitions registry file), then I need for it to stick on
the
> next reboot.

Make some app that will allow user to change IP, and that will commit
change.
Or that will save change in some file.

> 3. If you need 1 or 2, is it acceptable to commit EWF and restart device?
> Yes - as long as I can be 100% that the committing of the RAM EWF will
occur
> without corruption. What happens if the OS is in the process of
committing
> the RAM and power is turned off? Bad things? Good things? Who knows.

Who knows, but this to happen is bad luck nothing more.
This is part of a second, and if in this time you lose power then you are
really out of luck.
Registry is protected with some redundancies, but this is not enough to be
100% certain that everything will be ok.

> After reading your helpful responses, and given the problems I am having
> with cloning the drive, I will probably try a RAM overlay and add in some
> code to the Shutdown Script so that it commits the RAM overlay on
shutdown.

Don't commit it every time, just when you reconfigure your device.

> By the way - do you know what happens when the RAM overlay is full? I
think
> I read that any new changes are thrown away. True?

This is probably when you run out of memory from nonpaged pool.
Don't know I newer saw more that 300Kb memory usage from EWF.
But I use minlogon, and very small image. So I don't have many interested
parties for accessing disk or registry.

Slobodan

Slobadan,

Great suggestion on just having my apps set the IP address on restart. That
way I don't ever have to committ the RAM overlay.

Thanks,
Scott