Location of cache file for EWF

[Guest]

I heard it is recommended to locate cache file out of EWF volume. However, if
I locate it on D dirve, it will be difficult to run chkdsk to D drive.
It won't run directly and runs after boot time. However, the setting chkdsk
after boot is canceled by EWF function.
Actually, it won't be possible to run chkdsk at the customer side.

What is the solution for this problem?
Thanks for your help.

 

[KM]

If by "cache file" you meant pagefile, then yes, it is recommended to move it out of the protected volume.

Assuming your drive D is a separate disk in the target hardware from the boot disk.
If you second disk is unprotected, chkdsk will run at the system boot if the dirty flag was set on that drive. It should not do that
again on the next boot if the disk was unprotected (so that the dirty flag can be cleaned and the change is persistent).

 

[Guest]

Thank you, KM.
Yes, I mean cache file pagefile and it is located on the different partition
on the same drive as boot disk.

When I run chkdsk for D drive, system answers it will be run at the next
boot. This setting is actually set to protected system disk. The setting for
the running chkdsk will be lost at the time of the next boot, since it is
written on the protected partition. In other word, the setting of running
chkdsk in the boot sequence won't be written to the system disk.

In order to run it actually, we need to disable the EWF function, but I
don't think it is a good idea to let the customer to turn off EWF.

I'd like to know if there is a good solution for this.
Is there an automated way to do the following process?
1. Turn off EWF (reboot)
2. Set chkdsk -> reboot -> running chkdsk
3. Turn EWF back on (reboot)

I have followed the instruction "EWF Performance Considerations"
http://msdn2.microsoft.com/en-us/library/ms912916.aspx
Especially with following items.

"Changing the Location of the pagefile"
http://msdn2.microsoft.com/en-us/library/ms912851.aspx
Key Name: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory
Management\
Value Name: PagingFiles
Type: REG_MULT_SZ
Data: D:\temp\pagefile.sys 150 500

"Changing the Location of the Temporary Files Folder"
http://msdn2.microsoft.com/en-us/library/ms940828.aspx
1. Modify one or both of the following registry keys on your run-time
image:

Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\Current
Version\Explorer\User Shell Folders
Name: Cache
Type: REG_EXPAND_SZ
Value: D:\temp
- or -

Key:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell
Folders
Name: Cache
Type: REG_EXPAND_SZ
Value: D:\temp

2. You can also redirect the TMP and TEMP folders to an unprotected
volume by modifying the following registry settings:

Key: HKEY_CURRENT_USER\Environment
Name: TEMP
Type: REG_SZ
Value: D:\temp

Key: HKEY_CURRENT_USER\Environment
Name: TMP
Type: REG_SZ
Value: D:\temp

Thanks,
HA

 

[KM]

HA,

I was actually referring to the situation where the chkdisk is launched automatically on disk D:. It may be invoked by autochk if
the dirty bit is set on a disk connected to the system. This may occur, for instance, if you suddenly powered off the machine while
it was flushing data to the disk.
Every time your XPe image starts, autochk.exe is called by the Kernel to scan all volumes to check if the volume dirty bit is set.
If the dirty bit is set, autochk performs an immediate chkdsk /f on that volume. Chkdsk /f verifies file system integrity and
attempts to fix any problems with the volume.

If you want to schedule chkdsk on that drive, it will certainly "program" that in the registry system hive and therefore to make
this change persistent you will have to commit the EWF overlay. However, I am not sure why do you want to allow users to
run/schedule chkdsk on drive D: and don't want to let them to commit EWF overlay? (note, commit but not disable EWF).

Also, you can try to approach your problem in a little bit different way. All you have to do to run the disk check on the next boot
is to set the dirty bit on drive D:.

The way you were setting the disk check was changing the autochk command line run (in bootexecute sequence in registry) to
explicetly run the chkdsk /f by the kernel at boot. It is getting set up in registry. Since the registry is sitting on your
protected disk this approach is conceptually wrong.
There is however another way to set the dirty flag. Just run the following command at run time: fsutil dirty set D: . (assuming you
get the fsutil utility included in to your image config) Since you only changed something (the dirty bit) on unprotected drive D:,
you don't have to worry and commit EWF changes on protected drive C:.

Hope this helps.

 

[Guest]

KM
Thanks a lot.
Actually, this question was raised because autochk does not run after
abnormal shutdown. Does it require special compenent and I missed it for the
build?

Anyhow, I will try "fsutil dirty set D:" and see how it goes.
Thanks,
HA

 

[KM]

HA,

Well, it is not always the dirty bit gets set if a sudden power loss
happened. Only if data flushing was going on at that moment. I guess you can
test it by trying to copy a large file to the drive D: and powering down the
device during it.

Anyway, you may want to check if the autocheck is properly set up on your
image.
[HKLM\SYSTEM\CurrentControlSet\Control\Session Manager],"BootExecute"
registry value should include something like "autocheck autochk *" to scan
all the volumes. All other strings of that multi-string value should not
contain "autocheck /k *".
If you don't change target configuration often, or, perhaps, the all volume
scan is broken on your image for some reasons, it may be a good idea to set
up and force the autocheck for the specified drive D:. E.g., add the
following to the BootExecute string: "autocheck /m \??\D:". This will first
look only at the dirty bit on the volume, and if set, run the chkdsk on it.

And, of course, make sure the autochk.exe is in your image

Regards,
KM

 

[Guest]

KM,
Thanks! It worked.
Actually, [HKLM\SYSTEM\CurrentControlSet\Control\Session
Manager],"BootExecute" registry value was left blank.
I added the instructed value and now it works for the abnormal shut down.
Thanks,
HA