FltCreateFile and stream

NTFSD
1

In the post op callback to IRP_MJ_CREATE my mini filter needs to open up a stream (or at least see if it is there) for the file that is being opened.

e.g \Device\HarddiskVolume1\Dir1\Subdir2\Somefile.xyz:Abc.def

Since I’m in PostOp and I need to have IRQL = passive for FltCreateFile, I issue a FltQueueDeferredIoWorkItem() which will launch the code to open the stream when it can.

When my routine does get called, I’ve checked to see that the IRQL = 0 for the cores in my machine and indeed windbg says they are. In fact I do this just before I make the call to FltCreateFile().

InitializeObjectAttributes(&ObjAttr,&RDMStreamName,OBJ_KERNEL_HANDLE,NULL,NULL);
Status = FltCreateFile(RepData.Filter,pIC,StreamHandle, FILE_READ_DATA|FILE_READ_ATTRIBUTES,
&ObjAttr,&IoStatus,
0,FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ,FILE_OPEN, //fail if it does not exist.
FILE_NON_DIRECTORY_FILE,
NULL, //ea buffer
0, // ea len
0);

BUT… I’m dying with IRQL_NOT_LESS_OR_EQUAL (a)

Arg1: 00000084, memory referenced <---- why is something looking over here?
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 81ba4e79, address which referenced memory.

Here is the thrreads stack:

0 82fd7b58 818769c9 hal!KeAcquireInStackQueuedSpinLockRaiseToSynch+0x19
01 82fd7b78 82173235 nt!ExAcquireResourceSharedLite+0x21
02 82fd7b98 82190d83 fltmgr!FltpGetNextCallbackNodeForInstance+0x29
03 82fd7bc0 8218abe5 fltmgr!TargetedIOCtrlGenerateECP+0x155
04 82fd7c20 8218ad1c fltmgr!FltCreateFileEx2+0x69
05 82fd7c68 8e1187ad fltmgr!FltCreateFile+0x38
06 82fd7cdc 8e1135bf RDMFilter!DoesRDMStreamExist+0x8d
07 82fd7d14 82193bd4 RDMFilter!SafePostCreateProcessing_Succeed+0x5f
08 82fd7d44 81878db8 fltmgr!FltpProcessDeferredIoWorkItem+0x34
09 82fd7d7c 81a25472 nt!ExpWorkerThread+0xfd
0a 82fd7dc0 8189141e nt!PspSystemThreadStartup+0x9d
0b 00000000 00000000 nt!KiThreadStartup+0x16

I guess that I’ve missed something about the problem of opening up streams, but
I don’t see it from here, does anyone have some insight???

Thanks
Larry

2

In InitializeObjectAttributes, is your stream name a real UNICODE_STRING?
That is a structure and not a wide character string.

Did you read that the second parameter to FltCreateFile() must be NULL if
you use FILE_NON_DIRECTORY_FILE attributes? How about the Handle being a
pointer to the handle? I quit since you have so many simple mistakes that
any compiler at warning level 4 can find. Either your code is really bad or
the copying to your email was done badly.

The IRQL is DISPATCH_LEVEL because of the call to acquire a spinlock.
Probably the incorrect parameters forces the code down a bad path which
won’t work.

