RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

NTFSD
1

Hi All,

I am using FltGetDestinationFileNameInformation to get the FileName
information during rename. But i am consistently seeing the
RDR_FILE_SYSTEM(27)crash.

I believe, This issue has been discussed here earlier. But there was no
resolution in the discussion.
Does anyone knows what rule i am break or weather i can call
“FltGetDestinationFileNameInformation” during rename or not.

thanks in advance.
Here is the stack trace, File Object and Rename Information.

Original File Name:
“\TDCEN2V9.prod.travp.net\Ops_Sys\Ops_Sys_default\0077_PASD\inbound\FN{25220858-803B-42DE-BE9C-978EF5E7F21F}{B38B6CBF-1B3A-4C89-91A7-C35FE8DC08FE}”

Rename Information:

dt 0x8c0ca3b0 _FILE_RENAME_INFORMATION
vfiltr!_FILE_RENAME_INFORMATION
+0x000 ReplaceIfExists : 0 ‘’
+0x004 RootDirectory : (null)
+0x008 FileNameLength : 0x178
+0x00c FileName :
“??\UNC\prod.travp.net\ent_dfs\ent_apps\Filenet\DPPT\Ops_Sys\Ops_Sys_default
\0077_PASD\content\FN9\FN12\FN{25220858-803B-42DE-BE9C-978EF5E7F21F}{9FA50757
-90D8-4263-A629-53E5043B742A}-0.doc蟌羝FE倠跍г???”

File Object:

0: kd> dt 0x8d3913a0 _FILE_OBJECT
nt!_FILE_OBJECT
+0x000 Type : 5
+0x002 Size : 112
+0x004 DeviceObject : 0x90acf030 _DEVICE_OBJECT
+0x008 Vpb : (null)
+0x00c FsContext : 0xe4331008
+0x010 FsContext2 : 0xe23bfa00
+0x014 SectionObjectPointer : 0x8cb0f374 _SECTION_OBJECT_POINTERS
+0x018 PrivateCacheMap : (null)
+0x01c FinalStatus : 0
+0x020 RelatedFileObject : (null)
+0x024 LockOperation : 0 ‘’
+0x025 DeletePending : 0 ‘’
+0x026 ReadAccess : 0 ‘’
+0x027 WriteAccess : 0 ‘’
+0x028 DeleteAccess : 0x1 ‘’
+0x029 SharedRead : 0x1 ‘’
+0x02a SharedWrite : 0x1 ‘’
+0x02b SharedDelete : 0x1 ‘’
+0x02c Flags : 0x41002
+0x030 FileName : _UNICODE_STRING
“\TDCEN2V9.prod.travp.net\Ops_Sys\Ops_Sys_default\0077_PASD\inbound\FN{25220858-803B-42DE-BE9C-978EF5E7F21F}{B38B6CBF-1B3A-4C89-91A7-C35FE8DC08FE}”
+0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
+0x040 Waiters : 0
+0x044 Busy : 1
+0x048 LastLock : (null)
+0x04c Lock : _KEVENT
+0x05c Event : _KEVENT
+0x06c CompletionContext : (null)

Stack Trace:

RDR_FILE_SYSTEM (27)
If you see RxExceptionFilter on the stack then the 2nd and 3rd
parameters are the
exception record and context record. Do a .cxr on the 3rd parameter
and then kb to
obtain a more informative stack trace.
The high 16 bits of the first parameter is the RDBSS bugcheck code,
which is defined
as follows:
RDBSS_BUG_CHECK_CACHESUP = 0xca550000,
RDBSS_BUG_CHECK_CLEANUP = 0xc1ee0000,
RDBSS_BUG_CHECK_CLOSE = 0xc10e0000,
RDBSS_BUG_CHECK_NTEXCEPT = 0xbaad0000,
Arguments:
Arg1: baad0080
Arg2: b609acb8
Arg3: b609a9b4
Arg4: b86f0b22

Debugging Details:

Page 7c9bb not present in the dump file. Type “.hh dbgerr004” for details
Page 27febb not present in the dump file. Type “.hh dbgerr004” for details
PEB is paged out (Peb.Ldr = 7ffd700c). Type “.hh dbgerr001” for details
PEB is paged out (Peb.Ldr = 7ffd700c). Type “.hh dbgerr001” for details

EXCEPTION_RECORD: b609acb8 – (.exr 0xffffffffb609acb8)
ExceptionAddress: b86f0b22 (rdbss!RxIsThisACscAgentOpen+0x00000038)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000008
Attempt to read from address 00000008

CONTEXT: b609a9b4 – (.cxr 0xffffffffb609a9b4)
eax=00000000 ebx=b86f0b02 ecx=00000009 edx=00000000 esi=00000008
edi=b86f0b02
eip=b86f0b22 esp=b609ad80 ebp=b609ad90 iopl=0 nv up ei pl zr na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
rdbss!RxIsThisACscAgentOpen+0x38:
b86f0b22 f3a6 repe cmps byte ptr [esi],byte ptr es:[edi]
Resetting default scope

PROCESS_NAME: java.exe

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 00000008

READ_ADDRESS: 00000008

FOLLOWUP_IP:
rdbss!RxIsThisACscAgentOpen+38
b86f0b22 f3a6 repe cmps byte ptr [esi],byte ptr es:[edi]

FAULTING_IP:
rdbss!RxIsThisACscAgentOpen+38
b86f0b22 f3a6 repe cmps byte ptr [esi],byte ptr es:[edi]

BUGCHECK_STR: 0x27

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from b86fecf0 to b86f0b22

STACK_TEXT:
b609ad90 b86fecf0 8d376440 00000000 8c893da0
rdbss!RxIsThisACscAgentOpen+0x38
b609adb0 b86fb43b 00000000 b609ade0 b609adf0
rdbss!RxInitializeVNetRootParameters+0x282
b609ae18 b86fd63e 8e0df560 8c52d998 b609ae40
rdbss!RxFindOrConstructVirtualNetRoot+0xf6
b609ae50 b86fdb76 8d376440 8c52d998 8c927058
rdbss!RxCanonicalizeNameAndObtainNetRoot+0x1a2
b609aeb8 b86ee8d9 8d376440 8c52d998 8c927028 rdbss!RxCommonCreate+0x2c3
b609af48 b86fc9a2 b86f9028 8c52d998 8c927028 rdbss!RxFsdCommonDispatch+0x320
b609af68 b86a2a63 8ee11030 8c52d998 00000000 rdbss!RxFsdDispatch+0xd3
b609af88 8081df85 00000000 0152d998 8c52d998 mrxsmb!MRxSmbFsdDispatch+0x134
b609af9c f76e6b25 00000000 8c52d998 8c52da50 nt!IofCallDriver+0x45
b609afc0 f76f45de b609afe0 90605020 00000000
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
b609affc 8081df85 90605020 8c52d998 b609b11c fltmgr!FltpCreate+0x26a
b609b010 baee1203 b609b11c 8e2df680 8e2df6dc nt!IofCallDriver+0x45
WARNING: Stack unwind information not available. Following frames may be
wrong.
b609b050 baec417d b609b11c 8c52da74 907c7098
mfehidk!DEVICEDISPATCH::LowerDispatchPassThrough+0x51
b609b074 baec4f2d 00000002 8c52da74 8c927028 mfehidk+0x917d
b609b10c baee045b cccccccc 90bd0d28 908969a0 mfehidk+0x9f2d
b609b134 8081df85 908969a0 8c52d998 8c927028
mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x48
b609b148 baf16bb7 8d929bc4 8d929bc0 00000000 nt!IofCallDriver+0x45
b609b17c baf172c9 8d929bc0 baf13188 8d929bc0 Mup!DnrRedirectFileOpen+0x443
b609b1dc baf16d1e 01929bc0 00f800c2 8c52da98 Mup!DnrNameResolve+0x52a
b609b20c baf156e8 8c74f090 8c52d998 90acf0e8
Mup!DnrStartNameResolution+0x28c
b609b27c baf15766 8c74f090 90acf030 8c52d998 Mup!DfsCommonCreate+0x237
b609b2c4 baf157be 90acf030 8c52d998 8c927028 Mup!DfsFsdCreate+0xde
b609b31c 8081df85 90acf030 8c52d998 8c52d998 Mup!MupCreate+0xbc
b609b330 808f904b b609b4d8 90acf018 00000000 nt!IofCallDriver+0x45
b609b418 80937a20 90acf030 00000000 8cb1cae0 nt!IopParseDevice+0xa35
b609b498 80933b54 00000000 b609b4d8 00000240 nt!ObpLookupObjectName+0x5b0
b609b4ec 808eaeff 00000000 00000000 09b56c00 nt!ObOpenObjectByName+0xea
b609b568 808ec210 8c9a57e8 00100000 b609b600 nt!IopCreateFile+0x447
b609b5b0 f76faa94 8c9a57e8 00100000 b609b600
nt!IoCreateFileSpecifyDeviceObjectHint+0x52
b609b658 f76fb1bb 00000000 00000000 e4281c80
fltmgr!FltpExpandFilePathWorker+0x118
b609b670 f76fb6e1 8c9a57a0 00000000 8c9a57a0 fltmgr!FltpExpandFilePath+0x19
b609b6a8 f76fb729 8c9a57a0 8c9a57a0 b609b7f8
fltmgr!FltpGetOpenedDestinationFileName+0x303
b609b6b8 f76fb8b5 8c9a57a0 f788f0f4 f789027c
fltmgr!FltpGetNormalizedDestinationFileName+0x13
b609b7f8 f787e719 90405008 8d3913a0 00000000
fltmgr!FltGetDestinationFileNameInformation+0x12b
b609b840 f787ee4f 8da2df5c 90405008 8d3913a0

