Hello
A 3rd party app locks a byte range with key 1 and then writes to the file. In Pre-Write, due to some logic in our minifilter, rather than continuing the request down the stack we try to write ourselves to that file using FltWriteFile (direct IO). We use the file object from Cdb and its done for non-paging IO.
But as FltWriteFile does not take key of byte range lock, our FltWrite fails with STATUS_FILE_LOCK_CONFLICT.
I read through at the thread http://www.osronline.com/ShowThread.cfm?link=138654, which suggested to use FltPerformSynchronousIO. So I created callback data, set params appropriately (set Iopb->Parameters.Write.Key = 1) and called it to write. But it also fails with same error.
Debugging it, reveals that it also does not use the key parameter and sends IRP with key set to 0. Verified that by looking at IO_STACK_LOCATION of IRP that goes below.
So is that a bug with FltMgr?
Is there any way/api to circumvent the problem other than memory mapping the file?
There is FltWriteFileEx which takes key but available starting from windows 8.
Thanks
Rohan
Looks to me like the Key value isn’t copied over until at least Windows 8,
at which point you have the new API anyway. There are a few unattractive
alternatives, but it looks to me like you have to resort to using
ZwWriteFile in this case pre-Windows 8.
-scott
OSR
wrote in message news:xxxxx@ntfsd…
Hello
A 3rd party app locks a byte range with key 1 and then writes to the file.
In Pre-Write, due to some logic in our minifilter, rather than continuing
the request down the stack we try to write ourselves to that file using
FltWriteFile (direct IO). We use the file object from Cdb and its done for
non-paging IO.
But as FltWriteFile does not take key of byte range lock, our FltWrite fails
with STATUS_FILE_LOCK_CONFLICT.
I read through at the thread
http://www.osronline.com/ShowThread.cfm?link=138654, which suggested to use
FltPerformSynchronousIO. So I created callback data, set params
appropriately (set Iopb->Parameters.Write.Key = 1) and called it to write.
But it also fails with same error.
Debugging it, reveals that it also does not use the key parameter and sends
IRP with key set to 0. Verified that by looking at IO_STACK_LOCATION of IRP
that goes below.
So is that a bug with FltMgr?
Is there any way/api to circumvent the problem other than memory mapping the
file?
There is FltWriteFileEx which takes key but available starting from windows
8.
Thanks
Rohan
When you say " We use the file object from Cdb", what is Cdb ? The only
thing I can think of is the debugger but I can’t figure out how that would
work ?
Thanks,
Alex.
On Tue, Feb 4, 2014 at 6:40 AM, Scott Noone wrote:
> Looks to me like the Key value isn’t copied over until at least Windows 8,
> at which point you have the new API anyway. There are a few unattractive
> alternatives, but it looks to me like you have to resort to using
> ZwWriteFile in this case pre-Windows 8.
>
> -scott
> OSR
>
> wrote in message news:xxxxx@ntfsd…
>
>
> Hello
>
> A 3rd party app locks a byte range with key 1 and then writes to the file.
> In Pre-Write, due to some logic in our minifilter, rather than continuing
> the request down the stack we try to write ourselves to that file using
> FltWriteFile (direct IO). We use the file object from Cdb and its done for
> non-paging IO.
>
> But as FltWriteFile does not take key of byte range lock, our FltWrite
> fails with STATUS_FILE_LOCK_CONFLICT.
>
> I read through at the thread http://www.osronline.com/
> ShowThread.cfm?link=138654, which suggested to use
> FltPerformSynchronousIO. So I created callback data, set params
> appropriately (set Iopb->Parameters.Write.Key = 1) and called it to write.
> But it also fails with same error.
>
> Debugging it, reveals that it also does not use the key parameter and
> sends IRP with key set to 0. Verified that by looking at IO_STACK_LOCATION
> of IRP that goes below.
>
> So is that a bug with FltMgr?
>
> Is there any way/api to circumvent the problem other than memory mapping
> the file?
> There is FltWriteFileEx which takes key but available starting from
> windows 8.
>
> Thanks
> Rohan
>
>
> —
> 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
>
Or “SCSI Command Data Block” 
I suspect that he meant “Callback Data” (cbd)
-scott
OSR
“Alex Carp” wrote in message
news:xxxxx@ntfsd…
When you say " We use the file object from Cdb", what is Cdb ? The only
thing I can think of is the debugger but I can’t figure out how that would
work ?
Thanks,
Alex.
On Tue, Feb 4, 2014 at 6:40 AM, Scott Noone wrote:
Looks to me like the Key value isn’t copied over until at least Windows 8,
at which point you have the new API anyway. There are a few unattractive
alternatives, but it looks to me like you have to resort to using
ZwWriteFile in this case pre-Windows 8.
-scott
OSR
wrote in message news:xxxxx@ntfsd…
Hello
A 3rd party app locks a byte range with key 1 and then writes to the file.
In Pre-Write, due to some logic in our minifilter, rather than continuing
the request down the stack we try to write ourselves to that file using
FltWriteFile (direct IO). We use the file object from Cdb and its done for
non-paging IO.
But as FltWriteFile does not take key of byte range lock, our FltWrite fails
with STATUS_FILE_LOCK_CONFLICT.
I read through at the thread
http://www.osronline.com/ShowThread.cfm?link=138654, which suggested to use
FltPerformSynchronousIO. So I created callback data, set params
appropriately (set Iopb->Parameters.Write.Key = 1) and called it to write.
But it also fails with same error.
Debugging it, reveals that it also does not use the key parameter and sends
IRP with key set to 0. Verified that by looking at IO_STACK_LOCATION of IRP
that goes below.
So is that a bug with FltMgr?
Is there any way/api to circumvent the problem other than memory mapping the
file?
There is FltWriteFileEx which takes key but available starting from windows
8.
Thanks
Rohan
—
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
Oh I see… It was before I had my tea this morning :).
Anyway, I was just going to say that using the FILE_OBJECT from the
FLT_CALLBACK_DATA (or any FILE_OBJECT that the filter didn’t open with
FltCreateFile()) might be problematic to use with ZwWriteFile() since it’s
hard to control where in the IO stack it the IRP_MJ_WRITE will go.
Thanks,
Alex.
On Tue, Feb 4, 2014 at 9:54 AM, Scott Noone wrote:
> Or “SCSI Command Data Block”
>
> I suspect that he meant “Callback Data” (cbd)
>
> -scott
> OSR
>
> “Alex Carp” wrote in message
> news:xxxxx@ntfsd…
>
> When you say " We use the file object from Cdb", what is Cdb ? The only
> thing I can think of is the debugger but I can’t figure out how that would
> work ?
>
> Thanks,
> Alex.
>
>
>
> On Tue, Feb 4, 2014 at 6:40 AM, Scott Noone wrote:
> Looks to me like the Key value isn’t copied over until at least Windows 8,
> at which point you have the new API anyway. There are a few unattractive
> alternatives, but it looks to me like you have to resort to using
> ZwWriteFile in this case pre-Windows 8.
>
> -scott
> OSR
>
> wrote in message news:xxxxx@ntfsd…
>
>
> Hello
>
> A 3rd party app locks a byte range with key 1 and then writes to the file.
> In Pre-Write, due to some logic in our minifilter, rather than continuing
> the request down the stack we try to write ourselves to that file using
> FltWriteFile (direct IO). We use the file object from Cdb and its done for
> non-paging IO.
>
> But as FltWriteFile does not take key of byte range lock, our FltWrite
> fails with STATUS_FILE_LOCK_CONFLICT.
>
> I read through at the thread http://www.osronline.com/
> ShowThread.cfm?link=138654, which suggested to use
> FltPerformSynchronousIO. So I created callback data, set params
> appropriately (set Iopb->Parameters.Write.Key = 1) and called it to write.
> But it also fails with same error.
>
> Debugging it, reveals that it also does not use the key parameter and
> sends IRP with key set to 0. Verified that by looking at IO_STACK_LOCATION
> of IRP that goes below.
>
> So is that a bug with FltMgr?
>
> Is there any way/api to circumvent the problem other than memory mapping
> the file?
> There is FltWriteFileEx which takes key but available starting from
> windows 8.
>
> Thanks
> Rohan
>
>
> —
> 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
>
>
>
> —
> 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
>
Thanks Alex for inputs and yes Cbd is callback data for minifilter callback.
As you said, using ZwWriteFile is not good option with that file object. So tried to open the file again and tried to use ZwWriteFile, but that again fails with lock conflict error. Probably because its already locked through other file object, which is correct.
Could you elaborate (give pointers) about other unattractive options?
Thanks
Rohan
Well, since we’re talking unattractive options, you could always write
your own FltWriteFileEx() version (could be simpler than FltWriteFileEx()
if you don’t need all the parameters) that does what you want. As far as I
recall FltMgr’s FltWriteFileEx() doesn’t use any undocumented magic. You’d
have to call FltAllocateCallbackData() to create a FLT_CALLBACK_DATA and
then something like FltPerformSynchronousIo() to send the request down.
I’ve done this before (well, not exactly this for byte range locks, but for
something similar, I think for MDLs) and I highly recommend looking at
FltWriteFileEx() in a disassembler to make sure you’re not missing any
fields. It’s tedious but doable.
Thanks,
Alex.
On Tue, Feb 4, 2014 at 8:16 PM, wrote:
> Thanks Alex for inputs and yes Cbd is callback data for minifilter
> callback.
> As you said, using ZwWriteFile is not good option with that file object.
> So tried to open the file again and tried to use ZwWriteFile, but that
> again fails with lock conflict error. Probably because its already locked
> through other file object, which is correct.
>
> Could you elaborate (give pointers) about other unattractive options?
>
> Thanks
> Rohan
>
> —
> 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
>
As I mentioned in first post, I have already tried using FltPerformSynchronousIO(), but that too ignores the key parameter internally when fltmgr builds an IRP to send it down.
Are you suggesting to create my own IRP in minifilter and send it down?
Thanks for writing.
Rohan
This is not a viable paradigm in a mini-filter. That’s because there is no exposed mechanism from Filter Manager to “inject” an IRP at the right level.
Tony
OSR
Sorry, I totally forgot about that. I thought you were only complaining
that FltWriteFile doesn’t take the right parameter.
No, I’m not suggesting you create an actual IRP in a minifilter, it has the
same problem as using ZwWriteFile() with the layering…
At this point perhaps it might be easier just to continue to use the
original request and use that FLT_CALLBACK_DATA to do your reads… May I
ask why that was off the table ?
Thanks,
Alex.
On Wed, Feb 5, 2014 at 8:17 PM, wrote:
> As I mentioned in first post, I have already tried using
> FltPerformSynchronousIO(), but that too ignores the key parameter
> internally when fltmgr builds an IRP to send it down.
>
> Are you suggesting to create my own IRP in minifilter and send it down?
>
> Thanks for writing.
> Rohan
>
>
> —
> 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
>