0x7F crash on IoCreateFileSpecifyDeviceObjectHint()

NTFSD
1

Hi All,
When my filter driver is testing, I got one time 0x7F crash on
IoCreateFileSpecifyDeviceObjectHint().
I have several questions and attach memory dump analysis in here.

  1. From memory dump analysis, I consider this is a stack overflow caused
    by reentrancy. Am I right or not?

  2. In file system driver stack, there are three filter drivers above
    file system driver. My filter driver is in middle. Symatec AntiVirus
    software is under my filter(savrt.sys is one of drivers in Symatec
    AntiVirus). Another antivirus software TrendMicro (TmPreFlt.sys is the
    driver of TrendMicro) is above of my driver. When I need to open a file in
    post IRP_MJ_CREATE, I call IoCreateFileSpecifyDeviceObjectHint() to prevent
    reentrancy. In that case, how can I find some extra evidences to figure
    out if this double fault is really caused by my driver or other driver(I
    guess Symatec AntiVirus driver savrt.sys might not handle reentrancy
    properly)?

  3. In my filter driver, I didn’t wrap IoCreateFileSpecifyDeviceObjectHint()
    with try-exception block. Will try-exception block help to prevent this
    problem? Is there any way to detect if an IRP_MJ_CREATE is a reentrancy
    IRP?

Thanks for advice.

*******************************Memory dump analysis ********************

BugCheck 7F, {8, 80042000, 0, 0}

*** ERROR: Symbol file could not be found. Defaulted to export symbols for
TmPreFlt.sys -
*** ERROR: Module load completed but symbols could not be loaded for
savrt.sys
Probably caused by : fsfilter.sys ( fsfilter!fsStreamFileCreate+28a )

Followup: MachineOwner

kd> !analyze -v
**********************************************************************
* *
* Bugcheck Analysis *
* *
**********************************************************************

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck parens is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 80042000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

BUGCHECK_STR: 0x7f_8

TSS: 00000028 – (.tss 28)
eax=867ed100 ebx=86f71100 ecx=867ed148 edx=8670d618 esi=ab5be0dc
edi=8670d760
eip=f73c33e3 esp=ab5be000 ebp=ab5be01c iopl=0 vif nv up ei pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00090246
Ntfs!ExAllocateFromPagedLookasideList+0x2:
f73c33e3 55 push ebp
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from f73c1644 to f73c33e3

STACK_TEXT:
Ntfs!ExAllocateFromPagedLookasideList+0x2
Ntfs!NtfsInitializeIrpContext+0x8b
Ntfs!NtfsFsdCreate+0xda
nt!IopfCallDriver+0x31
nt!IopParseDevice+0xa58
nt!ObpLookupObjectName+0x56a
nt!ObOpenObjectByName+0xeb
nt!IopCreateFile+0x407
nt!IoCreateFileSpecifyDeviceObjectHint+0x52
fsfilter!fsStreamFileCreate+0x28a
fsfilter!fsCreateDispatch+0x5a6
fsfilter!fsPassThrough+0x9b
nt!IopfCallDriver+0x31
WARNING: Stack unwind information not available. Following frames may be
wrong.
TmPreFlt!TmpQueryFullName+0x5ba4
nt!IopfCallDriver+0x31
nt!IopParseDevice+0xa58
nt!ObpLookupObjectName+0x56a
nt!ObOpenObjectByName+0xeb
nt!IopCreateFile+0x407
nt!IoCreateFile+0x8e
savrt+0x3e656
savrt+0x4116f
savrt+0x15b42

2

Multiple anti-virus programs usually do not work together. Putting three on
one stack sounds like a sure way to double fault. No - you may not detect
stack overflow (underflow?) via a SEH block or any other method other than
the stack remaining call that can let you know you are in trouble, but not
how much trouble. Ordering of file system filters is another problem for
which the only solution is the minifilter. Too many FSFDs don’t handle that
call well. Microsoft and OSR provided guidance on how to do what those
filters need to do, but so many just don’t get it correct or even try. I
see so many posts from developers who are trying to use an old version of
filemon which is definitely the wrong example to follow for several reasons
which have been enumerated in the past.