vfiltr!GetParsedFileName+0x1a3
b609b870 f787f9c9 8da2df5c b6099000 904e5030
vfiltr!GetFileNameInformation+0xe3 b609b8a8 f7885dc3 8da2df5c b609b9b0
00000000 vfiltr!PopulateFileName+0xa5
b609b8e4 f7886086 8da2df5c b609b9b0 00000000 vfiltr!IsRenameAllowed+0x13b

b609b9f0 f76e5f2a 0009ba38 00000000 b609ba38
fltmgr!FltpPerformPreCallbacks+0x2d4
b609ba04 f76e68d2 b609ba38 00000000 90605020
fltmgr!FltpPassThroughInternal+0x32
b609ba20 f76e6ce3 b609ba00 00000000 90d35030 fltmgr!FltpPassThrough+0x1c2
b609ba50 8081df85 90605020 8c57ae48 b609bbfc fltmgr!FltpDispatch+0x10d
b609ba64 baee1203 8c57ae48 b609bbfc 00000000 nt!IofCallDriver+0x45
b609baa4 baec449e b609bbfc 8c57af24 907c7098
mfehidk!DEVICEDISPATCH::LowerDispatchPassThrough+0x51
b609bb50 baec4eed 00000002 8c57af24 8d3913a0 mfehidk+0x949e
b609bbec baee045b 55555555 90bd0d28 908969a0 mfehidk+0x9eed
b609bc14 8081df85 908969a0 8c57ae48 8c57af6c
mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x48
b609bc28 baf23ac1 8c57af48 90bd0908 8c57ae48 nt!IofCallDriver+0x45
b609bc6c baf23bba 8d2233e8 8c57ae48 8c57af48
Mup!DfsCommonSetInformation+0xa3
b609bcac 8081df85 90acf030 8c57ae48 00000000 Mup!DfsFsdSetInformation+0x61
b609bcc0 808f115b b609bd64 5922fc94 808f0bbc nt!IofCallDriver+0x45
b609bd48 808897cc 00000c40 5922fccc 56581c60 nt!NtSetInformationFile+0x59f
b609bd48 7c82860c 00000c40 5922fccc 56581c60 nt!KiFastCallEntry+0xfc
5922fd2c 00000000 00000000 00000000 00000000 0x7c82860c

2

Hi All,

I would really appreciate if anyone can give me any suggestion regarding
this issue. I am not sure if this is known issue or is there any
workaround? I don’t have the reproducible case here, but i am pursuing
the customer to disable the Mcaffe AV.

I found one more thread, where this issue was discussed. I have the
exact same stack trace and environment is very similar as well. But i
don’t see any resolution in this thread. During rename i am just making
a simple call “FltGetDestinationFileNameInformation” and it crashes.

http://www.osronline.com/showThread.cfm?link=155798

thanks again.

Rajesh Gupta wrote:

Hi All,

I am using FltGetDestinationFileNameInformation to get the FileName
information during rename. But i am consistently seeing the
RDR_FILE_SYSTEM(27)crash.

I believe, This issue has been discussed here earlier. But there was no
resolution in the discussion.
Does anyone knows what rule i am break or weather i can call
“FltGetDestinationFileNameInformation” during rename or not.

thanks in advance.
Here is the stack trace, File Object and Rename Information.

Original File Name:
“\TDCEN2V9.prod.travp.net\Ops_Sys\Ops_Sys_default\0077_PASD\inbound\FN{25220858-803B-42DE-BE9C-978EF5E7F21F}{B38B6CBF-1B3A-4C89-91A7-C35FE8DC08FE}”

Rename Information:

dt 0x8c0ca3b0 _FILE_RENAME_INFORMATION
vfiltr!_FILE_RENAME_INFORMATION
+0x000 ReplaceIfExists : 0 ‘’
+0x004 RootDirectory : (null)
+0x008 FileNameLength : 0x178
+0x00c FileName :
“??\UNC\prod.travp.net\ent_dfs\ent_apps\Filenet\DPPT\Ops_Sys\Ops_Sys_default
\0077_PASD\content\FN9\FN12\FN{25220858-803B-42DE-BE9C-978EF5E7F21F}{9FA50757
-90D8-4263-A629-53E5043B742A}-0.doc蟌羝FE倠跍г???”

File Object:

0: kd> dt 0x8d3913a0 _FILE_OBJECT
nt!_FILE_OBJECT
+0x000 Type : 5
+0x002 Size : 112
+0x004 DeviceObject : 0x90acf030 _DEVICE_OBJECT
+0x008 Vpb : (null)
+0x00c FsContext : 0xe4331008
+0x010 FsContext2 : 0xe23bfa00
+0x014 SectionObjectPointer : 0x8cb0f374 _SECTION_OBJECT_POINTERS
+0x018 PrivateCacheMap : (null)
+0x01c FinalStatus : 0
+0x020 RelatedFileObject : (null)
+0x024 LockOperation : 0 ‘’
+0x025 DeletePending : 0 ‘’
+0x026 ReadAccess : 0 ‘’
+0x027 WriteAccess : 0 ‘’
+0x028 DeleteAccess : 0x1 ‘’
+0x029 SharedRead : 0x1 ‘’
+0x02a SharedWrite : 0x1 ‘’
+0x02b SharedDelete : 0x1 ‘’
+0x02c Flags : 0x41002
+0x030 FileName : _UNICODE_STRING
“\TDCEN2V9.prod.travp.net\Ops_Sys\Ops_Sys_default\0077_PASD\inbound\FN{25220858-803B-42DE-BE9C-978EF5E7F21F}{B38B6CBF-1B3A-4C89-91A7-C35FE8DC08FE}”

