Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

returning FLT_PREOP_PENDING and its effect on CPU usage

kernkern Member Posts: 5


I'm writing an application which scans file operations (a security product, user mode + driver). In order to preserve the OS behavior, I return FLT_PREOP_PENDING / FLT_POSTOP_MORE_PROCESSING_REQUIRED whenever the IRP is asynchronous. This means that if some user mode application requests an asynchronous file operation, the requesting thread will not block. I resume the pre/post operation once I'm done processing the operation, where the resumption is triggered by a user mode thread which completed the scanning.

My problem is that once I call FltCompletePendedPreOperation(), resuming the operation is done in my thread(s), and not in the original thread/process which requested the operation. This means that my user mode thread appears as consuming a lot of CPU, when in fact this CPU should have been attributed to the processes which requested the file operations.
Granted, some of the operations are not called in the original thread context anyway. Still, since I pend and resume the operation, I practically delegate the CPU to my own threads.

My question is:
Is there a 'natural', built-in way in the flt manager, to make preop/postop resumption take place in the original process where the IRP initially arrived? Sort of like resuming the operation asynchronously, and where my thread passes the ownership back to where is was before pending.

I thought about creating a worker thread pool and having the resumption take place there, but this would again create a skewed picture where system process is attributed with more CPU than normal. I'm looking for a more built-in way to keep the system CPU distribution similar to what it would have been without pending - i.e. that each process is attributed with CPU time corresponding to what it has requested.

I'd appreciate any comment,
thank you.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online