Different behaviour of EWFMGR vs EWFAPI commands?

[Bila]

Hello all,

I am trying to acchieve the same functionality of EWFMGR, but with
programmatical aproach using EWFAPI, where the functionalities are
exposed through a GUI. To me it seems that it should be possible to
reproduce many, if not all, commands exposed by EWFMGR by using EWFAPI,
but at the moment I am having problems with this.
In first step I only have the need to reproduce ENABLE, DISABLE and
COMMIT & DISABLE functionlities of EWFMGR.
Now, the problem I faced here is that with EWFMGR it is possible to
issue the boot commands for one volume many times (during one session,
no reboot), disregarding in which state the volume currently is. I am
unable to get the same bhaviour in EWFAPI.

Example (using EWFMGR): lets assume volume D is used and its current
state is DISABLED. It is possible to call "EWFMGR d:/ -enable" then
"EWFMGR d: -disable" and "EWFMGR d: -commitanddisable" consecutively
and each time the command will succeed and the boot command will be set
accordingly (note that the machine is not rebooted between commands).
Now, if I try to acchive the analogous functionality in EWFAPI by
calling "EwfMgrEnable(hProVol
)" then "EwfMgrDisable(hProVol, FALSE)" and "EwfMgrDisable(hProVol,
TRUE)", only the "EwfMgrEnable" function will succede and all others
will fail (GetLastError() returns 87, MSDN states:
ERROR_INVALID_PARAMETER). This is obvously not the same behaviour as in
EWFMGR.

Situation is the same even if the volume is in the ENABLED state: all
EWFMGR commands (from previous example) succeed, but in EWF API now
only the "EwfMgrDisable(hProVol, TRUE)" is succesfull, all others fail
with the same error.

Bottom line is, in EWFMGR it is possible to issue any command,
regardles of the volume's current state, while this is not he case with
EWFAPI.
My question is: why is this so? Is this by design? Am I missing
something (I tried using "EwfMgrClearCommand" function before issuing
any new command, but it does not work for RAM REG mode protected
volumes, just like stated in the documentation)?

I believe it is usefull to mention the EWF configurations: there are
two protected volumes (system and data, drives C: and D: respectively)
using RAM REG mode. Both volumes are located on a flash drive. WinXPe
SP2 is installed.

If required, I will provide my code (it is basically the same code as
in EWF API samples only with minor design modifications). In runtime,
the EWFAPI.dll used is dated april 11th, 2003, version 2.0.1900.0, size
7680 bytes. Library file used for linking (ewfapi.lib) also dates from
april 11th, 2003, size 6758 bytes.

Thank you in advance.

Kind regards,
Bila

 

[Matt Kellner [MS]]

Hi Bila. There is an updated EWF API available in the Feature Pack 2007
download, available from the Microsoft Connect site. It's possible that
this updated API may fix some of your problems.

Also, it's possible that some portion of the communication between your
application and the EWF API isn't being completed properly - are you leaving
a connection open after issuing the first command? If so, the API may be
rejecting additional commands simply because the first one wasn't closed. I
unfortunately don't know enough about the API to be able to guide you more
specifically.

 

[Bila]

Hi Matt,

There is an updated EWF API available in the Feature Pack 2007
download, available from the Microsoft Connect site. It's possible that
this updated API may fix some of your problems.

OK, I have downloaded the Feature Pack 2007. I see that there is
"Updated EWF API" step. I copied the new "lib" and "h" files and built
my tool with them. However when I run it, the behaviour is the same.
This leads me to another question: if there is an updated interface (h)
and a new import lib for EWFAPI, shouldn't there be a new EWFAPI.dll
too? If there is one, where can i find it? Do I need to install
something else from this feature pack, like "tools update"?

Also, it's possible that some portion of the communication between your
application and the EWF API isn't being completed properly - are you leaving
a connection open after issuing the first command? If so, the API may be
rejecting additional commands simply because the first one wasn't closed.

Could be, but I really do not know where as all the functionality
consists of only three functions called in a sequence, once for each
command being issued. Here is a code snippet:

// open handle
hProVol = EwfMgrOpenProtected(wstrName);

// check if handle is valid and call command
if (hProVol != INVALID_HANDLE_VALUE)
{
// execute command
EwfMgrXYZ(...);
//XYZ is Enable, Disable or Commit, depending on the desired command

// close handle
EwfMgrClose(hProVol);
}

Thank you once more.
Bila

 

[Matt Kellner [MS]]

There is an updated EWFAPI.DLL, which is included in the FP2007 Database
Update. You should install that as well, and we highly recommend updating
your tools to FP2007 to take advantage of various improvements.