mobsync.exe returns invalid param when access a file

NTFSD
1

I observed a situation,very strange:
When mobsync.exe executes the sync workflow(sync the network to local),it will open the network file (ex. \192.168.1.100\test\1.txt).

In the second IRP_MJ_CREATE:
the desiredaccess is: FILE_READ_ATTRIBUTES|SYNCHRONIZE
the options is FILE_NON_DIRECTORY_FILE|FILE_NO_INTERMEDIATE_BUFFERING|FILE_SYNCHRONOUS_IO_NONALERT
the dispostion is FILE_OPEN
the sharemode is FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE

If my minifilter do nothing to the IRP_MJ_CREATE,everything is OK,the mobsync will sync the network file (\192.168.1.100\test\1.txt) to local.
But if I add FILE_READ_DATA to the desiredaccess of the IRP_MJ_CREATE,the mobsync will fail,and reports “invalid params when access \192.168.1.100\test\1.txt”.

very very strange,please clear it,thanks ~~~~~

2

oh,I said the mobsync.exe returns invalid params.
In filespy,I can see the IRP_MJ_CREATE returns STATUS_SUCCESS.
And,in filespy,the mobsync just IRP_MJ_CREATE,IRP_MJ_CLEANUP,IRP_MJ_CLOSE to the file,and all are STATUS_SUCCESS.
and then,the mobsync.exe returns invalid params in its UI.

3

This shouldn’t come as a surprise… Imagine the code in mobsync does
something like:

…
__try {
status = ZwCreateFile(&handle,…);
If (!NT_SUCCESS(status)) {
__leave;
}

status = ZwSomeFunction(handle,…);
If (!NT_SUCCESS(status)) {
__leave;
}
…
…
} __finally {

If (handle != NULL) {

ZwClose(handle);
}
Return status;

So in this case, filespy and your minifilter will see the create, then the
call to ZwSomeFunction will go to the IO manager (for example) which might
find that something is not quite right with the handle (depending on the
function there might some additional restrictions on what the handle access
should be), so it will return STATUS_INVALID_PARAMETER. Then the __finally
block will close that handle successfully and then the whole function will
return the status from ZwSomeFunction, which was STATUS_INVALID_PARAMETER.
Since the IO manager didn’t like the handle in ZwSomeFunction there was
never an IRP sent so you don’t see any failure in filespy.

Now, I don’t know if this is what actually happens, but it’s a plausible
scenario… unless someone on this list knows the answer right of the bat,
you’ll probably have to debug it yourself…

What I would do in this situation would be to let the minfilter change the
create and then continue execution until the code goes back to mobsync.exe
after the create, and from that point on step through each call until you
find the one that fails (to figure out what ZwSomeFunction is). Then I would
look on MSDN to see if there are additional requirements for that api and
why adding FILE_READ_DATA to the handle doesn’t work…

Hope this helps…

Thanks,
Alex.