“David Wu” wrote in message news:xxxxx@ntfsd…
> Hi All,
> When my filter driver is testing, I got one time 0x7F crash on
> IoCreateFileSpecifyDeviceObjectHint().
> I have several questions and attach memory dump analysis in here.
>
> 1) From memory dump analysis, I consider this is a stack overflow caused
> by reentrancy. Am I right or not?
>
> 2) In file system driver stack, there are three filter drivers above
> file system driver. My filter driver is in middle. Symatec AntiVirus
> software is under my filter(savrt.sys is one of drivers in Symatec
> AntiVirus). Another antivirus software TrendMicro (TmPreFlt.sys is the
> driver of TrendMicro) is above of my driver. When I need to open a file in
> post IRP_MJ_CREATE, I call IoCreateFileSpecifyDeviceObjectHint() to
> prevent
> reentrancy. In that case, how can I find some extra evidences to figure
> out if this double fault is really caused by my driver or other driver(I
> guess Symatec AntiVirus driver savrt.sys might not handle reentrancy
> properly)?
>
> 3) In my filter driver, I didn’t wrap
> IoCreateFileSpecifyDeviceObjectHint()
> with try-exception block. Will try-exception block help to prevent this
> problem? Is there any way to detect if an IRP_MJ_CREATE is a reentrancy
> IRP?
>
> Thanks for advice.
>
>
> ***********Memory dump analysis
>
> BugCheck 7F, {8, 80042000, 0, 0}
>
> ERROR: Symbol file could not be found. Defaulted to export symbols
> for
> TmPreFlt.sys -
> ERROR: Module load completed but symbols could not be loaded for
> savrt.sys
> Probably caused by : fsfilter.sys ( fsfilter!fsStreamFileCreate+28a )
>
> Followup: MachineOwner
> ---------
>
> kd> !analyze -v
> ***
> *
> * Bugcheck Analysis
> *
>
>
> UNEXPECTED_KERNEL_MODE_TRAP (7f)
> This means a trap occurred in kernel mode, and it’s a trap of a kind
> that the kernel isn’t allowed to have/catch (bound trap) or that
> is always instant death (double fault). The first number in the
> bugcheck parens is the number of the trap (8 = double fault, etc)
> Consult an Intel x86 family manual to learn more about what these
> traps are. Here is a portion of those codes:
> If kv shows a taskGate
> use .tss on the part before the colon, then kv.
> Else if kv shows a trapframe
> use .trap on that value
> Else
> .trap on the appropriate frame will show where the trap was taken
> (on x86, this will be the ebp that goes with the procedure KiTrap)
> Endif
> kb will then show the corrected stack.
> Arguments:
> Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
> Arg2: 80042000
> Arg3: 00000000
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: 0x7f_8
>
> TSS: 00000028 – (.tss 28)
> eax=867ed100 ebx=86f71100 ecx=867ed148 edx=8670d618 esi=ab5be0dc
> edi=8670d760
> eip=f73c33e3 esp=ab5be000 ebp=ab5be01c iopl=0 vif nv up ei pl zr na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00090246
> Ntfs!ExAllocateFromPagedLookasideList+0x2:
> f73c33e3 55 push ebp
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> LAST_CONTROL_TRANSFER: from f73c1644 to f73c33e3
>
> STACK_TEXT:
> Ntfs!ExAllocateFromPagedLookasideList+0x2
> Ntfs!NtfsInitializeIrpContext+0x8b
> Ntfs!NtfsFsdCreate+0xda
> nt!IopfCallDriver+0x31
> nt!IopParseDevice+0xa58
> nt!ObpLookupObjectName+0x56a
> nt!ObOpenObjectByName+0xeb
> nt!IopCreateFile+0x407
> nt!IoCreateFileSpecifyDeviceObjectHint+0x52
> fsfilter!fsStreamFileCreate+0x28a
> fsfilter!fsCreateDispatch+0x5a6
> fsfilter!fsPassThrough+0x9b
> nt!IopfCallDriver+0x31
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> TmPreFlt!TmpQueryFullName+0x5ba4
> nt!IopfCallDriver+0x31
> nt!IopParseDevice+0xa58
> nt!ObpLookupObjectName+0x56a
> nt!ObOpenObjectByName+0xeb
> nt!IopCreateFile+0x407
> nt!IoCreateFile+0x8e
> savrt+0x3e656
> savrt+0x4116f
> savrt+0x15b42
>
>
>