multithreaded paging I/O failure for mini-filter

Hi.

I am seeing a failure when trying to access 2 or more files simultaneously via my mini-filter while handling memory mapped I/O (regular file access works fine with multiple threads). I can see the create and file info callbacks succeeding for both files, but pre-read callbacks only appear for the first thread/process to read data.

My filter operation is described somewhat in these threads:
http://www.osronline.com/showThread.cfm?link=214745
http://www.osronline.com/showThread.cfm?link=212042

Usually an exception is triggered in my test process while actually reading the mapped memory. Reading multiple files sequentially works. But it seems strange to me that reading one file prevents reading another controlled by the same filter. I am not aware of any global locks or shared data structures in my code that might be an obvious cause. The read callback for the second thread just never happens, so I am assuming it fails before being initiated by the VM manager. Aside from MDL handling the paging I/O path in my pre-read callback is the same as normal I/O (maybe that is the problem). I am not using the cache manager at all yet.

I know this is probably not enough information, but I was hoping someone would have a clue where to look. My previous queries here have been very fruitful.

Thanks

Well, I see from the below thread that even though my paging I/O requests are coming through at passive level, it probably isn’t safe to be performing file I/O there since special kernel APCs are disabled:

http://www.osronline.com/showthread.cfm?link=156969

Is there a best practice for performing I/O in this situation in a mini-filter? This seems like a pretty common scenario. I am basically implementing a virtualized file hierarchy to allow access to the contents of an archive (similar to ZIP) file. Poking through the past forum postings doesn’t seem to reveal a consensus on this issue. One solution that has been mentioned is using FltQueueGenericWorkItem() to perform the file I/O.

>create and file info callbacks succeeding for both files, but pre-read callbacks only appear for the first

thread/process to read data.

This is by design.

Both processes share the same set of physical pages, and the callback is only invoked when the first process to access the page brings it in to the memory.

There is no possibility at all to see such an event in the second process.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>common scenario. I am basically implementing a virtualized file hierarchy to allow access to the

contents of an archive (similar to ZIP) file.

Surely you should not call ZwXxx from the paging path.

Open the underlying file as noncached, and then, in the paging path of the “upper” filesystem view, read/write the file using IoAllocateIrp+IoCallDriver.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

> Open the underlying file as noncached, and then, in the paging path of the

“upper” filesystem view, read/write the file using IoAllocateIrp+IoCallDriver.

As an alternative, is it possible to defer the work to another thread as mentioned at the end of the thread below?
http://www.osronline.com/showThread.CFM?link=201276

It seems like Brian is doing something very similar to what I am doing. Although he doesn’t mention how in particular he routed requests to his worker thread, I am curious what the trade-offs would be between that and the IoCallDriver() approach.

Thanks