+0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
+0x040 Waiters : 0
+0x044 Busy : 1
+0x048 LastLock : (null)
+0x04c Lock : _KEVENT
+0x05c Event : _KEVENT
+0x06c CompletionContext : (null)

Stack Trace:

RDR_FILE_SYSTEM (27)
If you see RxExceptionFilter on the stack then the 2nd and 3rd
parameters are the
exception record and context record. Do a .cxr on the 3rd parameter
and then kb to
obtain a more informative stack trace.
The high 16 bits of the first parameter is the RDBSS bugcheck code,
which is defined
as follows:
RDBSS_BUG_CHECK_CACHESUP = 0xca550000,
RDBSS_BUG_CHECK_CLEANUP = 0xc1ee0000,
RDBSS_BUG_CHECK_CLOSE = 0xc10e0000,
RDBSS_BUG_CHECK_NTEXCEPT = 0xbaad0000,
Arguments:
Arg1: baad0080
Arg2: b609acb8
Arg3: b609a9b4
Arg4: b86f0b22

Debugging Details:

Page 7c9bb not present in the dump file. Type “.hh dbgerr004” for details
Page 27febb not present in the dump file. Type “.hh dbgerr004” for details
PEB is paged out (Peb.Ldr = 7ffd700c). Type “.hh dbgerr001” for details
PEB is paged out (Peb.Ldr = 7ffd700c). Type “.hh dbgerr001” for details

EXCEPTION_RECORD: b609acb8 – (.exr 0xffffffffb609acb8)
ExceptionAddress: b86f0b22 (rdbss!RxIsThisACscAgentOpen+0x00000038)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000008
Attempt to read from address 00000008

CONTEXT: b609a9b4 – (.cxr 0xffffffffb609a9b4)
eax=00000000 ebx=b86f0b02 ecx=00000009 edx=00000000 esi=00000008
edi=b86f0b02
eip=b86f0b22 esp=b609ad80 ebp=b609ad90 iopl=0 nv up ei pl zr na
pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
rdbss!RxIsThisACscAgentOpen+0x38:
b86f0b22 f3a6 repe cmps byte ptr [esi],byte ptr es:[edi]
Resetting default scope

PROCESS_NAME: java.exe

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 00000000

EXCEPTION_PARAMETER2: 00000008

READ_ADDRESS: 00000008

FOLLOWUP_IP:
rdbss!RxIsThisACscAgentOpen+38
b86f0b22 f3a6 repe cmps byte ptr [esi],byte ptr es:[edi]

FAULTING_IP:
rdbss!RxIsThisACscAgentOpen+38
b86f0b22 f3a6 repe cmps byte ptr [esi],byte ptr es:[edi]

BUGCHECK_STR: 0x27

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from b86fecf0 to b86f0b22

STACK_TEXT:
b609ad90 b86fecf0 8d376440 00000000 8c893da0
rdbss!RxIsThisACscAgentOpen+0x38
b609adb0 b86fb43b 00000000 b609ade0 b609adf0
rdbss!RxInitializeVNetRootParameters+0x282
b609ae18 b86fd63e 8e0df560 8c52d998 b609ae40
rdbss!RxFindOrConstructVirtualNetRoot+0xf6
b609ae50 b86fdb76 8d376440 8c52d998 8c927058
rdbss!RxCanonicalizeNameAndObtainNetRoot+0x1a2
b609aeb8 b86ee8d9 8d376440 8c52d998 8c927028 rdbss!RxCommonCreate+0x2c3
b609af48 b86fc9a2 b86f9028 8c52d998 8c927028
rdbss!RxFsdCommonDispatch+0x320
b609af68 b86a2a63 8ee11030 8c52d998 00000000 rdbss!RxFsdDispatch+0xd3
b609af88 8081df85 00000000 0152d998 8c52d998 mrxsmb!MRxSmbFsdDispatch+0x134
b609af9c f76e6b25 00000000 8c52d998 8c52da50 nt!IofCallDriver+0x45
b609afc0 f76f45de b609afe0 90605020 00000000
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
b609affc 8081df85 90605020 8c52d998 b609b11c fltmgr!FltpCreate+0x26a
b609b010 baee1203 b609b11c 8e2df680 8e2df6dc nt!IofCallDriver+0x45
WARNING: Stack unwind information not available. Following frames may be
wrong.
b609b050 baec417d b609b11c 8c52da74 907c7098
mfehidk!DEVICEDISPATCH::LowerDispatchPassThrough+0x51
b609b074 baec4f2d 00000002 8c52da74 8c927028 mfehidk+0x917d
b609b10c baee045b cccccccc 90bd0d28 908969a0 mfehidk+0x9f2d
b609b134 8081df85 908969a0 8c52d998 8c927028
mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x48
b609b148 baf16bb7 8d929bc4 8d929bc0 00000000 nt!IofCallDriver+0x45
b609b17c baf172c9 8d929bc0 baf13188 8d929bc0 Mup!DnrRedirectFileOpen+0x443
b609b1dc baf16d1e 01929bc0 00f800c2 8c52da98 Mup!DnrNameResolve+0x52a
b609b20c baf156e8 8c74f090 8c52d998 90acf0e8
Mup!DnrStartNameResolution+0x28c
b609b27c baf15766 8c74f090 90acf030 8c52d998 Mup!DfsCommonCreate+0x237
b609b2c4 baf157be 90acf030 8c52d998 8c927028 Mup!DfsFsdCreate+0xde
b609b31c 8081df85 90acf030 8c52d998 8c52d998 Mup!MupCreate+0xbc
b609b330 808f904b b609b4d8 90acf018 00000000 nt!IofCallDriver+0x45
b609b418 80937a20 90acf030 00000000 8cb1cae0 nt!IopParseDevice+0xa35
b609b498 80933b54 00000000 b609b4d8 00000240 nt!ObpLookupObjectName+0x5b0
b609b4ec 808eaeff 00000000 00000000 09b56c00 nt!ObOpenObjectByName+0xea
b609b568 808ec210 8c9a57e8 00100000 b609b600 nt!IopCreateFile+0x447
b609b5b0 f76faa94 8c9a57e8 00100000 b609b600
nt!IoCreateFileSpecifyDeviceObjectHint+0x52
b609b658 f76fb1bb 00000000 00000000 e4281c80
fltmgr!FltpExpandFilePathWorker+0x118
b609b670 f76fb6e1 8c9a57a0 00000000 8c9a57a0 fltmgr!FltpExpandFilePath+0x19
b609b6a8 f76fb729 8c9a57a0 8c9a57a0 b609b7f8
fltmgr!FltpGetOpenedDestinationFileName+0x303
b609b6b8 f76fb8b5 8c9a57a0 f788f0f4 f789027c
fltmgr!FltpGetNormalizedDestinationFileName+0x13
b609b7f8 f787e719 90405008 8d3913a0 00000000
fltmgr!FltGetDestinationFileNameInformation+0x12b
b609b840 f787ee4f 8da2df5c 90405008 8d3913a0

vfiltr!GetParsedFileName+0x1a3
b609b870 f787f9c9 8da2df5c b6099000 904e5030
vfiltr!GetFileNameInformation+0xe3 b609b8a8 f7885dc3 8da2df5c b609b9b0
00000000 vfiltr!PopulateFileName+0xa5
b609b8e4 f7886086 8da2df5c b609b9b0 00000000 vfiltr!IsRenameAllowed+0x13b

