Minifilter callback parameters access result IRQL_NOT_LESS_OR_EQUAL

Rohan_Nandode-2 · December 11, 2009, 10:48am

Hi

I have written a minifilter, registered for Write post operation callback.
The function defined like
FLT_POSTOP_CALLBACK_STATUS
hPostOperationCallbackWrite (
__inout PFLT_CALLBACK_DATA Data,
__in PCFLT_RELATED_OBJECTS FltObjects,
__in PVOID CompletionContext,
__in FLT_POST_OPERATION_FLAGS Flags
)

While reading filename for the operation in the callback using “FltObjects->FileObject->FileName.Buffer”, sometimes I get bug check with IRQL_NOT_LESS_OR_EQUAL.
This mainly happens when driver verifier is enabled with force IRQL checking.

Isn’t the callback parameters are from non-paged pool?

Thanks

Eric_Diven · December 11, 2009, 10:54am

FltObjects->FileObject->FileName isn’t an FltMgr owned object. As such,
regardless of whether FltObjects is allocated from the NPP, you can’t
assume that FileObject->FileName is accessible at elevated IRQL.

Also, if you look at the documentation for FILE_OBJECT, you’ll also see
that FileObject.FileName is only valid during the IRP_MJ_CREATE path.
Since you’re writing a minifilter you should look at the
FltGetFileNameInformation function.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Friday, December 11, 2009 10:49 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Minifilter callback parameters access result
IRQL_NOT_LESS_OR_EQUAL

Hi

I have written a minifilter, registered for Write post
operation callback.
The function defined like
FLT_POSTOP_CALLBACK_STATUS
hPostOperationCallbackWrite (
__inout PFLT_CALLBACK_DATA Data,
__in PCFLT_RELATED_OBJECTS FltObjects,
__in PVOID CompletionContext,
__in FLT_POST_OPERATION_FLAGS Flags
)

While reading filename for the operation in the callback
using “FltObjects->FileObject->FileName.Buffer”, sometimes I
get bug check with IRQL_NOT_LESS_OR_EQUAL.
This mainly happens when driver verifier is enabled with
force IRQL checking.

Isn’t the callback parameters are from non-paged pool?

Thanks

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

Don_Burn_1 · December 11, 2009, 10:54am

First you can only rely on FileObject->FileName being correct in a PreCreate
operation. Second, in a mini-filter there is generaly no reason to be
accessing the raw file object. If you want this data, set it up in a
context in PreCreate and use the value from the context.

–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntfsd…
> Hi
>
> I have written a minifilter, registered for Write post operation callback.
> The function defined like
> FLT_POSTOP_CALLBACK_STATUS
> hPostOperationCallbackWrite (
> inout PFLT_CALLBACK_DATA Data,
> in PCFLT_RELATED_OBJECTS FltObjects,
> in PVOID CompletionContext,
> in FLT_POST_OPERATION_FLAGS Flags
> )
>
> While reading filename for the operation in the callback using
> “FltObjects->FileObject->FileName.Buffer”, sometimes I get bug check with
> IRQL_NOT_LESS_OR_EQUAL.
> This mainly happens when driver verifier is enabled with force IRQL
> checking.
>
> Isn’t the callback parameters are from non-paged pool?
>
> Thanks
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4679 (20091211)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>

Information from ESET NOD32 Antivirus, version of virus signature database 4679 (20091211)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Rohan_Nandode-2 · December 14, 2009, 6:24am

Thanks for the knowledge.

I tried to use FltGetFileNameInformation().
But this function is suppose to be used at irql <= APC.
With driver verifier, the driver is crashing with DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) in this function.
With reference to “Dispatch Routine IRQL and Thread Context” http://msdn.microsoft.com/en-us/library/ms790762.aspx
the write operation callback should be at APC_LEVEL or PASSIVE level.

Why it is problem with verifier?

Thanks again.

Lijun_Wang · December 14, 2009, 11:38am

Make sure you are not calling the function inside a spin lock which elevats the IRQL.

From: “xxxxx@gmail.com”
To: Windows File Systems Devs Interest List
Sent: Mon, December 14, 2009 6:24:54 AM
Subject: RE:[ntfsd] Minifilter callback parameters access result IRQL_NOT_LESS_OR_EQUAL

Thanks for the knowledge.

