Strange redirector behavior

Hi all,

Recently I faced some odd problem with a redirector. I develop some kind of an FS mini-filter driver and some days ago I began to perform various tests. Everything was fine, but when I tried to test a profile roaming on Windows Server 2003 machines, my driver began to fail steadily on a single file. In this experiment there are three machines (all with Windows Server 2003 installed): a file server which contains a user profile, a client machine with my mini-filter installed which the above profile is copied to, and yet another machine which is used for a connection to the client machine via the remote desktop. When I log on to the client machine using the remote desktop, the client machine begins to transfer profile files from the file server machine, and then at some point of time the operation fails on some file with an error code STATUS_BAD_NETWORK_PATH. It’s worth to mention that this failed operation is retried four times then and every time it fails.
I’m putting down some info that perhaps will be useful to shed some light on this strange problem. All structures and other information were captured while in RxCommonCreate() and lower routines. At that time my PreCreate() mini-filter callback routine had already been completed and passed this request to a lower driver, i.e. to the mini-redirector (of course, thru the Filter Manager driver).
Finally RxFindOrConstructVirtualNetRoot() routine failed with an error STATUS_BAD_NETWORK_PATH which I could observe then in my PostCreate() mini-filter callback.

b97567a8 ba7f963e 89286d90 898578f8 b97567d0 rdbss!RxFindOrConstructVirtualNetRoot+0x170
b97567e0 ba7f9b76 8967ca28 898578f8 892e99a0 rdbss!RxCanonicalizeNameAndObtainNetRoot+0x1a2
b9756848 ba7ea8d9 8967ca28 898578f8 892e9970 rdbss!RxCommonCreate+0x2c3
b97568d8 ba7f89a2 ba7f5028 898578f8 892e9970 rdbss!RxFsdCommonDispatch+0x320
b97568f8 ba776a63 8985b7e8 898578f8 80a5bf00 rdbss!RxFsdDispatch+0xd3
b9756918 809b550c 00000000 018578f8 892e9970 mrxsmb!MRxSmbFsdDispatch+0x134
b9756948 8081df33 f724c54d b9756984 f724c54d nt!IovCallDriver+0x112
b9756954 f724c54d 00000000 80a5bf00 892ad1f0 nt!IofCallDriver+0x13
b9756984 809b550c 892ad1f0 898578f8 00000000 fltMgr!FltpCreate+0x1d9
b97569b4 8081df33 f723eb25 b97569e4 f723eb25 nt!IovCallDriver+0x112
b97569c0 f723eb25 00000000 898578f8 898579b0 nt!IofCallDriver+0x13
b97569e4 f724c5de b9756a04 892c7020 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
b9756a20 809b550c 892c7020 898578f8 892e9970 fltMgr!FltpCreate+0x26a
b9756a50 8081df33 808f8f71 b9756b44 808f8f71 nt!IovCallDriver+0x112
b9756a5c 808f8f71 b9756c04 8985b7d0 00000000 nt!IofCallDriver+0x13
b9756b44 80937942 8985b7e8 00000000 89676cd0 nt!IopParseDevice+0xa35
b9756bc4 80933a76 00000000 b9756c04 00000040 nt!ObpLookupObjectName+0x5b0
b9756c18 808eae25 00000000 00000000 00000001 nt!ObOpenObjectByName+0xea
b9756c94 808ec0bf 0164f4b4 80100080 0164f450 nt!IopCreateFile+0x447
b9756cf0 808eeb4e 0164f4b4 80100080 0164f450 nt!IoCreateFile+0xa3
b9756d30 8088978c 0164f4b4 80100080 0164f450 nt!NtCreateFile+0x30
b9756d30 7c8285ec 0164f4b4 80100080 0164f450 nt!KiFastCallEntry+0xfc
0164f40c 7c826deb 77e649f7 0164f4b4 80100080 ntdll!KiFastSystemCallRet
0164f410 77e649f7 0164f4b4 80100080 0164f450 ntdll!ZwCreateFile+0xc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0164f4ac 77e48b34 00000000 80000000 00000001 0x77e649f7
0164f928 7c82dffe 0164f95c 00000000 00d3f1d4 0x77e48b34
0164f8ec 7698b337 0144ca38 0164fb6c 7698aa85 ntdll!RtlDosApplyFileIsolationRedirection_Ustr+0x346
0164fd78 7698bd55 0144ca38 0144cc40 00004000 0x7698b337
0164ffb8 77e64829 00d3f1d4 00000000 00000000 0x7698bd55
0164ffec 00000000 7698bcab 00d3f1d4 00000000 0x77e64829

A file object upon entering RxCommonCreate() routine:

