Hi again Guenter. After some more thought on the matter, I think I
understand what's going on here.
When you have Reg Filter running (which necessarily means that EWF is
enabled *), Reg Filter applies changes to the system registry on each boot
based on the modifications made to the keys it's setup to monitor.
Basically, the version of the registry on the protected partition is the
version that was there when EWF was first enabled (or since the last full
commit), and any changes to the monitored keys are applied after boot (and
exist in the EWF overlay). Reg Filter stores these changes in a separate,
fixed-size file which gets committed on each shutdown.
Let's assume that you've configured Reg Filter to monitor the registry key
that governs CHKDSK's scan on next boot. The problem you're most likely
running into here is that when you direct CHKDSK to schedule a scan on the
next boot, the registry change for this action is stored in the RegFilter
"changes" file, but not directly in the registry, and the system reads that
portion of the registry before RegFilter is initialized (and can apply its
changes). That would explain why you can see the scheduled scan in the
registry, but it does not actually take place.
When you manually edit the registry and commit the overlay, but do not
disable EWF, the registry will contain the scheduled scan, but EWF (which
starts before RegFilter) will catch the removal of the scan instruction,
thus keeping it from being committed to the registry. That would explain
why the scan occurs on each subsequent boot in this case.
The solution to this problem is to ensure that you commit and DISABLE EWF in
the same step (ewfmgr c: -commitanddisable), such that the overlay and your
registry changes are committed and the overlay is disabled on the next boot.
This is also important because otherwise, any changes CHKDSK makes to the
file system during its scan will be stored in the EWF overlay rather than
committed to disk - this is both costly to the overlay (especially for a RAM
overlay) and does not achieve the desired results.
After the scan is completed, enable the overlay again and reboot to continue
protecting your partition.
* Note: Reg Filter doesn't do anything when EWF is disabled.
--
Matt Kellner (
[email protected])
SDET, Windows Embedded Group
This posting is provided "AS IS" with no warranties, and confers no rights.
===============================
Guenter said:
Hi Konstantin,
I found it. The regsitry filter component is preventing chkdsk from doing
it's job. When i change HKLM\SYSTEM\CurrentControlSet\Services\Regfilter
from
1 to 2 then chkdsk works in all it's variants as expected. This means of
course that I changed the Regfilter-StartupMode from System to Automatic
which then means, that Regfilter doesn't do it's job anymore.
I think MS should fix this tiny bug, but I have doubt, that it's possible
for me to convince them*g*.
--
GG
KM said:
Hi Guenter,
Let me back up a little bit and ask you the question Matt has already
asked you. How are you committing EWF overlay?
Can you disable EWF, reboot and then perform "chkdsk" test again
(schedule the autocheck)?
Also, when you see the value "autocheck autocheck /p \??\C:" set in
registry, does it have small or capital "/P"? Should be the
capital one (
http://support.microsoft.com/?kbid=218461).
Not sure what the /r switch you used when you set up the key manually.
=========
Regards,
KM
Hi Konstantin,
The job gets scheduled but isn't comitted properly. The registry key is
filled correctly with "autocheck autocheck /p \??\C:", but nothing
happens on
system restart. The registry key remains. The system still thinks that
checkdsk is scheduled. When i manually change the key to "autocheck
autocheck
/r \??\C:" chkdsk occurs on system restart, but now forever. The
registry key
remains. At the time I have now Idea how to solute the problem.
Regards,
Gunter
:
Guenter,
You can easy verify if the job gets scheduled and the change is
committed properly.
Instead of reboot the device, shut it down. Open its system registry
hive and check the key
[HKLM\SYSTEM\CurrentControlSet\Control\Session Manager],"BootExecute".
