FltGetFileNameInformation and IRQL

Hi All!

My minifilter is causing a double fault. It happens about once a week, and
so far only on Win2k SP4 Rollup 1.

Today, I was fortunate enough on the last crash to get a FULL memory.dmp.

based on the call stack and the code…

It looks like my minifilter is picking up a rename (srv!DoRename)

and in the processing of it, it calls FltGetFileNameInformation

which is causing a access fault (nt!KiTrap0E) for some reason

then the access fault handling code does something (a
IRP_MJ_READ/IRP_MJ_WRITE or IRP_MJ_CLEANUP (I’m guessing cleanup) ) which my
driver picks up again and causes the final exception for some reason
(nt!KiTrap08)

This call stack was before I added the check to make sure that IRQL before
attempting to any call to FltGetFileNameInformation.

if (KeGetCurrentIrql() > APC_LEVEL) // FltGetFileNameInformation requires
this level of ACCESS.

{

DbgPrint(“IRQL is above APC_LEVEL\n”);

return STATUS_SUCCESS;

}

I’m thinking that I was making the FltGetFileNameInformation when the IRQL
was too high, but honestly I’m just guessing.

Since it’s going to probably be a week before I get another crash, I thought
I would ask if anyone thought my IRQL check will help and for any guidance.

Thanks everyone!

Gene

Here is the call stack:

00000000 edbbe8fe nt!KiTrap08+0x3e

ee3b3974 edbbefed OurFilter!SendToUserMode+0x10
[c:\OurFilter\bssFilter\filter\bssFilter.c @ 694]

ee3b3990 bff534bd OurFilter!PreGenericWithSend+0x31
[c:\OurFilter\bssFilter\filter\bssFilter.c @ 586]

ee3b39bc bff38941 fltmgr!FltvPreOperation+0x3d

ee3b3a20 bff3c162 fltmgr!FltpPerformPreCallbacks+0x24c

ee3b3a34 bff3c12b fltmgr!FltpPassThroughInternal+0x30

ee3b3a50 bff3c7d1 fltmgr!FltpPassThrough+0x1f1

ee3b3a80 805290c4 fltmgr!FltpDispatch+0xfd

ee3b3acc 8041f125 nt!IovSpecialIrpCallDriver+0xcd

ee3b3ae0 80440e2d nt!IoPageRead+0xb1

ee3b3b20 80449c40 nt!MiDispatchFault+0x23d

ee3b3b6c 80467c1f nt!MmAccessFault+0x682

ee3b3b6c bfeae302 nt!KiTrap0E+0xc3

ee3b3cd8 bfeb029a Ntfs!NtfsAccessCheck+0x62

ee3b3d08 bfeb00ab Ntfs!NtfsCheckExistingFile+0x80

ee3b3d30 bfeb0494 Ntfs!NtfsOpenExistingAttr+0x21

ee3b3e40 bfedaf1d Ntfs!NtfsOpenAttributeInExistingFile+0x1ae

ee3b3f4c bfed9ee7 Ntfs!NtfsOpenExistingPrefixFcb+0x339

ee3b426c bfeaa666 Ntfs!NtfsCommonCreate+0x17f7

ee3b4320 805290c4 Ntfs!NtfsFsdCreate+0x186

ee3b436c 804bf978 nt!IovSpecialIrpCallDriver+0xcd

ee3b44fc 80450893 nt!IopParseDevice+0xabe

ee3b4574 804d59a0 nt!ObpLookupObjectName+0x4e7

ee3b4684 8049f9f1 nt!ObOpenObjectByName+0xc8

ee3b4760 8049f5e6 nt!IopCreateFile+0x407

ee3b47a8 bff501b0 nt!IoCreateFileSpecifyDeviceObjectHint+0x4c

ee3b481c bff50d65 fltmgr!FltpNormalizeNameComponent+0x70

ee3b4824 bff4f991 fltmgr!FltpCallNormalizeNameComponentHandler+0x39

ee3b4850 bff503fd fltmgr!FltpExpandShortNames+0x10f

ee3b486c bff5027d fltmgr!FltpGetNormalizedFileNameWorker+0xb1

ee3b4884 bff4e8c4 fltmgr!FltpGetNormalizedFileName+0x17