ntdll!_FILE_OBJECT
+0x000 Type : 5
+0x002 Size : 0x70
+0x004 DeviceObject : 0x8985b7e8 _DEVICE_OBJECT
+0x008 Vpb : (null)
+0x00c FsContext : (null)
+0x010 FsContext2 : (null)
+0x014 SectionObjectPointer : (null)
+0x018 PrivateCacheMap : (null)
+0x01c FinalStatus : 0
+0x020 RelatedFileObject : (null)
+0x024 LockOperation : 0 ‘’
+0x025 DeletePending : 0 ‘’
+0x026 ReadAccess : 0 ‘’
+0x027 WriteAccess : 0 ‘’
+0x028 DeleteAccess : 0 ‘’
+0x029 SharedRead : 0 ‘’
+0x02a SharedWrite : 0 ‘’
+0x02b SharedDelete : 0 ‘’
+0x02c Flags : 0x22
+0x030 FileName : _UNICODE_STRING “;F:00000000002c8383\tl-ws-node2\Profile Storage\User004\Start Menu\Programs\Accessories\Synchronize.lnk”
+0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
+0x040 Waiters : 0
+0x044 Busy : 0
+0x048 LastLock : (null)
+0x04c Lock : _KEVENT
+0x05c Event : _KEVENT
+0x06c CompletionContext : (null)

CreateOptions: 0x01200064
Disposition: FILE_OPEN
CreateOptions: ( FILE_OPEN_REPARSE_POINT | FILE_NON_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT | FILE_SEQUENTIAL_ONLY )

A file name before RxCanonicalizeNameAndObtainNetRoot() call:

ntdll!_UNICODE_STRING
“;F:00000000002c8383\tl-ws-node2\Profile Storage\User004\Start Menu\Programs\Accessories\Synchronize.lnk”
+0x000 Length : 0xd0
+0x002 MaximumLength : 0xf8
+0x004 Buffer : 0xe2271a70 “;F:00000000002c8383\tl-ws-node2\Profile Storage\User004\Start Menu\Programs\Accessories\Synchronize.lnk”

A file name before RxFindOrConstructVirtualNetRoot() call:

ntdll!_UNICODE_STRING
“\Profile Storage\User004\Start Menu\Programs\Accessories\Synchronize.lnk”
+0x000 Length : 0x90
+0x002 MaximumLength : 0x90
+0x004 Buffer : 0xe1553ca8 “\Profile Storage\User004\Start Menu\Programs\Accessories\Synchronize.lnk”

The NET_ROOT structure at the moment when RxFindOrConstructVirtualNetRoot() routine failed internally:

klif!_NET_ROOT
+0x000 NodeTypeCode : 0xeb11
+0x002 NodeByteSize : 0x238
+0x004 NodeReferenceCount : 2
+0x008 pSrvCall : 0x896e63e0 MRX_SRV_CALL
+0x00c Context : 0x892d76c0
+0x010 Context2 : (null)
+0x014 Flags : 0
+0x018 NumberOfFcbs : 0
+0x01c NumberOfSrvOpens : 0
+0x020 MRxNetRootState : 0x2 ‘’
+0x021 Type : 0 ‘’
+0x022 PurgeRelationship : 0 ‘’
+0x023 PurgeSyncLocation : 0 ‘’
+0x024 DeviceType : 7
+0x028 pNetRootName : 0x88c0b0b8 _UNICODE_STRING “\tl-ws-node2”
+0x02c InnerNamePrefix : _UNICODE_STRING “”
+0x034 ParameterValidationStamp : 0
+0x038 NamedPipeParameters :
+0x038 DiskParameters :
+0x000 spacer : _MRX_NORMAL_NODE_HEADER
+0x008 SrvCall : 0x896e63e0 _SRV_CALL
+0x05c UpperFinalizationDone : 0 ‘’
+0x060 Condition : 4 ( Condition_Bad )
+0x064 TransitionWaitList : _LIST_ENTRY [0x88c0b06c - 0x88c0b06c]
+0x06c ScavengerFinalizationList : _LIST_ENTRY [0x88c0b074 - 0x88c0b074]
+0x074 PurgeSyncronizationContext : _PURGE_SYNCHRONIZATION_CONTEXT
+0x080 DefaultVNetRoot : (null)
+0x084 VirtualNetRoots : _LIST_ENTRY [0x89286e20 - 0x89286e20]
+0x08c NumberOfVirtualNetRoots : 1
+0x090 SerialNumberForEnum : 0xca
+0x094 PrefixEntry : _RX_PREFIX_ENTRY
+0x0cc FcbTable : _RX_FCB_TABLE

I’m really stuck. The thing is that this error occurs only on one specific file (but this file can be different on different test machines) and only when the user profile contains many small files.

Many thanks beforehand. Any suggestions will be highly appreciated.

WBR,
Konstantin Manurin

klif.sys is a driver from Kaspersky Labs. Have you followed up with them?

Yeah, recently I joined a team and now I work on this driver. :slight_smile: Hmmm, accidentally I exposed a driver name with _NET_ROOT structure (we deliberately built a driver with some reference to RDR stuff to make its structures accessible in WinDBG), but just now have seen this miss. :-))))
We also noticed that if FltGetFileNameInformation() is called with FLT_FILE_NAME_OPENED flag in PreCreate() mini-filter callback, this odd error persists, on the other hand using an FLT_FILE_NAME_NORMALIZED flag solves this problem, but it’s not acceptable on the score of performance degradation.
I don’t know but perhaps this error is related to using communication port API in Pre- and PostCreate() callbacks? We tried to disable this communication calls in both create callbacks and it also surprisingly eliminated this flaw.
Further we tried to patch on the fly several mini-redirector MRx dispatch callbacks and figured out that at some point of time MRxExtractNetRootName() callback received only a server name as a FilePathName parameter and returned in NetRootName some useless string (as I think it was a part of the server name string).

WBR,
Konstantin Manurin