Processing IRPs in minifilter driver

Hey.

I’m currently developing a small minifilter driver. My main goal is to intercept IRP_MJ_CREATEs, and then, process it in a user mode process. After the user mode process finishes its processing, it should communicate with the minifilter driver. In this stage the driver can complete the IRP’s post operation.

The user-processing could take a while, therefore, I return FLT_POSTOP_MORE_PROCESSING_REQUIRED in my post create function. I’m also creating a work item and inserting it to the deferred queue, in order to complete its processing in the end. My problem is that the delayed irp completion function is running immediately when i call FltQueueDeferredIoWorkItem. That way I can’t wait for the user mode processing.

I thought about adding waitforsingleobject in the irp completion function, but it will overload the cpu I guess.

I will appreciate any help here,
thanks.

First of all, read something about the OS concepts to get the knowledge of why WaitForSingleObject will not overload the CPU :slight_smile:

Second: you need to notify your user-mode code in some way that there is a CREATE request to handle. For this, you should use FltMgr’s Communication Ports.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

I have no problem to notify the userprocess… My only problem is the waiting in the driver for the userprocess result. The delayed irp-completion function returns immediately, and because of that I can’t wait for the user result. If i’ll use waitforsingleobject, I would have to create an event or something else to wait on for every CREATE irp. Sounds like overkill. Don’t you think? Thanks

Mark the request as pending, and then complete it when the user mode will call you about “this request was processed by me”.

wrote in message news:xxxxx@ntfsd…
>I have no problem to notify the userprocess… My only problem is the waiting in the driver for the userprocess result. The delayed irp-completion function returns immediately, and because of that I can’t wait for the user result. If i’ll use waitforsingleobject, I would have to create an event or something else to wait on for every CREATE irp. Sounds like overkill. Don’t you think? Thanks
>

  1. It’s a post operation, therefore i return “FLT_POSTOP_MORE_PROCESSING_REQUIRED”, and not “FLT_PREOP_PENDING”.

In my post create function, I insert WorkItems to the queue, in order to process them later :
status = FltQueueDeferredIoWorkItem(WorkItem, Data, MyFilterDelayedPostOpCB, DelayedWorkQueue, CompletionContext);

The problem is that the worker routine (DelayedWorkQueue) happens immediately, however, I want it to wait for the user processing.

Why use a work item? Save the FLT_CALLBACK_DATA pointer to your queue. Complete the processing when you get an IOCTL from the user that completes the operation.

Bill Wandel

 

on Dec 10, 2013, xxxxx@gmail.com wrote:

  1. It’s a post operation, therefore i return “FLT_POSTOP_MORE_PROCESSING_REQUIRED”, and not “FLT_PREOP_PENDING”.

In my post create function, I insert WorkItems to the queue, in order to process them later :
status = FltQueueDeferredIoWorkItem(WorkItem, Data, MyFilterDelayedPostOpCB, DelayedWorkQueue, CompletionContext);

The problem is that the worker routine (DelayedWorkQueue) happens immediately, however, I want it to wait for the user processing.


NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

 

@kfir sht

Instead of queuing a work-item, do the irp completion in user applications response.
OR
In the irp/work-item queue make field to identify whether user application processed has this irp or not, if not processed do not de-queue the work item.

Well thanks, you gave me some food for thought!