MS:
What does the EWF hotfix Q823025 fix? The download page for this hotfix
states the following:
"This update addresses a potential problem when using EWF on certain
Windows XP Embedded with SP1 runtimes. Certain commands issued through
the EWF API or EWFMGR.EXE do not function properly, possibly causing
blue screen errors. "
Can someone from MS clarify this please? What BSOD's could occur?
Also, could one of the problems fixed be a commit via ewfmgr that
doesn't actually commit?
Hi Doug:
The BSOD problem we tracked and fixed in Q823025 did not result from a
concrete sequence of steps. There were no exact repro steps that led to
the BSOD, and it would occur at different times under different
circumstances.
The commit problem you describe was something else that was fixed with
this QFE. A KB article describing the fixes to EWFMGR is in process and
should be available RSN, but here's some of the content:
1. When you run EWFMGR.EXE and include the -NOCMD switch, the boot command
would not be cleared. Now the -NOCMD switch to EWFMGR.EXE will properly
clear the boot command.
2. When you run EWFMGR.EXE and include the -COMMITANDDISABLE switch on a
system using RAM-based overlays, the overlay would not be committed and
the boot command would not be cleared. Now the -COMMITANDDISABLE switch to
EWFMGR.EXE will properly commit a RAM-based overlay and clear the boot
command.
3. When you run EWFMGR.EXE and include the -COMMITANDDISABLE and/or the
-NOCMD switches on a system using RAM-Registry-based overlays, the overlay
would not be committed and the boot command would not be cleared. Now the
-COMMITANDDISABLE switch will properly commit the RAM-Registry-based
overlay and clear the boot command, and the -NOCMD switch will properly
clear the boot command.
4. When you used the EwfMgrGetProtectedVolumeConfig() API to retrieve the
current status of the EWF overlay, an incorrect status may be returned for
RAM-based overlays. The status returned would not accurately reflect the
effect of issuing a CLEAR or COMMIT command on the overlay. Now the
EwfMgrGetProtectedVolumeConfig() API returns accurate status information
about the volume following all commands issued on the overlay.
5. The EwfMgrRegisterLowSpaceNotification() API allows you to set a
notification event to fire when the free space in the overlay reaches a
certain threshold. If the amount of free space in the overlay was already
past the threshold you set using the EwfMgrRegisterLowSpaceNotification()
API, the event would never fire. For example, if a threshold of 30
megabytes was set, but the amount of free space in the overlay was only 25
megabytes, the event would not fire. Now the
EwfMgrRegisterLowSpaceNotification() API properly fires when the free
space of the overlay exceeds the threshold when it is set.
Hope this helps.