ee3b489c bff3ee54 fltmgr!FltpCreateFileNameInformation+0xc4

ee3b48cc bff3f299 fltmgr!FltpGetFileNameInformation+0x2ac

ee3b48f8 edbbe96d fltmgr!FltGetFileNameInformation+0x127

ee3b55b0 edbbefb0 OurFilter!SendToUserMode+0x7f
[c:\OurFilter\bssFilter\filter\bssFilter.c @ 748]

ee3b55c8 bff53537 OurFilter!PostGeneric+0x1e
[c:\OurFilter\bssFilter\filter\bssFilter.c @ 506]

ee3b55ec bff38e7e fltmgr!FltvPostOperation+0x4b

ee3b5654 bff3c4f2 fltmgr!FltpPerformPostCallbacks+0x1ca

ee3b5664 bff3c637 fltmgr!FltpProcessIoCompletion+0xc

ee3b5670 bff3c42c fltmgr!FltpPassThroughCompletion+0xa4

ee3b56a0 bff47e5f
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x26c

ee3b56dc 805290c4 fltmgr!FltpCreate+0x29d

ee3b5728 804bf978 nt!IovSpecialIrpCallDriver+0xcd

ee3b58b8 804bfeb8 nt!IopParseDevice+0xabe

ee3b58f0 8045049d nt!IopParseFile+0x44

ee3b5968 804d59a0 nt!ObpLookupObjectName+0xf1

ee3b5a78 8049f9f1 nt!ObOpenObjectByName+0xc8

ee3b5b54 8049f596 nt!IopCreateFile+0x407

ee3b5b9c eedfd7cc nt!IoCreateFile+0x36

ee3b5c70 eedf3cad srv!SrvFind2Loop+0x856

ee3b5cd8 eee058b0 srv!SrvLogError+0x2f

ee3b5d68 eeded7ae srv!DoRename+0x1c1

ee3b5da8 80454a24 srv!SrvFindCachedRfcb+0x12b

ee3b5df8 00000000 nt!PspSystemThreadStartup+0x54

Gene,

Bug check 0x7F (Unexpected kernel mode trap) with first parameter 8 is
normally a stack overflow (where “normally” here means “the only case
*I* have ever seen”) - and that’s what it looks like from your stack
trace as well (notice the large divide between the starting EBP values
and the ending EBP values.) Is the faulting instruction something
innocuous like a “push xxx” instruction?

