FLT_PREOP_PENDING

NTFSD
1

Hi,
I am studying minifilter driver. I wrote one user application in which I created a file then wrote some data. The code fragment is:

if(!(hDevice=CreateFile(file_name,
GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_ALWAYS,
FILE_ATTRIBUTE_NORMAL,
NULL) )
) {
printf(“\nError !”);
}
status=WriteFile(hDevice,buff,sizeof(buff),&bw,NULL);

So, the write request will be captured by minifilter and then Preoperation of Write will be called. Now without bothering (for initial phases) I returned FLT_PREOP_PENDING (only for that file)then I found that the thread of that process is suspended and it didn’t perform any of the remaining tasks.
Now my question is, whether returning the FLT_PREOP_PENDING suspends the whole process? I expected that only IO operation would be suspended (here write operation.)

Also, during that time the file was not accessible. Why it is not accessible? Whether system does any locking on files?

Thank you.

2

If you return FLT_PREOP_PENDING then you are expected to complete the
request at some point. In this case you do not have overlapped I/O set up
so that thread that is performing the write is blocked, if that is the only
thread in the process the whole process is therefore blocked.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntfsd…
> Hi,
> I am studying minifilter driver. I wrote one user application
> in which I created a file then wrote some data. The code fragment is:
> -----
> if(!(hDevice=CreateFile(file_name,
> GENERIC_READ | GENERIC_WRITE,
> FILE_SHARE_READ | FILE_SHARE_WRITE,
> NULL,
> OPEN_ALWAYS,
> FILE_ATTRIBUTE_NORMAL,
> NULL) )
> ) {
> printf(“\nError !”);
> }
> status=WriteFile(hDevice,buff,sizeof(buff),&bw,NULL);
> --------
> So, the write request will be captured by minifilter and then Preoperation
> of Write will be called. Now without bothering (for initial phases) I
> returned FLT_PREOP_PENDING (only for that file)then I found that the
> thread of that process is suspended and it didn’t perform any of the
> remaining tasks.
> Now my question is, whether returning the FLT_PREOP_PENDING suspends the
> whole process? I expected that only IO operation would be suspended (here
> write operation.)
>
> Also, during that time the file was not accessible. Why it is not
> accessible? Whether system does any locking on files?
>
> Thank you.
>

3

Hi Guru Prasad,

So, the write request will be captured by minifilter and then Preoperation
of Write will be called. Now without bothering (for initial phases)
I returned FLT_PREOP_PENDING (only for that file)then I found that the thread
of that process is suspended and it didn’t perform any of the remaining tasks.
Now my question is, whether returning the FLT_PREOP_PENDING suspends the whole
process? I expected that only IO operation would be suspended (here write operation.)

Few points that I have for you:

  1. Did you call FltcompletePendedPreOperation at some later stage for the operation for which you returned FLT_PREOP_PENDING? But the thread should be free as soon as you return pending status. However, note one thing: You have opened the file for synchronous operations. So I/O Manager will perform the wait on your behalf even if some drive returns STATUS_PENDING.
    If you really want to see the working of I/O pending, you should open the file along with overlapped I/O flag. And then you can do asynchronous I/O operations. Basically, asynchronous processing will be visible to your application. Otherwise, even if the processing is done asynchronously, I/O manager will wait on your behalf and make it appear to be synchronous for your application.

  2. Also, you cannot pend paging i/o operations. Did you put that check? This is important because when you issue a write (which is cached write) from your application, it comes to the cache and results in a page fault. This page fault is serviced in the context of the thread that caused the fault. And if you pend it, then also you may land up in this problem. And if you are saying that the thread has also blocked then this could be the reason.

Regards,
Ayush Gupta

4

Hi Guru Prasad,

Sorry, I misread and thought that the thread was stuck.
If it is suspended, it is perfectly normal. You have opened the file for synchronous access.
See point 1 of my previous post for explanation.

Regards,
Ayush Gupta

5

Thank you Don and Ayush.

Is there any way to specify Asynchronous write in minifilter(as there is Overlapped flag in user mode)?
Since there is almost one-one to mapping between the options specified in user mode and those in minifilter code.

6

Hi Guru Prasad,

Is there any way to specify Asynchronous write in minifilter
(as there is Overlapped flag in user mode)?
Since there is almost one-one to mapping between the options
specified in user mode and those in minifilter code.

Check out the documentation for FltWriteFile. See the comments section in it.

Regards,
Ayush Gupta

7

You may use “FltAllocateCallbackData” and “FltPerformAsynchronousIo” to
issue an async write.

wrote news:xxxxx@ntfsd…
> Thank you Don and Ayush.
>
> Is there any way to specify Asynchronous write in minifilter(as there is
> Overlapped flag in user mode)?
> Since there is almost one-one to mapping between the options specified in
> user mode and those in minifilter code.
>
>

8

Hi Frank,

You may use “FltAllocateCallbackData” and “FltPerformAsynchronousIo” to
issue an async write.

I think one should try to use one of the FltXXXFile functions as far as possible.
But if one has to make calls at APC_LEVEL (for paging I/O operations), FltAllocateCallbackData & FltPerformAsynchronousIo come in handy.

Regards,
Ayush Gupta

9

RE: [ntfsd] FLT_PREOP_PENDINGThat is indeed true. Better use FltXXXFile, if possible.

But there’s another problem with FltXXXFile for an async op: if you want to cancel that async I/O with “FltCancelIo”, because I/O takes too long, you’ll need the CallbackData parameter. FltXXXFile doesn’t deliver that information.

“Ayush Gupta” wrote news:xxxxx@ntfsd…
Hi Frank,

>You may use “FltAllocateCallbackData” and “FltPerformAsynchronousIo” to

>issue an async write.

I think one should try to use one of the FltXXXFile functions as far as possible.

But if one has to make calls at APC_LEVEL (for paging I/O operations), FltAllocateCallbackData & FltPerformAsynchronousIo come in handy.

Regards,

Ayush Gupta

10

Hi Frank,

But there’s another problem with FltXXXFile for an async op:

if you want to cancel that async I/O with “FltCancelIo”, because I/O takes too long,

you’ll need the CallbackData parameter. FltXXXFile doesn’t deliver that information.

Yes. That’s true.

And the funny thing is that the documentation says “A minifilter driver that initiates an I/O operation by calling a routine such as ms-help: FltPerformAsynchronousIo, ms-help: FltReadFile, or ms-help: FltWriteFile can cancel the operation by calling FltCancelIo”

The documentation does not care “HOW” will the caller of FltXXXFile get the callbackdata to call FltCancelIo.

:slight_smile:

Regards,

Ayush Gupta</ms-help:></ms-help:></ms-help:>