b609b9f0 f76e5f2a 0009ba38 00000000 b609ba38
fltmgr!FltpPerformPreCallbacks+0x2d4
b609ba04 f76e68d2 b609ba38 00000000 90605020
fltmgr!FltpPassThroughInternal+0x32
b609ba20 f76e6ce3 b609ba00 00000000 90d35030 fltmgr!FltpPassThrough+0x1c2
b609ba50 8081df85 90605020 8c57ae48 b609bbfc fltmgr!FltpDispatch+0x10d
b609ba64 baee1203 8c57ae48 b609bbfc 00000000 nt!IofCallDriver+0x45
b609baa4 baec449e b609bbfc 8c57af24 907c7098
mfehidk!DEVICEDISPATCH::LowerDispatchPassThrough+0x51
b609bb50 baec4eed 00000002 8c57af24 8d3913a0 mfehidk+0x949e
b609bbec baee045b 55555555 90bd0d28 908969a0 mfehidk+0x9eed
b609bc14 8081df85 908969a0 8c57ae48 8c57af6c
mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x48
b609bc28 baf23ac1 8c57af48 90bd0908 8c57ae48 nt!IofCallDriver+0x45
b609bc6c baf23bba 8d2233e8 8c57ae48 8c57af48
Mup!DfsCommonSetInformation+0xa3
b609bcac 8081df85 90acf030 8c57ae48 00000000 Mup!DfsFsdSetInformation+0x61
b609bcc0 808f115b b609bd64 5922fc94 808f0bbc nt!IofCallDriver+0x45
b609bd48 808897cc 00000c40 5922fccc 56581c60 nt!NtSetInformationFile+0x59f
b609bd48 7c82860c 00000c40 5922fccc 56581c60 nt!KiFastCallEntry+0xfc
5922fd2c 00000000 00000000 00000000 00000000 0x7c82860c

3

FYI I took a look at a couple of these dumps for Rajesh. Certainly something strange going on, though it’s not clear whose fault it is as the dump doesn’t contain the critical info required (who set the field to NULL?). Analysis follows for those curious, wonder if anyone has seen anything similar:

0: kd> .cxr 0xffffffffb7cbe9b4

eax=00000000 ebx=b88acb02 ecx=00000009 edx=00000000 esi=00000008 edi=b88acb02

eip=b88acb22 esp=b7cbed80 ebp=b7cbed90 iopl=0 nv up ei pl zr na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246

rdbss!RxIsThisACscAgentOpen+0x38:

b88acb22 f3a6 repe cmps byte ptr [esi],byte ptr es:[edi]

RxIsThisACscAgentOpen is the crashing routine, which is actually documented:

http://msdn.microsoft.com/en-us/library/ff554508(VS.85).aspx

BOOLEAN RxIsThisACscAgentOpen(

__in PRX_CONTEXT RxContext

);

It has an EBP frame:

0: kd> u rdbss!RxIsThisACscAgentOpen

rdbss!RxIsThisACscAgentOpen:

b86ef763 mov edi,edi

b86ef765 push ebp

b86ef766 mov ebp,esp

b86ef768 push ecx

b86ef769 mov eax,dword ptr [ebp+8]

And EBP+8 still points to something claiming to be an RX_CONTEXT:

0: kd> !pool poi(@ebp+8)

Pool page 8d376440 region is Nonpaged pool

8d376000 size: 228 previous size: 0 (Allocated) VOFN

