EWF RAM (REG) Help!

  • Thread starter Thread starter lovelyshadeofgreen
  • Start date Start date
L

lovelyshadeofgreen

Hello all,

I have a problem with the EWF RAM / RAM (REG) "thing".
At the moment we have a single image which is remotely deployed to over
500 terminals.
The image is designed with a RAM overlay. This is fine.
However, we noticed the other day that after a period of time the
overlay changes (seemingly by itself) to a RAM (REG) overlay. This is
not what we want and when we re-image the terminal it goes back to a
RAM overlay.
I have searched the web and found on the MS site the registry keys for
enabling RAM (REG).
I checked one of each terminal (a right one and a wrong one) and found
they both have the same registry keys with the same values.
I also checked the FBAlog and it says that the Ewf it has created is a
RAM overlay on both terminals.
I can't find any reason for it to be RAM (REG) and I really want it to
be just a RAM overlay.

Has anyone else come across this problem before and if so how can I
stop it?

Please help!

Thanks,
Lucy.
 
Hi Lucy,

Can you give any more detail about differences in behavior between the two
systems. Using EWF RAM in REG mode basically means that the overlay is
controlled via registry entries instead of the configuration partition (in
classic EWF RAM).

Is there a reason for avoiding the RAM REG mode? It actually makes it easier
in the cloning process.

HTH,
Brad
 
Hi Brad,

I think the main reason we have avoided the RAM (REG) option is because
we didn't know enough about it. I've inherited the image creation job
from someone who left and this was the last one he did and no-one has
really questioned it as it just works.

Am I right in thinking RAM (REG) does basically the same thing as the
basic RAM overlay but controls everything from the registry?

Does this mean that everything should still be fine and the terminals
should still be fairly unbreakable?

We run our software applications from the server and everything is
stored on the d: partition rather than c: on the terminals themselves.
The machines are all turned on and off with the breaker switch not
turned off gradually and we were just worried that the images would
corrupt or things could be changed if it was the wrong partition.

If this is not the case then everything should be fine and we can carry
on regardless.
At least there will be some overlay protection.

If you think we'll be ok please let me know.

Thanks for your help.
 
Hi Lucy,

I think you will be fine using the REG mode. Could you export the following
reg key and copy the contents here so we can see it? The key is
HKLM\System\CurrentControlSet\Services\EWF.

Also keep in mind that if you are logging or writing any data to D: and the
power is lost you still have the possibility of corrupt files there. The
system will still boot as the C: partition is protected but your application
may malfunction if it requires r/w files to be intact.

HTH,
Brad
 
EWF RAM and RAM (REG) modes are basically identical in function, with the
only difference being how the configuration info is stored. RAM mode stores
overlay configuration info in the EWF volume, but RAM (Reg) mode uses the
registry instead, as noted below.

However, the system should not ever spontaneously switch between RAM and RAM
(Reg) modes. If you are able to reproduce this somehow and see that,
between boots (and without any reimaging or registry modification going on),
the system switches between modes, that definitely sounds like a bug we'd
need to fix.

What version of XP Embedded are you using? (SP1, SP2, Feature Pack 2007
CTP?) That'll help us determine the likely cause of the problem.

Thanks.
 
I was able to reproduce the same problem. I ran my FBA and did my EWF (RAM)
setups in a hard disk. After the setups are completed, I typed ewfmgr C: in
command prompt and it displayed EWF RAM. I then transferred the post FBA +
EWF image to my CF card. When I booted up the image in the CF card and
checked the mode, it said RAM (REG)...weird
 
Hi Jim,

Although I haven't tested this directly my first guess would be that EWF is
smart enough to look for the configuration partition and if missing default
to EWF RAM in REG mode. The configuration partition really isn't needed, it
mostly holds information about the state of the filter. As you found, it can
create problems in the cloning process since some utilities skip the
partition because its hidden. Unless there is some weird requirement not to
use REG mode, I would switch to it exclusively.

HTH,
Brad
 
Hello again all,

The registry settings are as follows-The first one is from the one that
has a RAM overlay only-

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EWF]
"ErrorControl"=dword:00000001
"Group"="System Bus Extender"
"Start"=dword:00000000
"Type"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EWF\FBA]
"OVSize"=dword:00000000
"OVLevel"=dword:00000001
"PVConfigs"=dword:00000001
"EwfEnable"=hex(7):31,00,00,00,00,00
"EnableLazyWrite"=hex(7):30,00,00,00,00,00
"PVDisk"=hex(7):30,00,00,00,00,00
"PVPart"=hex(7):31,00,00,00,00,00
"PVDiskType"=hex(7):30,00,00,00,00,00
"PVType"=hex(7):31,00,00,00,00,00
"PVOptimize"=hex(7):30,00,00,00,00,00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EWF\Parameters]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EWF\Parameters\Protected]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EWF\Parameters\Protected\Volume0]
"ArcName"="multi(0)disk(0)rdisk(0)partition(1)"
"CompareBeforeAlloc"=dword:00000000
"Type"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EWF\Enum]
"0"="Root\\LEGACY_EWF\\0000"
"Count"=dword:00000001
"NextInstance"=dword:00000001

The second lot is from the one that has the RAM (REG) overlay -


[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EWF]
"ErrorControl"=dword:00000001
"Group"="System Bus Extender"
"Start"=dword:00000000
"Type"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EWF\FBA]
"OVSize"=dword:00000000
"OVLevel"=dword:00000001
"PVConfigs"=dword:00000001
"EwfEnable"=hex(7):31,00,00,00,00,00
"EnableLazyWrite"=hex(7):30,00,00,00,00,00
"PVDisk"=hex(7):30,00,00,00,00,00
"PVPart"=hex(7):31,00,00,00,00,00
"PVDiskType"=hex(7):30,00,00,00,00,00
"PVType"=hex(7):31,00,00,00,00,00
"PVOptimize"=hex(7):30,00,00,00,00,00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EWF\Parameters]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EWF\Parameters\Protected]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EWF\Parameters\Protected\Volume0]
"ArcName"="multi(0)disk(0)rdisk(0)partition(1)"
"CompareBeforeAlloc"=dword:00000000
"Type"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EWF\Enum]
"0"="Root\\LEGACY_EWF\\0000"
"Count"=dword:00000001
"NextInstance"=dword:00000001

I've had a look through these and I can't find any differences between
the two.
We are using Embedded XP with Service Pack 2 and all the updates.
We send out an image to the machines which has a 5GB C: partition, a
15GB D: partition and a 15GB E: partition on a 40GB disk.
Some are RAM and after some time (few days/weeks/hours don't know when
exactly) some become RAM (REG).
There are no differences between the units (IBM Kiosk terminals) and no
differences between the image - they are all getting the same
image.sdi.
There are also no differences between the software. They are all
receiving the same version of our own apps.
We had this happen once before with some different machines after the
FBA and we reimaged them and they were fine. They have been on site for
some time and I haven't looked at them since so they could have
reverted to RAM (REG).

It isn't a major problem at the moment as so long as we have some
protection to C: then this is fine. D: and E: are only for our software
and the pagefile/event logs and don't need the same level of
protection.

Thanks for everyones help so far!

Lucy.
 
Back
Top