Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Upcoming OSR Seminars:

Writing WDF Drivers I: Core Concepts, Nashua, NH 15-19 May, 2017
Writing WDF Drivers II: Advanced Implementation Tech., Nashua, NH 23-26 May, 2017
Kernel Debugging and Crash Analysis, Dulles, VA 26-30 June, 2017
Windows Internals & Software Driver Development, Nashua, NH 24-28 July, 2017


Go Back   OSR Online Lists > ntfsd
Welcome, Guest
You must login to post to this list
  Message 1 of 15  
04 Aug 10 12:38
Rajesh Gupta
xxxxxx@gmail.com
Join Date: 05 Jan 2006
Posts To This List: 167
RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

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-8 03B-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-8 03B-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
  Message 2 of 15  
10 Aug 10 19:16
Rajesh Gupta
xxxxxx@gmail.com
Join Date: 05 Jan 2006
Posts To This List: 167
RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

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. <...excess quoted lines suppressed...>
  Message 3 of 15  
11 Aug 10 16:19
Scott Noone
xxxxxx@osr.com
Join Date: 10 Jul 2002
Posts To This List: 884
List Moderator
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 --
  Message 4 of 15  
11 Aug 10 16:54
Alex Carp
xxxxxx@gmail.com
Join Date: 23 Feb 2010
Posts To This List: 981
RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

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> 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 --
  Message 5 of 15  
11 Aug 10 17:25
Rajesh Gupta
xxxxxx@gmail.com
Join Date: 05 Jan 2006
Posts To This List: 167
RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

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. > > > <...excess quoted lines suppressed...>
  Message 6 of 15  
11 Aug 10 18:16
Alex Carp
xxxxxx@gmail.com
Join Date: 23 Feb 2010
Posts To This List: 981
RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

So.. I think I know what the problem is.. It's a rather nasty issue I've = dealt with before...=20 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).=20 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 =3D=3D 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.=20 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".=20 <hack> 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 =3D=3D NULL and = Data->Iopb->Parameters.Create.EaLength =3D=3D 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..=20 The code to do this is something like this: If ((Data->Iopb->Parameters.Create.EaBuffer =3D=3D NULL) &&=20 (Data->Iopb->Parameters.Create.EaLength =3D=3D 0x33)) ) {=20 Data->Iopb->Parameters.Create.EaLength =3D 0;=20 FltSetCallbackDataDirty(Data); Return FLT_PREOP_SUCCESS_NO_CALLBACK;=20 } 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..=20 </hack> Hope this helps.=20 Please let me know if you have any questions (as the description here is = quite convoluted). Thanks, Alex.
  Message 7 of 15  
12 Aug 10 12:37
Rajesh Gupta
xxxxxx@gmail.com
Join Date: 05 Jan 2006
Posts To This List: 167
RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

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. > <...excess quoted lines suppressed...>
  Message 8 of 15  
12 Aug 10 13:52
Alex Carp
xxxxxx@gmail.com
Join Date: 23 Feb 2010
Posts To This List: 981
RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

Is your driver a minifilter or not ? Thanks, Alex.
  Message 9 of 15  
12 Aug 10 15:23
Rajesh Gupta
xxxxxx@gmail.com
Join Date: 05 Jan 2006
Posts To This List: 167
RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

Yes, my driver is minifilter. thanks Alex Carp wrote: > Is your driver a minifilter or not ? > > Thanks, > Alex. > >
  Message 10 of 15  
12 Aug 10 15:33
Alex Carp
xxxxxx@gmail.com
Join Date: 23 Feb 2010
Posts To This List: 981
RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

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).=20 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.
  Message 11 of 15  
12 Aug 10 15:56
Rajesh Gupta
xxxxxx@gmail.com
Join Date: 05 Jan 2006
Posts To This List: 167
RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

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. > >
  Message 12 of 15  
16 Aug 10 22:57
Rajesh Gupta
xxxxxx@gmail.com
Join Date: 05 Jan 2006
Posts To This List: 167
RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

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
  Message 13 of 15  
17 Aug 10 01:27
ntfsd member 5961
xxxxxx@alfasp.com
Join Date:
Posts To This List: 1448
RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

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". :( 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 <...excess quoted lines suppressed...> -- Kind regards, Dejan (MSN support: xxxxx@alfasp.com) http://www.alfasp.com File system audit, security and encryption kits.
  Message 14 of 15  
17 Aug 10 10:58
Alex Carp
xxxxxx@gmail.com
Join Date: 23 Feb 2010
Posts To This List: 981
RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

Well, this is not a problem with FltGetFileNameInformation per se, it simply happens to expose the underlying problem in Mup. Thanks, Alex.
  Message 15 of 15  
17 Aug 10 13:04
Scott Noone
xxxxxx@osr.com
Join Date: 10 Jul 2002
Posts To This List: 884
List Moderator
RDR_FILE_SYSTEM (27) Crash, after Calling FltGetDestinationFileNameInformation

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 <xxxxx@gmail.com> wrote in message news:88376@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 > > > > <...excess quoted lines suppressed...>
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntfsd list to be able to post.

All times are GMT -5. The time now is 04:51.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license