8d376228 size: 10 previous size: 228 (Free) (b7.

8d376238 size: 40 previous size: 10 (Allocated) Ntfr

8d376278 size: 30 previous size: 40 (Allocated) TCPc

8d3762a8 size: 60 previous size: 30 (Allocated) VOIN

8d376308 size: 8 previous size: 60 (Free) MFE0

8d376310 size: 70 previous size: 8 (Allocated) MFEr

8d376380 size: 18 previous size: 70 (Free) MFE0

8d376398 size: a0 previous size: 18 (Allocated) MFE0

*8d376438 size: 388 previous size: a0 (Allocated) *RxIr

Pooltag RxIr : RxContext (IrpContext)

So I started walking through RxIsThisACscAgentOpen to see if I could recreate what happened. This is the path through the code that it took:

0: kd> uf rdbss!RxIsThisACscAgentOpen

rdbss!RxIsThisACscAgentOpen:

b86ef763 mov edi,edi

b86ef765 push ebp

b86ef766 mov ebp,esp

b86ef768 push ecx

b86ef769 mov eax,dword ptr [ebp+8]

b86ef76c cmp dword ptr [eax+12Ch],0 ; RxContext+12C == 0x33

b86ef773 mov byte ptr [ebp-1],0

b86ef777 ja rdbss!RxIsThisACscAgentOpen+0x16 (b86f0af2)

rdbss!RxIsThisACscAgentOpen+0x16:

b86f0af2 mov edx,dword ptr [eax+128h] ; RxContext+128 == NULL

b86f0af8 push ebx

b86f0af9 push esi

b86f0afa push edi

b86f0afb mov ebx,offset rdbss!RxpDestroySrvCall+0x62 (b86f0b02)

b86f0b00 jmp rdbss!RxIsThisACscAgentOpen+0x2e (b86f0b18)

rdbss!RxIsThisACscAgentOpen+0x2e:

b86f0b18 push 9

b86f0b1a mov edi,ebx

b86f0b1c lea esi,[edx+8] ; EDX is NULL from mov above, EDX+8 == 0x8

b86f0b1f pop ecx

b86f0b20 xor eax,eax

b86f0b22 repe cmps byte ptr [esi],byte ptr es:[edi] ; Crash because ESI is 8

Note that this is a string compare going on here. The string being compared to the NULL pointer is:

0: kd> da b86f0b02

b86f0b02 “CscAgent”

So, some field is being checked in the RxContext for being greater than zero. The field is 0x33, so the code then proceeds to compare another field of the RxContext to “CscAgent” but that field is NULL so we get a crash.

This then turned my attention back to the create IRP, which I pulled off of the stack:

0: kd> as badIrp 0x8c52d998

0: kd> !irp ${badIrp} 1

Irp is active with 5 stacks 2 is current (= 0x8c52da2c)

No Mdl: No System Buffer: Thread 8e902660: Irp stack trace.

Flags = 00000884

ThreadListEntry.Flink = 8c57ae58

ThreadListEntry.Blink = 8e902868

IoStatus.Status = 00000000

IoStatus.Information = 00000000

RequestorMode = 00000000

Cancel = 00

CancelIrql = 0

ApcEnvironment = 00

UserIosb = b609b3d0

UserEvent = 00000000

Overlay.AsynchronousParameters.UserApcRoutine = 00000000

Overlay.AsynchronousParameters.UserApcContext = 00000000

Overlay.AllocationSize = 00000000 - 00000000

CancelRoutine = b86f4a0d rdbss!RxCancelRoutine

UserBuffer = 00000000

&Tail.Overlay.DeviceQueueEntry = 8c52d9d8

Tail.Overlay.Thread = 8e902660

Tail.Overlay.AuxiliaryBuffer = 00000000

Tail.Overlay.ListEntry.Flink = 00000000

Tail.Overlay.ListEntry.Blink = 00000000

Tail.Overlay.CurrentStackLocation = 8c52da2c

Tail.Overlay.OriginalFileObject = 8c927028

Tail.Apc = 00000000

Tail.CompletionKey = 00000000

cmd flg cl Device File Completion-Context

[0, 0] 0 2 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 c0000024

[0, 0] 0 e0 8ee11030 8c927028 f76e5f8e-8cd65d40 Success Error Cancel

\FileSystem\MRxSmb fltmgr!FltpSynchronizedOperationCompletion

Args: b609b35c 01004021 00070080 00000033

[0, 0] 0 e0 90605020 8c927028 baee1159-b609b024 Success Error Cancel

\FileSystem\FltMgr mfehidk!DEVICEDISPATCH::DispatchPassThrough

Args: b609b35c 01004021 00070080 00000033

[0, 0] 0 e0 908969a0 8c927028 baf0ec60-8d929bc0 Success Error Cancel

\Driver\mfehidk Mup!DnrCompleteFileOpen

Args: b609b35c 01004021 00070080 00000033

[0, 0] 0 0 90acf030 8c927028 00000000-00000000

\FileSystem\Mup

Args: b609b35c 01004021 00070080 00000033

Note that the pesky 0x33 showed up in the arguments (the Args output on each of the stack locations). Expanding the stack location out that’s actually the EA length:

0: kd> as ioStack 0x8c52da2c

0: kd> ?? ((nt!_io_stack_location *)${ioStack})->Parameters.Create

struct __unnamed

+0x000 SecurityContext : 0xb609b35c _IO_SECURITY_CONTEXT

+0x004 Options : 0x1004021

+0x008 FileAttributes : 0x80

+0x00a ShareAccess : 7

+0x00c EaLength : 0x33

But also note that the EA buffer is NULL for this create:

0: kd> ?? ((nt!_irp *)${badIrp})->AssociatedIrp.SystemBuffer

void * 0x00000000

So, that would appear to be the issue, this create has a non-zero EA length but no EA buffer. Unfortunately, I don’t have the data type for the RX_CONTEXT so I can’t confirm.

Particularly interesting is that if you go back to the IoCreateFileSpecifyDeviceObjectHint call that started this there is an EA buffer specified along with the EA length:

0: kd> dd b609b5b0+8

b609b5b8 8c9a57e8 00100000 b609b600 b609b62c

b609b5c8 00000000 00000080 00000007 00000001

b609b5d8 00004021 e43315c0 00000033 00000000

Assuming that this isn’t a bug in the I/O manager code that builds the create IRP (unlikely), my guess is that somewhere between the create originally being made and the IRP being sent to RDBSS something happened to the EaBuffer in the IRP. This could be the fault of MUP or McAfee, it’s impossible to say from the dump. Is this reproducible? I’d want to set an access breakpoint on the system buffer field of the IRP and catch the criminal in the act…

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

4

Which OS is this on ?

Thanks,

Alex.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Wednesday, August 11, 2010 1:20 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

FYI I took a look at a couple of these dumps for Rajesh. Certainly something strange going on, though it’s not clear whose fault it is as the dump doesn’t contain the critical info required (who set the field to NULL?). Analysis follows for those curious, wonder if anyone has seen anything similar:

0: kd> .cxr 0xffffffffb7cbe9b4

eax=00000000 ebx=b88acb02 ecx=00000009 edx=00000000 esi=00000008 edi=b88acb02

eip=b88acb22 esp=b7cbed80 ebp=b7cbed90 iopl=0 nv up ei pl zr na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246

rdbss!RxIsThisACscAgentOpen+0x38:

b88acb22 f3a6 repe cmps byte ptr [esi],byte ptr es:[edi]

RxIsThisACscAgentOpen is the crashing routine, which is actually documented:

http: http://msdn.microsoft.com/en-us/library/ff554508(VS.85).aspx

BOOLEAN RxIsThisACscAgentOpen(

__in PRX_CONTEXT RxContext

);

It has an EBP frame:

0: kd> u rdbss!RxIsThisACscAgentOpen

rdbss!RxIsThisACscAgentOpen:

b86ef763 mov edi,edi

b86ef765 push ebp

b86ef766 mov ebp,esp

b86ef768 push ecx

b86ef769 mov eax,dword ptr [ebp+8]

And EBP+8 still points to something claiming to be an RX_CONTEXT:

0: kd> !pool poi(@ebp+8)

Pool page 8d376440 region is Nonpaged pool

8d376000 size: 228 previous size: 0 (Allocated) VOFN

8d376228 size: 10 previous size: 228 (Free) (b7.

8d376238 size: 40 previous size: 10 (Allocated) Ntfr

8d376278 size: 30 previous size: 40 (Allocated) TCPc

8d3762a8 size: 60 previous size: 30 (Allocated) VOIN

8d376308 size: 8 previous size: 60 (Free) MFE0

8d376310 size: 70 previous size: 8 (Allocated) MFEr

8d376380 size: 18 previous size: 70 (Free) MFE0

8d376398 size: a0 previous size: 18 (Allocated) MFE0

*8d376438 size: 388 previous size: a0 (Allocated) *RxIr

Pooltag RxIr : RxContext (IrpContext)

So I started walking through RxIsThisACscAgentOpen to see if I could recreate what happened. This is the path through the code that it took:

0: kd> uf rdbss!RxIsThisACscAgentOpen

rdbss!RxIsThisACscAgentOpen:

b86ef763 mov edi,edi

b86ef765 push ebp

b86ef766 mov ebp,esp

b86ef768 push ecx

b86ef769 mov eax,dword ptr [ebp+8]

b86ef76c cmp dword ptr [eax+12Ch],0 ; RxContext+12C == 0x33

b86ef773 mov byte ptr [ebp-1],0

b86ef777 ja rdbss!RxIsThisACscAgentOpen+0x16 (b86f0af2)

rdbss!RxIsThisACscAgentOpen+0x16:

b86f0af2 mov edx,dword ptr [eax+128h] ; RxContext+128 == NULL

b86f0af8 push ebx

b86f0af9 push esi

b86f0afa push edi

b86f0afb mov ebx,offset rdbss!RxpDestroySrvCall+0x62 (b86f0b02)

b86f0b00 jmp rdbss!RxIsThisACscAgentOpen+0x2e (b86f0b18)

rdbss!RxIsThisACscAgentOpen+0x2e:

b86f0b18 push 9

b86f0b1a mov edi,ebx

b86f0b1c lea esi,[edx+8] ; EDX is NULL from mov above, EDX+8 == 0x8

b86f0b1f pop ecx

b86f0b20 xor eax,eax

b86f0b22 repe cmps byte ptr [esi],byte ptr es:[edi] ; Crash because ESI is 8

Note that this is a string compare going on here. The string being compared to the NULL pointer is:

0: kd> da b86f0b02

b86f0b02 “CscAgent”

So, some field is being checked in the RxContext for being greater than zero. The field is 0x33, so the code then proceeds to compare another field of the RxContext to “CscAgent” but that field is NULL so we get a crash.

This then turned my attention back to the create IRP, which I pulled off of the stack:

0: kd> as badIrp 0x8c52d998

0: kd> !irp ${badIrp} 1

Irp is active with 5 stacks 2 is current (= 0x8c52da2c)

No Mdl: No System Buffer: Thread 8e902660: Irp stack trace.

Flags = 00000884

ThreadListEntry.Flink = 8c57ae58

ThreadListEntry.Blink = 8e902868

IoStatus.Status = 00000000

IoStatus.Information = 00000000

RequestorMode = 00000000

Cancel = 00

CancelIrql = 0

ApcEnvironment = 00

UserIosb = b609b3d0

UserEvent = 00000000

Overlay.AsynchronousParameters.UserApcRoutine = 00000000

Overlay.AsynchronousParameters.UserApcContext = 00000000

Overlay.AllocationSize = 00000000 - 00000000

CancelRoutine = b86f4a0d rdbss!RxCancelRoutine

UserBuffer = 00000000

&Tail.Overlay.DeviceQueueEntry = 8c52d9d8

Tail.Overlay.Thread = 8e902660

Tail.Overlay.AuxiliaryBuffer = 00000000

Tail.Overlay.ListEntry.Flink = 00000000

Tail.Overlay.ListEntry.Blink = 00000000

Tail.Overlay.CurrentStackLocation = 8c52da2c

Tail.Overlay.OriginalFileObject = 8c927028

Tail.Apc = 00000000

Tail.CompletionKey = 00000000

cmd flg cl Device File Completion-Context

[0, 0] 0 2 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 c0000024

>[0, 0] 0 e0 8ee11030 8c927028 f76e5f8e-8cd65d40 Success Error Cancel

\FileSystem\MRxSmb fltmgr!FltpSynchronizedOperationCompletion

Args: b609b35c 01004021 00070080 00000033

[0, 0] 0 e0 90605020 8c927028 baee1159-b609b024 Success Error Cancel

\FileSystem\FltMgr mfehidk!DEVICEDISPATCH::DispatchPassThrough

Args: b609b35c 01004021 00070080 00000033

[0, 0] 0 e0 908969a0 8c927028 baf0ec60-8d929bc0 Success Error Cancel

\Driver\mfehidk Mup!DnrCompleteFileOpen

Args: b609b35c 01004021 00070080 00000033

[0, 0] 0 0 90acf030 8c927028 00000000-00000000

\FileSystem\Mup

Args: b609b35c 01004021 00070080 00000033

Note that the pesky 0x33 showed up in the arguments (the Args output on each of the stack locations). Expanding the stack location out that’s actually the EA length:

0: kd> as ioStack 0x8c52da2c

0: kd> ?? ((nt!_io_stack_location *)${ioStack})->Parameters.Create

struct__unnamed

+0x000 SecurityContext : 0xb609b35c _IO_SECURITY_CONTEXT

+0x004 Options : 0x1004021

+0x008 FileAttributes : 0x80

+0x00a ShareAccess : 7

+0x00c EaLength : 0x33

But also note that the EA buffer is NULL for this create:

0: kd> ?? ((nt!_irp *)${badIrp})->AssociatedIrp.SystemBuffer

void * 0x00000000

So, that would appear to be the issue, this create has a non-zero EA length but no EA buffer. Unfortunately, I don’t have the data type for the RX_CONTEXT so I can’t confirm.

Particularly interesting is that if you go back to the IoCreateFileSpecifyDeviceObjectHint call that started this there is an EA buffer specified along with the EA length:

0: kd> dd b609b5b0+8

b609b5b8 8c9a57e8 00100000 b609b600 b609b62c

b609b5c8 00000000 00000080 00000007 00000001

b609b5d8 00004021 e43315c0 00000033 00000000

Assuming that this isn’t a bug in the I/O manager code that builds the create IRP (unlikely), my guess is that somewhere between the create originally being made and the IRP being sent to RDBSS something happened to the EaBuffer in the IRP. This could be the fault of MUP or McAfee, it’s impossible to say from the dump. Is this reproducible? I’d want to set an access breakpoint on the system buffer field of the IRP and catch the criminal in the act…

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

—
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</http:>

5

Thanks a lot Scott for the help.

Alex, this is on Windows Server 2003 x86.

Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (8 procs)
Free x86 compatible

thanks

Alex Carp wrote:

Which OS is this on ?

Thanks,

Alex.

*From:* xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] *On Behalf Of *Scott Noone
*Sent:* Wednesday, August 11, 2010 1:20 PM
*To:* Windows File Systems Devs Interest List
*Subject:* Re:[ntfsd] RDR_FILE_SYSTEM (27) Crash, after Calling
FltGetDestinationFileNameInformation

FYI I took a look at a couple of these dumps for Rajesh. Certainly
something strange going on, though it’s not clear whose fault it is as
the dump doesn’t contain the critical info required (who set the field
to NULL?). Analysis follows for those curious, wonder if anyone has seen
anything similar:

0: kd> .cxr 0xffffffffb7cbe9b4

eax=00000000 ebx=b88acb02 ecx=00000009 edx=00000000 esi=00000008
edi=b88acb02

eip=b88acb22 esp=b7cbed80 ebp=b7cbed90 iopl=0 nv up ei pl zr na
pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246

rdbss!RxIsThisACscAgentOpen+0x38:

b88acb22 f3a6 repe cmps byte ptr [esi],byte ptr es:[edi]

RxIsThisACscAgentOpen is the crashing routine, which is actually documented:

http://msdn.microsoft.com/en-us/library/ff554508(VS.85).aspx

BOOLEAN RxIsThisACscAgentOpen(

__in PRX_CONTEXT RxContext

);

It has an EBP frame:

0: kd> u rdbss!RxIsThisACscAgentOpen

rdbss!RxIsThisACscAgentOpen:

b86ef763 mov edi,edi

b86ef765 push ebp

b86ef766 mov ebp,esp

b86ef768 push ecx

b86ef769 mov eax,dword ptr [ebp+8]

And EBP+8 still points to something claiming to be an RX_CONTEXT:

0: kd> !pool poi(@ebp+8)

Pool page 8d376440 region is Nonpaged pool

8d376000 size: 228 previous size: 0 (Allocated) VOFN

8d376228 size: 10 previous size: 228 (Free) (b7.

8d376238 size: 40 previous size: 10 (Allocated) Ntfr

8d376278 size: 30 previous size: 40 (Allocated) TCPc

8d3762a8 size: 60 previous size: 30 (Allocated) VOIN

8d376308 size: 8 previous size: 60 (Free) MFE0

8d376310 size: 70 previous size: 8 (Allocated) MFEr

8d376380 size: 18 previous size: 70 (Free) MFE0

8d376398 size: a0 previous size: 18 (Allocated) MFE0

*8d376438 size: 388 previous size: a0 (Allocated) *RxIr

Pooltag RxIr : RxContext (IrpContext)

So I started walking through RxIsThisACscAgentOpen to see if I could
recreate what happened. This is the path through the code that it took:

0: kd> uf rdbss!RxIsThisACscAgentOpen

rdbss!RxIsThisACscAgentOpen:

b86ef763 mov edi,edi

b86ef765 push ebp

b86ef766 mov ebp,esp

b86ef768 push ecx

b86ef769 mov eax,dword ptr [ebp+8]

b86ef76c cmp dword ptr [eax+12Ch],0 *; RxContext+12C == 0x33*

b86ef773 mov byte ptr [ebp-1],0

b86ef777 ja rdbss!RxIsThisACscAgentOpen+0x16 (b86f0af2)

rdbss!RxIsThisACscAgentOpen+0x16:

b86f0af2 mov edx,dword ptr [eax+128h] *; RxContext+128 == NULL*

b86f0af8 push ebx

b86f0af9 push esi

b86f0afa push edi

b86f0afb mov ebx,offset rdbss!RxpDestroySrvCall+0x62 (b86f0b02)

b86f0b00 jmp rdbss!RxIsThisACscAgentOpen+0x2e (b86f0b18)

rdbss!RxIsThisACscAgentOpen+0x2e:

b86f0b18 push 9

b86f0b1a mov edi,ebx

b86f0b1c lea esi,[edx+8] *; EDX is NULL from mov above, EDX+8 == 0x8*

b86f0b1f pop ecx

b86f0b20 xor eax,eax

b86f0b22 repe cmps byte ptr [esi],byte ptr es:[edi] *; Crash because ESI
is 8*

Note that this is a string compare going on here. The string being
compared to the NULL pointer is:

0: kd> da b86f0b02

b86f0b02 “CscAgent”

So, some field is being checked in the RxContext for being greater than
zero. The field is 0x33, so the code then proceeds to compare another
field of the RxContext to “CscAgent” but that field is NULL so we get a
crash.

This then turned my attention back to the create IRP, which I pulled off
of the stack:

0: kd> as badIrp 0x8c52d998

0: kd> !irp ${badIrp} 1

Irp is active with 5 stacks 2 is current (= 0x8c52da2c)

No Mdl: No System Buffer: Thread 8e902660: Irp stack trace.

Flags = 00000884

ThreadListEntry.Flink = 8c57ae58

ThreadListEntry.Blink = 8e902868

IoStatus.Status = 00000000

IoStatus.Information = 00000000

RequestorMode = 00000000

Cancel = 00

CancelIrql = 0

ApcEnvironment = 00

UserIosb = b609b3d0

UserEvent = 00000000

Overlay.AsynchronousParameters.UserApcRoutine = 00000000

Overlay.AsynchronousParameters.UserApcContext = 00000000

Overlay.AllocationSize = 00000000 - 00000000

CancelRoutine = b86f4a0d rdbss!RxCancelRoutine

UserBuffer = 00000000

&Tail.Overlay.DeviceQueueEntry = 8c52d9d8

Tail.Overlay.Thread = 8e902660

Tail.Overlay.AuxiliaryBuffer = 00000000

Tail.Overlay.ListEntry.Flink = 00000000

Tail.Overlay.ListEntry.Blink = 00000000

Tail.Overlay.CurrentStackLocation = 8c52da2c

Tail.Overlay.OriginalFileObject = 8c927028

Tail.Apc = 00000000

Tail.CompletionKey = 00000000

cmd flg cl Device File Completion-Context

[0, 0] 0 2 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 c0000024

>[0, 0] 0 e0 8ee11030 8c927028 f76e5f8e-8cd65d40 Success Error Cancel

\FileSystem\MRxSmb
fltmgr!FltpSynchronizedOperationCompletion

Args: b609b35c 01004021 00070080 *00000033*

[0, 0] 0 e0 90605020 8c927028 baee1159-b609b024 Success Error Cancel

\FileSystem\FltMgr
mfehidk!DEVICEDISPATCH::DispatchPassThrough

Args: b609b35c 01004021 00070080 *00000033*

[0, 0] 0 e0 908969a0 8c927028 baf0ec60-8d929bc0 Success Error Cancel

\Driver\mfehidk Mup!DnrCompleteFileOpen

Args: b609b35c 01004021 00070080 *00000033*

[0, 0] 0 0 90acf030 8c927028 00000000-00000000

\FileSystem\Mup

Args: b609b35c 01004021 00070080 *00000033*

Note that the pesky 0x33 showed up in the arguments (the Args output on
each of the stack locations). Expanding the stack location out that’s
actually the EA length:

0: kd> as ioStack 0x8c52da2c

0: kd> ?? ((nt!_io_stack_location *)${ioStack})->Parameters.Create

struct __unnamed

+0x000 SecurityContext : 0xb609b35c _IO_SECURITY_CONTEXT

+0x004 Options : 0x1004021

+0x008 FileAttributes : 0x80

+0x00a ShareAccess : 7

* +0x00c EaLength : 0x33*

But also note that the EA buffer is NULL for this create:

0: kd> ?? ((nt!_irp *)${badIrp})->AssociatedIrp.SystemBuffer

void * 0x00000000

So, that would appear to be the issue, this create has a non-zero EA
length but no EA buffer. Unfortunately, I don’t have the data type for
the RX_CONTEXT so I can’t confirm.

Particularly interesting is that if you go back to the
IoCreateFileSpecifyDeviceObjectHint call that started this there is an
EA buffer specified along with the EA length:

0: kd> dd b609b5b0+8

b609b5b8 8c9a57e8 00100000 b609b600 b609b62c

b609b5c8 00000000 00000080 00000007 00000001

b609b5d8 00004021 *e43315c0 00000033* 00000000

Assuming that this isn’t a bug in the I/O manager code that builds the
create IRP (unlikely), my guess is that somewhere between the create
originally being made and the IRP being sent to RDBSS something happened
to the EaBuffer in the IRP. This could be the fault of MUP or McAfee,
it’s impossible to say from the dump. Is this reproducible? I’d want to
set an access breakpoint on the system buffer field of the IRP and catch
the criminal in the act…

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

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

6

So… I think I know what the problem is… It’s a rather nasty issue I’ve dealt with before…

This probably has something to do with FltCreateFile. FltMgr uses a two layered approach when issuing a targeted create. It uses IoCreateFileSpecifyDeviceObjectHint to target its device (thus making sure that legacy filter above FltMgr don’t see it) and then it uses some structure that can be attached to the create to identify which mini-filter is the one below the issuing filter (similar to IoCreateFileSpecifyDeviceObjectHint but for minifilters basically).

This structure is now an ECP (since Vista). However, before Vista FltMgr used an EA. And this is where the problem comes from. FltMgr needs to use the EA to talk to itself, but the minifilter might specify an EA as well. So FltMgr wraps the EA that the minifilter specifies (if any) and after it gets the create back, it removes its data from the EA and sends the EA down (to the minifilters first and then down the IO stack).

EA is a pretty weird structure in that the length is stored in the IO_STACK_LOCATION while the buffer itself is stored in the IRP (Irp->AssociatedIrp.SystemBuffer). Now, assume that the minifilter sent something like a buffer of size 0x50. FltMgr will allocate its own buffer of size 0x33 (perhaps… it doesn’t really matter). When it gets the IRP it will get the IO_STACK_LOCATION size == 0x33. It will then parse the data in the EA buffer, figure out what the original size was (0x50) and sets the buffer in the IRP to point to the original user EA buffer and sets the new size to 0x50 (the size of the original buffer).

This works pretty well, until RDR comes into the picture. RDR has some logic where when it sees a create go by and then if it sees it fail with some status it will retry. However, this is problematic for the case where FltMgr has already processed the EA buffer (for example, the first time the CREATE was sent down). The reason is that the IO_STACK_LOCATION for RDR might still have the old EaLength of 0x33 while the buffer in the IRP might be the 0x50 bytes one. Or, in this case, there was no user EA buffer, so the buffer in the IRP is null. FltMgr will handle the case (almost) correctly (it checks if the buffer is null) but since it doesn’t find the EA buffer it will show the CREATE to all the minifilters in that frame, regardless of who issued the create. So it won’t bugcheck but it will show operations to minifilters that weren’t supposed to see it.

Anyway, the real question what can you do about it. This is clearly microsoft’s bug but I couldn’t get a fix for it. There is a very very very hacky workaround though. I don’t recommend this approach at all. To paraphrase the disclaimer from southpark, “The following piece of code contains coarse language and due to its content it should not be read by anyone”.



Because your minifilter sees the create after the EA has been processed, what you’ll see if you look in Data->Iopb->Parameters.Create is Data->Iopb->Parameters.Create.EaBuffer == NULL and Data->Iopb->Parameters.Create.EaLength == 0x33 (I think … also, I think this is 0x47 on 64bit systems). What you could do is set EaLength to 0 in your preCreate, which will then propagate to MrxSmb and the problem is solved. Now, this might be problematic if there are additional minifilters so you need to investigate…

The code to do this is something like this:

If ((Data->Iopb->Parameters.Create.EaBuffer == NULL) &&
(Data->Iopb->Parameters.Create.EaLength == 0x33))
) {
Data->Iopb->Parameters.Create.EaLength = 0;
FltSetCallbackDataDirty(Data);
Return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

You need to check that this happens ONLY ON DFS or at least on network file systems. Also, I would recommend hiding this behavior under a registry flag or something and turning it on only on a case by case basis…

Hope this helps.

Please let me know if you have any questions (as the description here is quite convoluted).

Thanks,
Alex.

7

Hi Alex,

Thanks a lot for the detail explanation. I was going through this again
and again to make sure i understood it correctly.

As of workaround you mentioned, i am not sure how that will work in this
scenario.

You said this issue has something to do with FltCreateFile.

IoCreateFileSpecifyDeviceObjectHint definition from MSDN
“The IoCreateFileSpecifyDeviceObjectHint routine is used by file system
filter drivers to send a create request only to the filters below a
specified device object and to the file system.”

Hence, my driver doesn’t see this IRP as this request is going down the
stack.

“IoCreateFileSpecifyDeviceObjectHint” (where we see the parameter 0x33)
is called after my driver called the function
“FltGetDestinationFileNameInformation” when rename was happening.

Look at the stack location of the IRP, my driver is not present there.

Did i get it wrong? May be i understood it wrong.

Tail.Apc = 00000000
Tail.CompletionKey = 00000000

cmd flg cl Device File Completion-Context

[0, 0] 0 2 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 c0000024

[0, 0] 0 e0 8ee11030 8c927028 f76e5f8e-8cd65d40 Success Error Cancel

\FileSystem\MRxSmb
fltmgr!FltpSynchronizedOperationCompletion

Args: b609b35c 01004021 00070080 00000033

[0, 0] 0 e0 90605020 8c927028 baee1159-b609b024 Success Error Cancel

\FileSystem\FltMgr
mfehidk!DEVICEDISPATCH::DispatchPassThrough

Args: b609b35c 01004021 00070080 00000033

[0, 0] 0 e0 908969a0 8c927028 baf0ec60-8d929bc0 Success Error Cancel

\Driver\mfehidk Mup!DnrCompleteFileOpen

Args: b609b35c 01004021 00070080 00000033

[0, 0] 0 0 90acf030 8c927028 00000000-00000000

\FileSystem\Mup

Args: b609b35c 01004021 00070080 00000033

Alex Carp wrote:

So… I think I know what the problem is… It’s a rather nasty issue I’ve dealt with before…

This probably has something to do with FltCreateFile. FltMgr uses a two layered approach when issuing a targeted create. It uses IoCreateFileSpecifyDeviceObjectHint to target its device (thus making sure that legacy filter above FltMgr don’t see it) and then it uses some structure that can be attached to the create to identify which mini-filter is the one below the issuing filter (similar to IoCreateFileSpecifyDeviceObjectHint but for minifilters basically).

This structure is now an ECP (since Vista). However, before Vista FltMgr used an EA. And this is where the problem comes from. FltMgr needs to use the EA to talk to itself, but the minifilter might specify an EA as well. So FltMgr wraps the EA that the minifilter specifies (if any) and after it gets the create back, it removes its data from the EA and sends the EA down (to the minifilters first and then down the IO stack).

EA is a pretty weird structure in that the length is stored in the IO_STACK_LOCATION while the buffer itself is stored in the IRP (Irp->AssociatedIrp.SystemBuffer). Now, assume that the minifilter sent something like a buffer of size 0x50. FltMgr will allocate its own buffer of size 0x33 (perhaps… it doesn’t really matter). When it gets the IRP it will get the IO_STACK_LOCATION size == 0x33. It will then parse the data in the EA buffer, figure out what the original size was (0x50) and sets the buffer in the IRP to point to the original user EA buffer and sets the new size to 0x50 (the size of the original buffer).

This works pretty well, until RDR comes into the picture. RDR has some logic where when it sees a create go by and then if it sees it fail with some status it will retry. However, this is problematic for the case where FltMgr has already processed the EA buffer (for example, the first time the CREATE was sent down). The reason is that the IO_STACK_LOCATION for RDR might still have the old EaLength of 0x33 while the buffer in the IRP might be the 0x50 bytes one. Or, in this case, there was no user EA buffer, so the buffer in the IRP is null. FltMgr will handle the case (almost) correctly (it checks if the buffer is null) but since it doesn’t find the EA buffer it will show the CREATE to all the minifilters in that frame, regardless of who issued the create. So it won’t bugcheck but it will show operations to minifilters that weren’t supposed to see it.

Anyway, the real question what can you do about it. This is clearly microsoft’s bug but I couldn’t get a fix for it. There is a very very very hacky workaround though. I don’t recommend this approach at all. To paraphrase the disclaimer from southpark, “The following piece of code contains coarse language and due to its content it should not be read by anyone”.


>
> Because your minifilter sees the create after the EA has been processed, what you’ll see if you look in Data->Iopb->Parameters.Create is Data->Iopb->Parameters.Create.EaBuffer == NULL and Data->Iopb->Parameters.Create.EaLength == 0x33 (I think … also, I think this is 0x47 on 64bit systems). What you could do is set EaLength to 0 in your preCreate, which will then propagate to MrxSmb and the problem is solved. Now, this might be problematic if there are additional minifilters so you need to investigate…
>
> The code to do this is something like this:
>
> If ((Data->Iopb->Parameters.Create.EaBuffer == NULL) &&
> (Data->Iopb->Parameters.Create.EaLength == 0x33))
> ) {
> Data->Iopb->Parameters.Create.EaLength = 0;
> FltSetCallbackDataDirty(Data);
> Return FLT_PREOP_SUCCESS_NO_CALLBACK;
> }
>
> You need to check that this happens ONLY ON DFS or at least on network file systems. Also, I would recommend hiding this behavior under a registry flag or something and turning it on only on a case by case basis…
>
>

Hope this helps.

Please let me know if you have any questions (as the description here is quite convoluted).

Thanks,
Alex.

8

Is your driver a minifilter or not ?

Thanks,
Alex.

9

Yes, my driver is minifilter.

thanks

Alex Carp wrote:

Is your driver a minifilter or not ?

Thanks,
Alex.

10

Well, then you won’t see your minfilter on the stack unless you issue IO in your minifilter. The minifilter model is a call-back model, not a call-through model.

IoCreateFileSpecifyDeviceObjectHint is used by FltMgr to send the request to itself. My theory is that your minifilter sees this in preCreate (but it shouldn’t) the second time the request comes down (second time because the create is retried).

Anyway, did you try and it didn’t fix the problem ? You could just add an assert instead of the if in and if it hits then you can investigate it better…

Thanks,
Alex.

11

I don’t have reproducible environment here and we are working on to
reproduce it. I will try this out see if i see it second time.

It seems from the crash dump i have from customer that i am not seeing
it second time. But i may be wrong.

thanks

Alex Carp wrote:

Well, then you won’t see your minfilter on the stack unless you issue IO in your minifilter. The minifilter model is a call-back model, not a call-through model.

IoCreateFileSpecifyDeviceObjectHint is used by FltMgr to send the request to itself. My theory is that your minifilter sees this in preCreate (but it shouldn’t) the second time the request comes down (second time because the create is retried).

Anyway, did you try and it didn’t fix the problem ? You could just add an assert instead of the if in and if it hits then you can investigate it better…

Thanks,
Alex.

12

Hi All,

thanks a lot for all the help.
This is indeed the MS issue and here is the solution (patch) provided by them to me.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;978972

13

Wow, I thought this one was fixed quite some time ago… so many similar issues with FltGetFileNameInformation
and FltGetDestinationFileNameInformation API.
To top it off, the workaround note is not appealing to driver writers: “To work around this issue, uninstall the
software that installs the mini-filter driver, such as Kaspersky Antivirus Client”.

:frowning:

xxxxx@gmail.com wrote:

Hi All,

thanks a lot for all the help.
This is indeed the MS issue and here is the solution (patch) provided by them to me.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;978972

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

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

14

Well, this is not a problem with FltGetFileNameInformation per se, it simply
happens to expose the underlying problem in Mup.

Thanks,
Alex.

15

Thanks for the update and the link. Have to keep that one handy in case we
see this again…

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntfsd…
> Hi All,
>
> thanks a lot for all the help.
> This is indeed the MS issue and here is the solution (patch) provided by
> them to me.
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;978972
>
>
>
>
>