Thread: Using EWF on regular WinXP

it's actually in the Volume0 key, if you notice I removed the volumeid value because apparently it's not necessary for RAM Reg mode according to the MSDN docs. I can't try it out until i get back from school tonight.

Okay, here's the latest: that volsnap filter thing gave me problems, so scratch that. It's just EWF. Don't know why MSDN says to keep it in there. Also, the VolumeId value isn't necessary in the Volume0 key.

Here's the new version of the document incorporating SFiorito's information. Anybody willing to proof read and/or make some suggestions?

PDF
Word doc

I just went over the whole process this morning on my system using a 1G partition on a laptop drive. All works well. The document is accurate. I have those registry settings in a few reg file, so it's as easy as a double-click. I'll post those soon.
I kind of have a EWF Kit going right now with all the reg files, ewf files, and a few batch files to enable/disable etc, just for convenience. I'll zip all of these up and post them soon.

I got too eager and ordered a 1G Lexar 80X CF card yesterday. I'll have it by Monday. I'll be copying my OS partition from the laptop drive to it and testing all of this EWF stuff out. I'll continue to add to the doc.
Keep me posted with your results SFiorito, hopefully it works out straight forward for both os us.

Does anyone know of an application that can tell you how much data has actually been written to a drive. One that won't be tricked by EWF. I want to track exactly how many writes are happening to my CF card.

Here's something interesting. Here are the steps I took. My system is a Hibernate once resume many system with EWF enabled.

1. Create a text file on the desktop.
2. Reboot. The text file is gone.
3. Create the text file again.
4. Hibernate. This saves the new hiberfil.sys which it will resume from from now on.
5. Resume. The text file is still there.
6. Shutdown.
7. Turn on the system. It resumes from the hiberfil.sys file. The text file is still there!
8. Now reboot and hit F8 during the resuming progress bar and select the option to delete the restore information and go to the boot menu.
9. Select the normal startup. The text file is gone!

So it seems like you can hang on to files that would normally be lost due to EWF by freezing the system in that state with hibernate. When you don't want it anymore, reboot, and they will be gone.

This may be handy if you want to try a new app for a few days. Install it with EWF enabled, then hibernate. Resume from that state file over the next few days to try out your new app. If you don't like it, hit F8 on the next resume and kill the restoration data. Voila! You're back to where you were a few days ago.

This means the entire application is stored in memory the whole time, but man, that's so cool!

I tried the same thing with settings in FrodoPlayer. The new settings lasted through all the resumes after I hibernated once. As soon as I deleted the restoration data, it was back to the original settings.

So, is a hibernate once resume many system and HORM system? That's so much easier than typing the whole thing out.

Use the performance log under Admin Tools. Use the write values under PhysicalDisk. Test it by creating and deleting some files with EWF enabled and the values won't register any writes. Then run -commitanddisable -live. Do the same test again and you'll see it write. My CF card should be here Monday so we'll see.

Yeah, HORM is what MSDN uses to refer to hibernate once resume many. It makes sense since the RAM overlay will be saved with a hibernate, but I don't know if you'd want to hibernate every time you shut off since you'll be writing to the CF disk every time.

I think the FrontEnds should have configurable locations for their database files, resume files, etc. Either that or just install it on the external drive.