FltCreateFile and IO_STATUS_BLOCK

Hello,

In IRP_MJ_CLEANUP pre callback I need to open given file for further processing. Based on what I learnt and saw in msdn samples I should use FltCreateFile. I encountered problems with oplocks on shared drives as the FltCreateFile (I’m using the FILE_COMPLETE_IF_OPLOCKED option) returned STATUS_SUCCESS instead of STATUS_OPLOCK_BREAK_IN_PROGRESS.

When I hit that scenerio in windbg I saw that returned status is STATUS_SUCCESS but in IO_STATUS_BLOCK there’s desired STATUS_OPLOCK_BREAK_IN_PROGRESS status.

I’d like to ask you if I should use this function in this way then:


IO_STATUS_BLOCK iosb = {0}
NTSTATUS ntStatus = FltCreateFile(… , iosb, … );
if ( NT_SUCESS(ntStatus) )
ntstatus = iosb.Status;

I’d be very grateful for any help or suggestions or if you need more information (like parameters I’m using). This is a bit confusing for me because till I encountered that issue (windows 2k3 x86) I saw everyone use the return from the function itself not the iosb.

Kind Regards,
Kevin

That’s pretty weird. Are there any filters layered beneath you? You might
want to turn Driver Verifier on for your driver + FltMgr.sys + any file
system or filters below you. Feels like a bug.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

Hello,

In IRP_MJ_CLEANUP pre callback I need to open given file for further
processing. Based on what I learnt and saw in msdn samples I should use
FltCreateFile. I encountered problems with oplocks on shared drives as the
FltCreateFile (I’m using the FILE_COMPLETE_IF_OPLOCKED option) returned
STATUS_SUCCESS instead of STATUS_OPLOCK_BREAK_IN_PROGRESS.

When I hit that scenerio in windbg I saw that returned status is
STATUS_SUCCESS but in IO_STATUS_BLOCK there’s desired
STATUS_OPLOCK_BREAK_IN_PROGRESS status.

I’d like to ask you if I should use this function in this way then:


IO_STATUS_BLOCK iosb = {0}
NTSTATUS ntStatus = FltCreateFile(… , iosb, … );
if ( NT_SUCESS(ntStatus) )
ntstatus = iosb.Status;

I’d be very grateful for any help or suggestions or if you need more
information (like parameters I’m using). This is a bit confusing for me
because till I encountered that issue (windows 2k3 x86) I saw everyone use
the return from the function itself not the iosb.

Kind Regards,
Kevin

Thank you Scott, now I know that it shouldn’t work this way.
So I made a small research and opened fltMgr.sys (5.2.3790.3959) under disassembler and here’s what I found:

FltCreateFile->FltCreateFileEx->IoCreateFileSpecifyDeviceObjectHint
The returned value from IoCreateFileSpecifyDeviceObjectHint is in iosb but it’s not returned from FltCreateFileEx, instead FltCreateFileEx will return status returned from next functions for which it’s a “wrapper” (If I can call it this way).

I checked also fltMgr.sys (6.1.7600.16385) from windows 7:
FltCreateFile->FltCreateFileEx2->IoCreateFileEx
FltCreateFileEx2 saves IoCreateFileEx status in an additional variable and if FltCreateFileEx2’s other calls are success it will return what is really interesting - the IoCreateFileEx result.
So it will work fine there

Is it a bug? Should I then firstly check the returned status from FltCreateFile and if it’s a success, treat iosb.Status as a status of file opening?