wrote in message news:xxxxx@ntfsd…
> In the post op callback to IRP_MJ_CREATE my mini filter needs to open up a
> stream (or at least see if it is there) for the file that is being opened.
>
> e.g \Device\HarddiskVolume1\Dir1\Subdir2\Somefile.xyz:Abc.def
>
>
> Since I’m in PostOp and I need to have IRQL = passive for FltCreateFile, I
> issue a FltQueueDeferredIoWorkItem() which will launch the code to open
> the stream when it can.
>
> When my routine does get called, I’ve checked to see that the IRQL = 0 for
> the cores in my machine and indeed windbg says they are. In fact I do
> this just before I make the call to FltCreateFile().
>
> InitializeObjectAttributes(&ObjAttr,&RDMStreamName,OBJ_KERNEL_HANDLE,NULL,NULL);
> Status = FltCreateFile(RepData.Filter,pIC,StreamHandle,
> FILE_READ_DATA|FILE_READ_ATTRIBUTES,
> &ObjAttr,&IoStatus,
> 0,FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ,FILE_OPEN, //fail if it does
> not exist.
> FILE_NON_DIRECTORY_FILE,
> NULL, //ea buffer
> 0, // ea len
> 0);
>
>
> BUT… I’m dying with IRQL_NOT_LESS_OR_EQUAL (a)
>
> Arg1: 00000084, memory referenced <---- why is something
> looking over here?
> Arg2: 00000002, IRQL
> Arg3: 00000001, bitfield :
> bit 0 : value 0 = read operation, 1 = write operation
> bit 3 : value 0 = not an execute operation, 1 = execute operation (only on
> chips which support this level of status)
> Arg4: 81ba4e79, address which referenced memory.
>
> Here is the thrreads stack:
>
> 0 82fd7b58 818769c9 hal!KeAcquireInStackQueuedSpinLockRaiseToSynch+0x19
> 01 82fd7b78 82173235 nt!ExAcquireResourceSharedLite+0x21
> 02 82fd7b98 82190d83 fltmgr!FltpGetNextCallbackNodeForInstance+0x29
> 03 82fd7bc0 8218abe5 fltmgr!TargetedIOCtrlGenerateECP+0x155
> 04 82fd7c20 8218ad1c fltmgr!FltCreateFileEx2+0x69
> 05 82fd7c68 8e1187ad fltmgr!FltCreateFile+0x38
> 06 82fd7cdc 8e1135bf RDMFilter!DoesRDMStreamExist+0x8d
> 07 82fd7d14 82193bd4 RDMFilter!SafePostCreateProcessing_Succeed+0x5f
> 08 82fd7d44 81878db8 fltmgr!FltpProcessDeferredIoWorkItem+0x34
> 09 82fd7d7c 81a25472 nt!ExpWorkerThread+0xfd
> 0a 82fd7dc0 8189141e nt!PspSystemThreadStartup+0x9d
> 0b 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> I guess that I’ve missed something about the problem of opening up
> streams, but
> I don’t see it from here, does anyone have some insight???
>
> Thanks
> Larry
>
>
>
>
>

3

The params that you mentioned were passed into a routine to open the stream, so you did not see that file name is indeed a pointer to a Unicode String or that the StreamHandle is a pointer.

No I did not read that the 2nd param must be null,… certainly does not say so on FltCreateFile document. In fact, it says that if the param is 0, then the request is sent to the top of the stack, something I don’t want to happen (I think).

Here is the whole routine:

BOOLEAN DoesRDMStreamExist(HANDLE *StreamHandle, PFLT_INSTANCE pIC,UNICODE_STRING * InFileName)
{
int Found = TRUE;
UNICODE_STRING RDMStreamName;
WCHAR * RBuffer = 0;
OBJECT_ATTRIBUTES ObjAttr;
NTSTATUS Status;
IO_STATUS_BLOCK IoStatus;

// is this cheaper than enumeration of its streams???
if (!BuildRDMStreamName(InFileName,& RDMStreamName,DLM))
return FALSE;

InitializeObjectAttributes(&ObjAttr,&RDMStreamName,OBJ_KERNEL_HANDLE,NULL,NULL);
Status = FltCreateFile(RepData.Filter,pIC,StreamHandle,
FILE_READ_DATA|FILE_READ_ATTRIBUTES,&ObjAttr,&IoStatus,
0,FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ,FILE_OPEN, //fail if it does not exist.
FILE_NON_DIRECTORY_FILE,
NULL, //ea buffer
0, // ea len
0);

if(!NT_SUCCESS(Status)) // then it probably does not exist
goto cleanup;

Found =TRUE;

cleanup:
if (RDMStreamName.Buffer) ExFreePool(RDMStreamName.Buffer);

return (Found);

}

4

> No I did not read that the 2nd param must be null,… certainly does not say so on FltCreateFile document.

From the docs: “This parameter must be NULL if the CreateOptions FILE_NON_DIRECTORY_FILE flag is specified.”, at the end of the Instance parameter explanation.
Sounds like it did say, I could be wrong :wink:
This would not cause a blue screen, and should return an error instead.

–
Kind regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.

5

From the docs: “This parameter must be NULL if the CreateOptions
FILE_NON_DIRECTORY_FILE flag is specified.”, at the end of the Instance
parameter explanation.

Where did you get it?

Neither my copy of WDK (WDK.v10.6001) doc nor msdn (http://msdn2.microsoft.com/en-us/library/aa488542.aspx) contain that.

6

IFS Kit 3790.1830 says this in the FltCreateFile docs

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@umail.ru
Sent: 17 September 2007 13:23
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] FltCreateFile and stream

*** WARNING ***

This mail has originated outside your organization, either from an
external partner or the Global Internet.
Keep this in mind if you answer this message.

From the docs: “This parameter must be NULL if the CreateOptions
FILE_NON_DIRECTORY_FILE flag is specified.”, at the end of the Instance
parameter explanation.

Where did you get it?

Neither my copy of WDK (WDK.v10.6001) doc nor msdn
(http://msdn2.microsoft.com/en-us/library/aa488542.aspx) contain that.

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@baesystems.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************