I tried to use FltGetFileNameInformation().
But this function is suppose to be used at irql <= APC.
With driver verifier, the driver is crashing with DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) in this function.
With reference to “Dispatch Routine IRQL and Thread Context” http://msdn.microsoft.com/en-us/library/ms790762.aspx
the write operation callback should be at APC_LEVEL or PASSIVE level.

Why it is problem with verifier?

Thanks again.

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

Tapan_Chaudhari · December 15, 2009, 7:08pm

The write operation callback is not guaranteed to be called at <=APC_LEVEL.
Only create callback is guaranteed to be called at PASSIVE_LEVEL.

Check this out for more detail.
http://msdn.microsoft.com/en-us/library/ms793711.aspx

Thanks,

On Mon, Dec 14, 2009 at 11:38 AM, Lijun Wang wrote:

> Make sure you are not calling the function inside a spin lock which elevats
> the IRQL.
>
> ------------------------------
> From: “xxxxx@gmail.com”
> To: Windows File Systems Devs Interest List
> Sent: Mon, December 14, 2009 6:24:54 AM
> Subject: RE:[ntfsd] Minifilter callback parameters access result
> IRQL_NOT_LESS_OR_EQUAL
>
> Thanks for the knowledge.
>
> I tried to use FltGetFileNameInformation().
> But this function is suppose to be used at irql <= APC.
> With driver verifier, the driver is crashing with
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) in this function.
> With reference to “Dispatch Routine IRQL and Thread Context”
> http://msdn.microsoft.com/en-us/library/ms790762.aspx
> the write operation callback should be at APC_LEVEL or PASSIVE level.
>
> Why it is problem with verifier?
>
> Thanks again.
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) 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
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) 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
>

Ayush_Gupta-2 · December 16, 2009, 4:57am

According to your first post, you are trying to get the file name in
PostWrite routine. And I suppose you are trying to call
FltGetFileNameInformation from that routine? If yes, then I suggest that you
take a huge step back and first try to understand the basic FS concepts.
Calling
FltGetFileNameInformation in PostWrite is wrong for multiple reasons:

PostWrite can get called at IRQL DISPATCH_LEVEL, which is why Verifier
caught your driver’s neck trying to violate a rule.
Incase of Paging I/Os it is unsafe to call into the FS to get the name.
And hence the FltGetFileNameInformation will fail for those cases.

You could call FltGetFileNameInformation in PreWrite. That would save you
from the crash. But, again, in that case too you will not be able to query
the file name for Paging writes.

BTW, what are you trying to do getting the file name in PostWrite anyways?

Regards,
Ayush Gupta
AI Consulting
http://windows-internals.blogspot.com/

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, December 14, 2009 4:55 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Minifilter callback parameters access result
IRQL_NOT_LESS_OR_EQUAL

Thanks for the knowledge.

I tried to use FltGetFileNameInformation().
But this function is suppose to be used at irql <= APC.
With driver verifier, the driver is crashing with
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) in this function.
With reference to “Dispatch Routine IRQL and Thread Context”
http://msdn.microsoft.com/en-us/library/ms790762.aspx
the write operation callback should be at APC_LEVEL or PASSIVE level.

Why it is problem with verifier?

Thanks again.

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

Rohan_Nandode-2 · December 23, 2009, 5:17am

Thanks Ayush for your inputs.

The original question was why post write is called at dispatch level when documentation below do not suggest so.
With reference to “Dispatch Routine IRQL and Thread Context” http://msdn.microsoft.com/en-us/library/ms790762.aspx the write operation callback should be at APC_LEVEL or PASSIVE level.

The issue is been resolved by calling FltGetFileNameInformation in pre-operation.

Thanks

Ayush_Gupta-2 · December 24, 2009, 5:10am

The documentation says that Pre-write callback (or in legacy world, the
dispatch routine for IRP_MJ_WRITE) gets called at IRQL <=APC_LEVEL. The post
write callback (or the completion routine in the legacy world) can be called
at IRQL <=DISPATCH_LEVEL.

Regards,
Ayush Gupta
AI Consulting.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, December 23, 2009 3:46 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Minifilter callback parameters access result
IRQL_NOT_LESS_OR_EQUAL

Thanks Ayush for your inputs.

The original question was why post write is called at dispatch level when
documentation below do not suggest so.
With reference to “Dispatch Routine IRQL and Thread Context”
http://msdn.microsoft.com/en-us/library/ms790762.aspx the write operation
callback should be at APC_LEVEL or PASSIVE level.

The issue is been resolved by calling FltGetFileNameInformation in
pre-operation.

Thanks

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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