Hello,
I have some minidumps from http://winqual.microsoft.com with FltGetFileNameInformation crashes inside fltmgr.sys (OS: Windows Vista RTM).
in my PostCreate callback I only call:
RtlZeroMemory( &nameInfo, sizeof( nameInfo ));
FltGetFileNameInformation( Data, FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT, &nameInfo );
before I call that fn I check lot of things:
if ( !NT_SUCCESS( Data->IoStatus.Status ) ||
STATUS_REPARSE == Data->IoStatus.Status ||
STATUS_OPLOCK_BREAK_IN_PROGRESS == Data->IoStatus.Status ||
FlagOn( Flags, FLTFL_POST_OPERATION_DRAINING ) ||
!fltObjects || !fltObjects->FileObject || !fltObjects->Instance || !fltObjects->Volume || …
) { return FLT_POSTOP_FINISHED_PROCESSING; }
and callstack is:
ChildEBP RetAddr Args to Child
a23eb68c 82b5a3a3 00000034 87546ca8 a23eb6c8 fltmgr!TargetedIOCtrlAttachAsFoCtx+0x97 (FPO: [Non-Fpo])
a23eb6e0 82b5a6fb 00000000 863c4318 a23eb71c fltmgr!FltpNormalizeNameComponent+0x127 (FPO: [Non-Fpo])
a23eb6f0 82b5aaf0 863c4318 00000000 863c4318 fltmgr!FltpCallNormalizeNameComponentHandler+0x7f (FPO: [Non-Fpo])
a23eb71c 82b5ba25 013c4318 863c4318 863c4318 fltmgr!FltpExpandShortNames+0x138 (FPO: [Non-Fpo])
a23eb738 82b5c129 863c0000 863c4318 8641020c fltmgr!FltpGetNormalizedFileNameWorker+0xab (FPO: [Non-Fpo])
a23eb750 82b5951f 863c4318 863c4318 8731ba70 fltmgr!FltpGetNormalizedFileName+0x19 (FPO: [Non-Fpo])
a23eb768 82b595aa 863c4318 00000000 863c4318 fltmgr!FltpCreateFileNameInformation+0x81 (FPO: [Non-Fpo])
a23eb77c 82b45202 863c4318 00000000 00000000 fltmgr!CreateTemporaryFileNameInformation+0x4e (FPO: [Non-Fpo])
a23eb7ac 82b4537c 863c4318 a23eb800 a23eb8a4 fltmgr!FltpGetFileNameInformation+0x60a (FPO: [Non-Fpo])
a23eb7d4 a22f261f 00319488 00000101 a23eb7fc fltmgr!FltGetFileNameInformation+0x120 (FPO: [Non-Fpo])
a23eb820 a2300a0c a23eb908 87319488 a23eb8a4 aswMonFlt!AvMonGetFullPath+0xc5 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\400\residents\aswmonflt\fncs.c @ 143]
a23eb8e4 82b3f12d 87319488 a23eb908 00000000 aswMonFlt!fltPostCreate+0x8e (FPO: [Non-Fpo]) (CONV: stdcall) [d:\400\residents\aswmonflt\fnchooked.c @ 198]
a23eb948 82b41fa8 00319428 00000000 87319428 fltmgr!FltpPerformPostCallbacks+0x1f1 (FPO: [Non-Fpo])
a23eb95c 82b424de 87319428 873cf8d0 a23eb99c fltmgr!FltpProcessIoCompletion+0x10 (FPO: [Non-Fpo])
a23eb96c 82b42aec 87355b58 873cf8d0 87319428 fltmgr!FltpPassThroughCompletion+0x94 (FPO: [Non-Fpo])
a23eb99c 82b54a91 a23eb9bc 00000000 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2ba (FPO: [Non-Fpo])
a23eb9e8 81c67cc9 87355b58 8731b780 874dfb64 fltmgr!FltpCreate+0x2a1 (FPO: [Non-Fpo])
a23eba00 81dc8e57 a23e01f8 873a432c 86401018 nt!IofCallDriver+0x63
a23ebab8 81ddacdd 86401030 00000000 873a4288 nt!IopParseDevice+0xcff
a23ebb48 81dcc94e 00000000 a23ebba0 00000040 nt!ObpLookupObjectName+0x615
inside fltmgr!:TargetedIOCtrlAttachAsFoCtx:
82b5ce4c ff155483b482 call dword ptr [fltmgr!_imp__FsRtlInsertPerFileObjectContext (82b48354)]
82b5ce52 8bd8 mov ebx,eax
82b5ce54 85db test ebx,ebx
82b5ce56 7c53 jl fltmgr!TargetedIOCtrlAttachAsFoCtx+0xdd (82b5ceab)
82b5ce58 8b07 mov eax,dword ptr [edi]
82b5ce5a 8b4024 mov eax,dword ptr [eax+24h]
82b5ce5d 33c9 xor ecx,ecx
82b5ce5f 0588030000 add eax,388h
82b5ce64 41 inc ecx
82b5ce65 f00fc108 lock xadd dword ptr [eax],ecx ds:0023:00000388=??? << *** CRASH ***
82b5ce69 66834e0604 or word ptr [esi+6],4
82b5ce6e 66837e0400 cmp word ptr [esi+4],0
82b5ce73 7536 jne fltmgr!TargetedIOCtrlAttachAsFoCtx+0xdd (82b5ceab)
actual registers:
eax=00000388 ebx=00000000 ecx=00000001 edx=00000000 esi=87486504 edi=87486514
eip=82b5ce65 esp=a23eb67c ebp=a23eb68c iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
fltmgr!TargetedIOCtrlAttachAsFoCtx+0x97:
82b5ce65 f00fc108 lock xadd dword ptr [eax],ecx ds:0023:00000388=???
it looks like a FO/Ctx is NULL…
if you have any ideas, please let me know.
thanks,
Petr Kurtin
xxxxx@asw.cz wrote:
Hello,
I have some minidumps from http://winqual.microsoft.com with FltGetFileNameInformation crashes inside fltmgr.sys (OS: Windows Vista RTM).
in my PostCreate callback I only call:
RtlZeroMemory( &nameInfo, sizeof( nameInfo ));
FltGetFileNameInformation( Data, FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT, &nameInfo );
Check the return value here - not all files have a name (open by ID).
You have to handle that.
You can only call this during IRP_MJ_CREATE of course (looks like you
are in this case).
There are probably other restrictions… personally I’d avoid calling it
in postop & call it in preop instead, just in case another filter is
trashing the name buffer after the open has succeeded.
Tony
GetFileNameInformation may crash if called with FO located on stack (system/internal FO).
BOOLEAN
IsFileObjectOnStack (
PFILE_OBJECT FileObject
)
{
ULONG_PTR stLower;
ULONG_PTR stHigh;
IoGetStackLimits( &stLower, &stHigh );
if ((stLower <= (ULONG_PTR) FileObject) && ((ULONG_PTR)FileObject <= stHigh))
return TRUE;
return FALSE;
}
Hello
If you search this list for terms like ‘stack based file object’ you should
find more information about these strange file obejcts. I believe the good
news is that these beasts are supposed to have dissapeared in vista/longhorn
although I’ve not checked.
Cheers
Lyndon
wrote in message news:xxxxx@ntfsd…
> Hello,
> I have some minidumps from http://winqual.microsoft.com with
> FltGetFileNameInformation crashes inside fltmgr.sys (OS: Windows Vista
> RTM).
>
> in my PostCreate callback I only call:
> RtlZeroMemory( &nameInfo, sizeof( nameInfo ));
> FltGetFileNameInformation( Data, FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_DEFAULT, &nameInfo );
>
> before I call that fn I check lot of things:
> if ( !NT_SUCCESS( Data->IoStatus.Status ) ||
> STATUS_REPARSE == Data->IoStatus.Status ||
> STATUS_OPLOCK_BREAK_IN_PROGRESS == Data->IoStatus.Status ||
> FlagOn( Flags, FLTFL_POST_OPERATION_DRAINING ) ||
> !fltObjects || !fltObjects->FileObject || !fltObjects->Instance ||
> !fltObjects->Volume || …
> ) { return FLT_POSTOP_FINISHED_PROCESSING; }
>
> and callstack is:
> ChildEBP RetAddr Args to Child
> a23eb68c 82b5a3a3 00000034 87546ca8 a23eb6c8
> fltmgr!TargetedIOCtrlAttachAsFoCtx+0x97 (FPO: [Non-Fpo])
> a23eb6e0 82b5a6fb 00000000 863c4318 a23eb71c
> fltmgr!FltpNormalizeNameComponent+0x127 (FPO: [Non-Fpo])
> a23eb6f0 82b5aaf0 863c4318 00000000 863c4318
> fltmgr!FltpCallNormalizeNameComponentHandler+0x7f (FPO: [Non-Fpo])
> a23eb71c 82b5ba25 013c4318 863c4318 863c4318
> fltmgr!FltpExpandShortNames+0x138 (FPO: [Non-Fpo])
> a23eb738 82b5c129 863c0000 863c4318 8641020c
> fltmgr!FltpGetNormalizedFileNameWorker+0xab (FPO: [Non-Fpo])
> a23eb750 82b5951f 863c4318 863c4318 8731ba70
> fltmgr!FltpGetNormalizedFileName+0x19 (FPO: [Non-Fpo])
> a23eb768 82b595aa 863c4318 00000000 863c4318
> fltmgr!FltpCreateFileNameInformation+0x81 (FPO: [Non-Fpo])
> a23eb77c 82b45202 863c4318 00000000 00000000
> fltmgr!CreateTemporaryFileNameInformation+0x4e (FPO: [Non-Fpo])
> a23eb7ac 82b4537c 863c4318 a23eb800 a23eb8a4
> fltmgr!FltpGetFileNameInformation+0x60a (FPO: [Non-Fpo])
> a23eb7d4 a22f261f 00319488 00000101 a23eb7fc
> fltmgr!FltGetFileNameInformation+0x120 (FPO: [Non-Fpo])
> a23eb820 a2300a0c a23eb908 87319488 a23eb8a4
> aswMonFlt!AvMonGetFullPath+0xc5 (FPO: [Non-Fpo]) (CONV: stdcall)
> [d:\400\residents\aswmonflt\fncs.c @ 143]
> a23eb8e4 82b3f12d 87319488 a23eb908 00000000 aswMonFlt!fltPostCreate+0x8e
> (FPO: [Non-Fpo]) (CONV: stdcall) [d:\400\residents\aswmonflt\fnchooked.c @
> 198]
> a23eb948 82b41fa8 00319428 00000000 87319428
> fltmgr!FltpPerformPostCallbacks+0x1f1 (FPO: [Non-Fpo])
> a23eb95c 82b424de 87319428 873cf8d0 a23eb99c
> fltmgr!FltpProcessIoCompletion+0x10 (FPO: [Non-Fpo])
> a23eb96c 82b42aec 87355b58 873cf8d0 87319428
> fltmgr!FltpPassThroughCompletion+0x94 (FPO: [Non-Fpo])
> a23eb99c 82b54a91 a23eb9bc 00000000 00000000
> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2ba (FPO:
> [Non-Fpo])
> a23eb9e8 81c67cc9 87355b58 8731b780 874dfb64 fltmgr!FltpCreate+0x2a1 (FPO:
> [Non-Fpo])
> a23eba00 81dc8e57 a23e01f8 873a432c 86401018 nt!IofCallDriver+0x63
> a23ebab8 81ddacdd 86401030 00000000 873a4288 nt!IopParseDevice+0xcff
> a23ebb48 81dcc94e 00000000 a23ebba0 00000040 nt!ObpLookupObjectName+0x615
>
> inside fltmgr!:TargetedIOCtrlAttachAsFoCtx:
>
> 82b5ce4c ff155483b482 call dword ptr
> [fltmgr!_imp__FsRtlInsertPerFileObjectContext (82b48354)]
> 82b5ce52 8bd8 mov ebx,eax
> 82b5ce54 85db test ebx,ebx
> 82b5ce56 7c53 jl fltmgr!TargetedIOCtrlAttachAsFoCtx+0xdd
> (82b5ceab)
> 82b5ce58 8b07 mov eax,dword ptr [edi]
> 82b5ce5a 8b4024 mov eax,dword ptr [eax+24h]
> 82b5ce5d 33c9 xor ecx,ecx
> 82b5ce5f 0588030000 add eax,388h
> 82b5ce64 41 inc ecx
> 82b5ce65 f00fc108 lock xadd dword ptr [eax],ecx
> ds:0023:00000388=??? << CRASH
> 82b5ce69 66834e0604 or word ptr [esi+6],4
> 82b5ce6e 66837e0400 cmp word ptr [esi+4],0
> 82b5ce73 7536 jne fltmgr!TargetedIOCtrlAttachAsFoCtx+0xdd
> (82b5ceab)
>
> actual registers:
>
> eax=00000388 ebx=00000000 ecx=00000001 edx=00000000 esi=87486504
> edi=87486514
> eip=82b5ce65 esp=a23eb67c ebp=a23eb68c iopl=0 nv up ei pl nz na po
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010202
> fltmgr!TargetedIOCtrlAttachAsFoCtx+0x97:
> 82b5ce65 f00fc108 lock xadd dword ptr [eax],ecx
> ds:0023:00000388=???
>
> it looks like a FO/Ctx is NULL…
> if you have any ideas, please let me know.
>
> thanks,
> Petr Kurtin
>
>
thanks guys!
it seems FO is not located on stack:
0: kd> dt fltmgr!_FLT_RELATED_OBJECTS a23eb908
+0x000 Size : 0x18
+0x002 TransactionContext : 0
+0x004 Filter : 0x8731e760 _FLT_FILTER
+0x008 Volume : 0x8731b780 _FLT_VOLUME
+0x00c Instance : 0x8731ec78 _FLT_INSTANCE
+0x010 FileObject : 0x874dfb08 _FILE_OBJECT
+0x014 Transaction : (null)
0: kd> kv
ChildEBP RetAddr Args to Child
a23eb68c 82b5a3a3 … fltmgr!TargetedIOCtrlAttachAsFoCtx+0x97 (FPO:
[Non-Fpo])
a23eb6e0 82b5a6fb … fltmgr!FltpNormalizeNameComponent+0x127 (FPO:
[Non-Fpo])
…
a23ebb48 81dcc94e … nt!ObpLookupObjectName+0x615
FileObject’s address is 0x874dfb08 – but you’re right it’d be better to
test FO’s location in the driver, thanks.
I’ve made a simple tool for file opening by ID and now I’ll test it with
FltGetFileNameInformation.
thanks,
Petr Kurtin
wrote in message news:xxxxx@ntfsd…
> GetFileNameInformation may crash if called with FO located on stack
> (system/internal FO).
> BOOLEAN
> IsFileObjectOnStack (
> PFILE_OBJECT FileObject
> )
> {
> ULONG_PTR stLower;
> ULONG_PTR stHigh;
>
> IoGetStackLimits( &stLower, &stHigh );
> if ((stLower <= (ULONG_PTR) FileObject) && ((ULONG_PTR)FileObject <=
> stHigh))
> return TRUE;
>
> return FALSE;
> }
>
I guess generally we should not perform FltGetFileNameInformation in post operations as documentation says it should be running “FltGetFileNameInformation must be running at IRQL <= APC_LEVEL”
Thanks
Aishwary Bhashkar
R Systems International Ltd.
I call FltGetFileNameInformation in IRP_MJ_CREATE post-operation, which is
always called in the reqestor’s thread at IRQL <= APC_LEVEL. Moving
FltGetFileNameInformation to IRP_MJ_CREATE pre-operation may invalidate
normalized file name in post-operation (file name tunneling) - but I agree,
it’d be much safer to store file name in pre-operation callback and call
FltGetTunneledName in post-operation callback to see if the name has been
changed.
thanks,
Petr Kurtin
wrote in message news:xxxxx@ntfsd…
>I guess generally we should not perform FltGetFileNameInformation in post
>operations as documentation says it should be running
>“FltGetFileNameInformation must be running at IRQL <= APC_LEVEL”
>
> Thanks
> Aishwary Bhashkar
> R Systems International Ltd.
>
Refer to the previous thread about “File symbolic links in Vista” 
“Petr Kurtin” wrote in message news:xxxxx@ntfsd…
>I call FltGetFileNameInformation in IRP_MJ_CREATE post-operation, which is
>always called in the reqestor’s thread at IRQL <= APC_LEVEL. Moving
>FltGetFileNameInformation to IRP_MJ_CREATE pre-operation may invalidate
>normalized file name in post-operation (file name tunneling) - but I agree,
>it’d be much safer to store file name in pre-operation callback and call
>FltGetTunneledName in post-operation callback to see if the name has been
>changed.
>
> thanks,
> Petr Kurtin
>
>
> wrote in message news:xxxxx@ntfsd…
>>I guess generally we should not perform FltGetFileNameInformation in post
>>operations as documentation says it should be running
>>“FltGetFileNameInformation must be running at IRQL <= APC_LEVEL”
>>
>> Thanks
>> Aishwary Bhashkar
>> R Systems International Ltd.
>>
>
>
>