EWF memory leak !

  • Thread starter Thread starter fred
  • Start date Start date
F

fred

Hellou ppl,
Does some1 find a way to keep a system running with the EWF component
more than 3 month without crashing !!!
With a Ram overlay, I test a litle program that simulate 4k log
writing, every .5 sec, in the same file, overwriting the last log
data. The system crash after 4 hours, out of RAM. With 256 Megs.
Then, if we know that conventionnal windows like for any reasons write
log, registries, and any configue file everywhere then we estimate the
living time of the system to 3 month max. And this is after we
eliminate our apps write in running them on a RAM disk.
Are we stuck to buy a system that will have to be rebooted every like
2.5 mouth to be sure or there's a solution.
Be quick we are paying expensive lawers to make a hidden little line
on the sailing contract. lol
 
I'll have a shot at explaining this.

It it not actually a memory leak as such. The EWF RAM overlay starts out
small, and grows as more data is written. If the same data is written more
than once (eg 2 changes to the same registry entry, or writing new data that
is the same size as - or smaller then - the previous size to a file), the
size of the overlay need not increase. The overlay can grow until it is the
same size as the disc it is protecting (no-one has been very clear on what
happens then - it should produce disk full errors).

However, the RAM overlay shares the system RAM with the memory allocated by
the operating system to your aplications and everything else. If your EWF
protected volume is large, and physical RAM is relatively small, long before
the your overlay reaches the size of the volume it will have grabbed all the
free memory. The next thing that wants an allocation of RAM (be it
application or the overlay) will cause an error.

The solutions, as I see it, are 3 fold.

1) Minimise the size of the protected volume. This limits the size that the
overlay can grow to. Non-critcal data can be written to an unprotected
volume on the same drive.

2) Fit as much RAM as your CPU will support. I've run into trouble
regardless of EWF with 128Mb and no page file. 256Mb should be enough, but
it does depend on what you do and how you do it. I'm running a system with
512Mb of RAM an a protected volume of only 100Mb

3) Purge your logs periodically. If you want to keep them do an EWF
commit/Append their contents to some underlying file (perhaps on an
unprotected volume). I'm not sure if the overlay size is reset if you turn
EWF off and on again, or if you have to re-boot (any-one?). You don't say
what your underlying storage is, but writing to something with a limited
life (like CF) once a month should not damage it in your lifetime.

As a last ditch effort a programatic, managed restart is technically
possible (ie the user doesn't have to re-boot when an error occurs - the
device monitors its own free RAM and reboots when it reaches a critical
level). The down side is that your device stops for a minute or so whilst it
is doing it.

Stick with the lawers too - just for safety ;)

Good luck

Simon
 
Fred,
Please join the Windows XP Embedded development team in an online chat
regarding
the Enhanced Write Filter (EWF) and El-Torito in Windows XP Embedded.

This is the Date/Time of the chat:

August 7, 2003
10:00 A.M. - 11:00 A.M. Pacific time
1:00 - 2:00 P.M. Eastern time
17:00 - 18:00 GMT
18:00 - 19:00 BST

http://msdn.microsoft.com/chats/

See you there!
Andy
 
Back
Top