Running verifier is no doubt exacerbating this problem, but you might
also wish to audit your code and cut your own stack usage (if you work
hard, you can actually cut it to one local variable per call frame by
creating a structure definition and allocating the memory from non-paged
pool, but that’s pretty extreme; often just getting rid of locally
allocated buffers will be sufficient.

In later OS versions, MS has done quite a bit of work to minimize their
own stack usage, so you might not be seeing this issue as a result of
that work in later OS versions.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 24-27, 2006.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gene Allen
Sent: Friday, December 09, 2005 9:54 PM
To: ntfsd redirect
Subject: [ntfsd] FltGetFileNameInformation and IRQL

Hi All!

My minifilter is causing a double fault. It happens about once a week,
and
so far only on Win2k SP4 Rollup 1.

Today, I was fortunate enough on the last crash to get a FULL
memory.dmp.

based on the call stack and the code…

It looks like my minifilter is picking up a rename (srv!DoRename)

and in the processing of it, it calls FltGetFileNameInformation

which is causing a access fault (nt!KiTrap0E) for some reason

then the access fault handling code does something (a
IRP_MJ_READ/IRP_MJ_WRITE or IRP_MJ_CLEANUP (I’m guessing cleanup) )
which my
driver picks up again and causes the final exception for some reason
(nt!KiTrap08)

This call stack was before I added the check to make sure that IRQL
before
attempting to any call to FltGetFileNameInformation.

if (KeGetCurrentIrql() > APC_LEVEL) // FltGetFileNameInformation
requires
this level of ACCESS.

{

DbgPrint(“IRQL is above APC_LEVEL\n”);

return STATUS_SUCCESS;

}

I’m thinking that I was making the FltGetFileNameInformation when the
IRQL
was too high, but honestly I’m just guessing.

Since it’s going to probably be a week before I get another crash, I
thought
I would ask if anyone thought my IRQL check will help and for any
guidance.

Thanks everyone!

Gene

Here is the call stack:

00000000 edbbe8fe nt!KiTrap08+0x3e

ee3b3974 edbbefed OurFilter!SendToUserMode+0x10
[c:\OurFilter\bssFilter\filter\bssFilter.c @ 694]

ee3b3990 bff534bd OurFilter!PreGenericWithSend+0x31
[c:\OurFilter\bssFilter\filter\bssFilter.c @ 586]

ee3b39bc bff38941 fltmgr!FltvPreOperation+0x3d

ee3b3a20 bff3c162 fltmgr!FltpPerformPreCallbacks+0x24c

ee3b3a34 bff3c12b fltmgr!FltpPassThroughInternal+0x30

ee3b3a50 bff3c7d1 fltmgr!FltpPassThrough+0x1f1

ee3b3a80 805290c4 fltmgr!FltpDispatch+0xfd

ee3b3acc 8041f125 nt!IovSpecialIrpCallDriver+0xcd

ee3b3ae0 80440e2d nt!IoPageRead+0xb1

ee3b3b20 80449c40 nt!MiDispatchFault+0x23d

ee3b3b6c 80467c1f nt!MmAccessFault+0x682

ee3b3b6c bfeae302 nt!KiTrap0E+0xc3

ee3b3cd8 bfeb029a Ntfs!NtfsAccessCheck+0x62

ee3b3d08 bfeb00ab Ntfs!NtfsCheckExistingFile+0x80

ee3b3d30 bfeb0494 Ntfs!NtfsOpenExistingAttr+0x21

ee3b3e40 bfedaf1d Ntfs!NtfsOpenAttributeInExistingFile+0x1ae

ee3b3f4c bfed9ee7 Ntfs!NtfsOpenExistingPrefixFcb+0x339

ee3b426c bfeaa666 Ntfs!NtfsCommonCreate+0x17f7

ee3b4320 805290c4 Ntfs!NtfsFsdCreate+0x186

ee3b436c 804bf978 nt!IovSpecialIrpCallDriver+0xcd

ee3b44fc 80450893 nt!IopParseDevice+0xabe

ee3b4574 804d59a0 nt!ObpLookupObjectName+0x4e7

ee3b4684 8049f9f1 nt!ObOpenObjectByName+0xc8

ee3b4760 8049f5e6 nt!IopCreateFile+0x407

ee3b47a8 bff501b0 nt!IoCreateFileSpecifyDeviceObjectHint+0x4c

ee3b481c bff50d65 fltmgr!FltpNormalizeNameComponent+0x70

ee3b4824 bff4f991 fltmgr!FltpCallNormalizeNameComponentHandler+0x39

ee3b4850 bff503fd fltmgr!FltpExpandShortNames+0x10f

ee3b486c bff5027d fltmgr!FltpGetNormalizedFileNameWorker+0xb1

ee3b4884 bff4e8c4 fltmgr!FltpGetNormalizedFileName+0x17

ee3b489c bff3ee54 fltmgr!FltpCreateFileNameInformation+0xc4

ee3b48cc bff3f299 fltmgr!FltpGetFileNameInformation+0x2ac

ee3b48f8 edbbe96d fltmgr!FltGetFileNameInformation+0x127

ee3b55b0 edbbefb0 OurFilter!SendToUserMode+0x7f
[c:\OurFilter\bssFilter\filter\bssFilter.c @ 748]

ee3b55c8 bff53537 OurFilter!PostGeneric+0x1e
[c:\OurFilter\bssFilter\filter\bssFilter.c @ 506]

ee3b55ec bff38e7e fltmgr!FltvPostOperation+0x4b

ee3b5654 bff3c4f2 fltmgr!FltpPerformPostCallbacks+0x1ca

ee3b5664 bff3c637 fltmgr!FltpProcessIoCompletion+0xc

ee3b5670 bff3c42c fltmgr!FltpPassThroughCompletion+0xa4

ee3b56a0 bff47e5f
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x26c

ee3b56dc 805290c4 fltmgr!FltpCreate+0x29d

ee3b5728 804bf978 nt!IovSpecialIrpCallDriver+0xcd

ee3b58b8 804bfeb8 nt!IopParseDevice+0xabe

ee3b58f0 8045049d nt!IopParseFile+0x44

ee3b5968 804d59a0 nt!ObpLookupObjectName+0xf1

ee3b5a78 8049f9f1 nt!ObOpenObjectByName+0xc8

ee3b5b54 8049f596 nt!IopCreateFile+0x407

ee3b5b9c eedfd7cc nt!IoCreateFile+0x36

ee3b5c70 eedf3cad srv!SrvFind2Loop+0x856

ee3b5cd8 eee058b0 srv!SrvLogError+0x2f

ee3b5d68 eeded7ae srv!DoRename+0x1c1

ee3b5da8 80454a24 srv!SrvFindCachedRfcb+0x12b

ee3b5df8 00000000 nt!PspSystemThreadStartup+0x54


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

One nice feature of Driver Prefast is that you can specify a stack usage
limit that it will check. I like 256 instead of the default 1024. I don’t
think it is a full stack usage check but just a function by function test.
You can instrument your driver to check the stack usage and if it drops
below 8k or 4k or some other value that makes sense in your driver, have it
display or bug check.

“Tony Mason” wrote in message news:xxxxx@ntfsd…
Gene,

Bug check 0x7F (Unexpected kernel mode trap) with first parameter 8 is
normally a stack overflow (where “normally” here means “the only case
I have ever seen”) - and that’s what it looks like from your stack
trace as well (notice the large divide between the starting EBP values
and the ending EBP values.) Is the faulting instruction something
innocuous like a “push xxx” instruction?

Running verifier is no doubt exacerbating this problem, but you might
also wish to audit your code and cut your own stack usage (if you work
hard, you can actually cut it to one local variable per call frame by
creating a structure definition and allocating the memory from non-paged
pool, but that’s pretty extreme; often just getting rid of locally
allocated buffers will be sufficient.

In later OS versions, MS has done quite a bit of work to minimize their
own stack usage, so you might not be seeing this issue as a result of
that work in later OS versions.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 24-27, 2006.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gene Allen
Sent: Friday, December 09, 2005 9:54 PM
To: ntfsd redirect
Subject: [ntfsd] FltGetFileNameInformation and IRQL

Hi All!

My minifilter is causing a double fault. It happens about once a week,
and
so far only on Win2k SP4 Rollup 1.

Today, I was fortunate enough on the last crash to get a FULL
memory.dmp.

based on the call stack and the code…

It looks like my minifilter is picking up a rename (srv!DoRename)

and in the processing of it, it calls FltGetFileNameInformation

which is causing a access fault (nt!KiTrap0E) for some reason

then the access fault handling code does something (a
IRP_MJ_READ/IRP_MJ_WRITE or IRP_MJ_CLEANUP (I’m guessing cleanup) )
which my
driver picks up again and causes the final exception for some reason
(nt!KiTrap08)

This call stack was before I added the check to make sure that IRQL
before
attempting to any call to FltGetFileNameInformation.

if (KeGetCurrentIrql() > APC_LEVEL) // FltGetFileNameInformation
requires
this level of ACCESS.

{

DbgPrint(“IRQL is above APC_LEVEL\n”);

return STATUS_SUCCESS;

}

I’m thinking that I was making the FltGetFileNameInformation when the
IRQL
was too high, but honestly I’m just guessing.

Since it’s going to probably be a week before I get another crash, I
thought
I would ask if anyone thought my IRQL check will help and for any
guidance.

Thanks everyone!

Gene

Here is the call stack:

00000000 edbbe8fe nt!KiTrap08+0x3e

ee3b3974 edbbefed OurFilter!SendToUserMode+0x10
[c:\OurFilter\bssFilter\filter\bssFilter.c @ 694]

ee3b3990 bff534bd OurFilter!PreGenericWithSend+0x31
[c:\OurFilter\bssFilter\filter\bssFilter.c @ 586]

ee3b39bc bff38941 fltmgr!FltvPreOperation+0x3d

ee3b3a20 bff3c162 fltmgr!FltpPerformPreCallbacks+0x24c

ee3b3a34 bff3c12b fltmgr!FltpPassThroughInternal+0x30

ee3b3a50 bff3c7d1 fltmgr!FltpPassThrough+0x1f1

ee3b3a80 805290c4 fltmgr!FltpDispatch+0xfd

ee3b3acc 8041f125 nt!IovSpecialIrpCallDriver+0xcd

ee3b3ae0 80440e2d nt!IoPageRead+0xb1

ee3b3b20 80449c40 nt!MiDispatchFault+0x23d

ee3b3b6c 80467c1f nt!MmAccessFault+0x682

ee3b3b6c bfeae302 nt!KiTrap0E+0xc3

ee3b3cd8 bfeb029a Ntfs!NtfsAccessCheck+0x62

ee3b3d08 bfeb00ab Ntfs!NtfsCheckExistingFile+0x80

ee3b3d30 bfeb0494 Ntfs!NtfsOpenExistingAttr+0x21

ee3b3e40 bfedaf1d Ntfs!NtfsOpenAttributeInExistingFile+0x1ae

ee3b3f4c bfed9ee7 Ntfs!NtfsOpenExistingPrefixFcb+0x339

ee3b426c bfeaa666 Ntfs!NtfsCommonCreate+0x17f7

ee3b4320 805290c4 Ntfs!NtfsFsdCreate+0x186

ee3b436c 804bf978 nt!IovSpecialIrpCallDriver+0xcd

ee3b44fc 80450893 nt!IopParseDevice+0xabe

ee3b4574 804d59a0 nt!ObpLookupObjectName+0x4e7

ee3b4684 8049f9f1 nt!ObOpenObjectByName+0xc8

ee3b4760 8049f5e6 nt!IopCreateFile+0x407

ee3b47a8 bff501b0 nt!IoCreateFileSpecifyDeviceObjectHint+0x4c

ee3b481c bff50d65 fltmgr!FltpNormalizeNameComponent+0x70

ee3b4824 bff4f991 fltmgr!FltpCallNormalizeNameComponentHandler+0x39

ee3b4850 bff503fd fltmgr!FltpExpandShortNames+0x10f

ee3b486c bff5027d fltmgr!FltpGetNormalizedFileNameWorker+0xb1

ee3b4884 bff4e8c4 fltmgr!FltpGetNormalizedFileName+0x17

ee3b489c bff3ee54 fltmgr!FltpCreateFileNameInformation+0xc4

ee3b48cc bff3f299 fltmgr!FltpGetFileNameInformation+0x2ac

ee3b48f8 edbbe96d fltmgr!FltGetFileNameInformation+0x127

ee3b55b0 edbbefb0 OurFilter!SendToUserMode+0x7f
[c:\OurFilter\bssFilter\filter\bssFilter.c @ 748]

ee3b55c8 bff53537 OurFilter!PostGeneric+0x1e
[c:\OurFilter\bssFilter\filter\bssFilter.c @ 506]

ee3b55ec bff38e7e fltmgr!FltvPostOperation+0x4b

ee3b5654 bff3c4f2 fltmgr!FltpPerformPostCallbacks+0x1ca

ee3b5664 bff3c637 fltmgr!FltpProcessIoCompletion+0xc

ee3b5670 bff3c42c fltmgr!FltpPassThroughCompletion+0xa4

ee3b56a0 bff47e5f
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x26c

ee3b56dc 805290c4 fltmgr!FltpCreate+0x29d

ee3b5728 804bf978 nt!IovSpecialIrpCallDriver+0xcd

ee3b58b8 804bfeb8 nt!IopParseDevice+0xabe

ee3b58f0 8045049d nt!IopParseFile+0x44

ee3b5968 804d59a0 nt!ObpLookupObjectName+0xf1

ee3b5a78 8049f9f1 nt!ObOpenObjectByName+0xc8

ee3b5b54 8049f596 nt!IopCreateFile+0x407

ee3b5b9c eedfd7cc nt!IoCreateFile+0x36

ee3b5c70 eedf3cad srv!SrvFind2Loop+0x856

ee3b5cd8 eee058b0 srv!SrvLogError+0x2f

ee3b5d68 eeded7ae srv!DoRename+0x1c1

ee3b5da8 80454a24 srv!SrvFindCachedRfcb+0x12b

ee3b5df8 00000000 nt!PspSystemThreadStartup+0x54


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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