Hi,
I am working on pseudo file system driver that uses NTFS as a backing store.
Recently a customer got two crashes both in NTFS after my driver closed the
file.
The stack shows
1: kd> kb
ChildEBP RetAddr Args to Child
b8f73834 80938373 badb0d00 00000000 00000001 nt!KiTrap0E+0x2a7
b8f738e4 f721a0ac 8a13d798 b8f73914 00000400 nt!CcMapData+0x8c
b8f73904 f721a6e6 853fe008 8a160008 58543800 Ntfs!NtfsMapStream+0x4b
b8f73978 f721a045 853fe008 8a011100 e892d010 Ntfs!NtfsReadMftRecord+0x86
b8f739b0 f721a0f4 853fe008 8a011100 e892d010 Ntfs!NtfsReadFileRecord+0x7a
b8f739e8 f7212db5 853fe008 e892d008 e892d010
Ntfs!NtfsLookupInFileRecord+0x37
b8f73ac0 f7212c6a 853fe008 e6e5f738 b8f73b84 Ntfs!NtfsWriteFileSizes+0x76
b8f73ba8 f7213699 853fe008 8847feb8 86a7a8d0 Ntfs!NtfsSetEndOfFileInfo+0xaa
b8f73c18 f71e62fb 853fe008 86a7a8d0 8a127ee8
Ntfs!NtfsCommonSetInformation+0x474
b8f73c80 8083f9d0 8a011020 86a7a8d0 8a6a6898 Ntfs!NtfsFsdSetInformation+0xa3
b8f73c94 f72c6c53 8a6a6898 8847feb8 0000000a nt!IofCallDriver+0x45
b8f73cbc 8083f9d0 8a127ee8 86a7a8d0 8a127ee8 fltmgr!FltpDispatch+0x6f
b8f73cd0 80831293 00000000 8833b858 80a790e0 nt!IofCallDriver+0x45
b8f73d04 80830983 8847feb8 b8f73d2c 808acbb0 nt!CcSetValidData+0xa6
b8f73d40 8082fbf4 87f0b918 808b70a0 8a77ea18 nt!CcWriteBehind+0x25a
b8f73d80 8083f72e 8a77ea18 00000000 87f0b918 nt!CcWorkerThread+0x12c
b8f73dac 8092ccff 8a77ea18 00000000 00000000 nt!ExpWorkerThread+0xeb
b8f73ddc 80841a96 8083f671 80000000 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
The file object passed to CcMapData is $Mft.
The IRP for Ntfs!NtfsFsdSetInformation contains
1: kd> !irp 86a7a8d0
Irp is active with 10 stacks 10 is current (= 0x86a7aa84)
No Mdl Irp count = b8f73cfc Thread 87f0b918: Irp stack trace.
…
Args: 00000000 00000000 00000000 00000000
[6, 0] 0 0 8a011020 8847feb8 00000000-00000000
\FileSystem\Ntfs
Args: 00000008 00000014 00000000 00000100
The file object at 8847feb8 shows
1: kd> dt nt!_FILE_OBJECT 8847feb8
+0x000 Type : 5
+0x002 Size : 112
+0x004 DeviceObject : 0x8a7456e0
+0x008 Vpb : 0x8a745658
+0x00c FsContext : 0xe6e5f738
+0x010 FsContext2 : 0xe7997708
+0x014 SectionObjectPointer : 0x873a881c
+0x018 PrivateCacheMap : (null)
+0x01c FinalStatus : 0
+0x020 RelatedFileObject : 0x87c6aea0
+0x024 LockOperation : 0 ‘’
+0x025 DeletePending : 0 ‘’
+0x026 ReadAccess : 0x1 ‘’
+0x027 WriteAccess : 0x1 ‘’
+0x028 DeleteAccess : 0 ‘’
+0x029 SharedRead : 0x1 ‘’
+0x02a SharedWrite : 0x1 ‘’
+0x02b SharedDelete : 0x1 ‘’
+0x02c Flags : 0x44040
+0x030 FileName : _UNICODE_STRING
“\folder1\folder2\folder3\folder4\folder5\file1”
+0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
+0x040 Waiters : 0
+0x044 Busy : 0
+0x048 LastLock : (null)
+0x04c Lock : _KEVENT
+0x05c Event : _KEVENT
+0x06c CompletionContext : (null)
1: kd> dt nt!_FILE_OBJECT 0x87c6aea0
+0x000 Type : 5
+0x002 Size : 112
+0x004 DeviceObject : 0x8a7456e0
+0x008 Vpb : 0x8a745658
+0x00c FsContext : 0xf18379a8
+0x010 FsContext2 : 0xe9e16398
+0x014 SectionObjectPointer : 0x87c573a4
+0x018 PrivateCacheMap : (null)
+0x01c FinalStatus : 0
+0x020 RelatedFileObject : 0x87a52640
+0x024 LockOperation : 0 ‘’
+0x025 DeletePending : 0 ‘’
+0x026 ReadAccess : 0x1 ‘’
+0x027 WriteAccess : 0x1 ‘’
+0x028 DeleteAccess : 0 ‘’
+0x029 SharedRead : 0x1 ‘’
+0x02a SharedWrite : 0x1 ‘’
+0x02b SharedDelete : 0x1 ‘’
+0x02c Flags : 0x44040
+0x030 FileName : _UNICODE_STRING
“\folder1\folder2\folder3\folder4\folder6\file2”
+0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
+0x040 Waiters : 0
+0x044 Busy : 0
+0x048 LastLock : (null)
+0x04c Lock : _KEVENT
+0x05c Event : _KEVENT
+0x06c CompletionContext : (null)
Note that folder1…4 are same.
Any idea why this would happen? It’s on W2K3 SP1.
Thanks,
I guess the question is when/how can the related fileobject point to a
completely different path?
–suresh
“Hrishikesh Vidwans” wrote in message
news:xxxxx@ntfsd…
> Hi,
>
> I am working on pseudo file system driver that uses NTFS as a backing
> store.
> Recently a customer got two crashes both in NTFS after my driver closed
> the file.
>
> The stack shows
> 1: kd> kb
> ChildEBP RetAddr Args to Child
> b8f73834 80938373 badb0d00 00000000 00000001 nt!KiTrap0E+0x2a7
> b8f738e4 f721a0ac 8a13d798 b8f73914 00000400 nt!CcMapData+0x8c
> b8f73904 f721a6e6 853fe008 8a160008 58543800 Ntfs!NtfsMapStream+0x4b
> b8f73978 f721a045 853fe008 8a011100 e892d010 Ntfs!NtfsReadMftRecord+0x86
> b8f739b0 f721a0f4 853fe008 8a011100 e892d010 Ntfs!NtfsReadFileRecord+0x7a
> b8f739e8 f7212db5 853fe008 e892d008 e892d010
> Ntfs!NtfsLookupInFileRecord+0x37
> b8f73ac0 f7212c6a 853fe008 e6e5f738 b8f73b84 Ntfs!NtfsWriteFileSizes+0x76
> b8f73ba8 f7213699 853fe008 8847feb8 86a7a8d0
> Ntfs!NtfsSetEndOfFileInfo+0xaa
> b8f73c18 f71e62fb 853fe008 86a7a8d0 8a127ee8
> Ntfs!NtfsCommonSetInformation+0x474
> b8f73c80 8083f9d0 8a011020 86a7a8d0 8a6a6898
> Ntfs!NtfsFsdSetInformation+0xa3
> b8f73c94 f72c6c53 8a6a6898 8847feb8 0000000a nt!IofCallDriver+0x45
> b8f73cbc 8083f9d0 8a127ee8 86a7a8d0 8a127ee8 fltmgr!FltpDispatch+0x6f
> b8f73cd0 80831293 00000000 8833b858 80a790e0 nt!IofCallDriver+0x45
> b8f73d04 80830983 8847feb8 b8f73d2c 808acbb0 nt!CcSetValidData+0xa6
> b8f73d40 8082fbf4 87f0b918 808b70a0 8a77ea18 nt!CcWriteBehind+0x25a
> b8f73d80 8083f72e 8a77ea18 00000000 87f0b918 nt!CcWorkerThread+0x12c
> b8f73dac 8092ccff 8a77ea18 00000000 00000000 nt!ExpWorkerThread+0xeb
> b8f73ddc 80841a96 8083f671 80000000 00000000
> nt!PspSystemThreadStartup+0x2e
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
> The file object passed to CcMapData is $Mft.
>
> The IRP for Ntfs!NtfsFsdSetInformation contains
>
> 1: kd> !irp 86a7a8d0
> Irp is active with 10 stacks 10 is current (= 0x86a7aa84)
> No Mdl Irp count = b8f73cfc Thread 87f0b918: Irp stack trace.
> …
> Args: 00000000 00000000 00000000 00000000
>>[6, 0] 0 0 8a011020 8847feb8 00000000-00000000
> \FileSystem\Ntfs
> Args: 00000008 00000014 00000000 00000100
>
> The file object at 8847feb8 shows
>
> 1: kd> dt nt!_FILE_OBJECT 8847feb8
> +0x000 Type : 5
> +0x002 Size : 112
> +0x004 DeviceObject : 0x8a7456e0
> +0x008 Vpb : 0x8a745658
> +0x00c FsContext : 0xe6e5f738
> +0x010 FsContext2 : 0xe7997708
> +0x014 SectionObjectPointer : 0x873a881c
> +0x018 PrivateCacheMap : (null)
> +0x01c FinalStatus : 0
> +0x020 RelatedFileObject : 0x87c6aea0
> +0x024 LockOperation : 0 ‘’
> +0x025 DeletePending : 0 ‘’
> +0x026 ReadAccess : 0x1 ‘’
> +0x027 WriteAccess : 0x1 ‘’
> +0x028 DeleteAccess : 0 ‘’
> +0x029 SharedRead : 0x1 ‘’
> +0x02a SharedWrite : 0x1 ‘’
> +0x02b SharedDelete : 0x1 ‘’
> +0x02c Flags : 0x44040
> +0x030 FileName : _UNICODE_STRING
> “\folder1\folder2\folder3\folder4\folder5\file1”
> +0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
> +0x040 Waiters : 0
> +0x044 Busy : 0
> +0x048 LastLock : (null)
> +0x04c Lock : _KEVENT
> +0x05c Event : _KEVENT
> +0x06c CompletionContext : (null)
>
> 1: kd> dt nt!_FILE_OBJECT 0x87c6aea0
> +0x000 Type : 5
> +0x002 Size : 112
> +0x004 DeviceObject : 0x8a7456e0
> +0x008 Vpb : 0x8a745658
> +0x00c FsContext : 0xf18379a8
> +0x010 FsContext2 : 0xe9e16398
> +0x014 SectionObjectPointer : 0x87c573a4
> +0x018 PrivateCacheMap : (null)
> +0x01c FinalStatus : 0
> +0x020 RelatedFileObject : 0x87a52640
> +0x024 LockOperation : 0 ‘’
> +0x025 DeletePending : 0 ‘’
> +0x026 ReadAccess : 0x1 ‘’
> +0x027 WriteAccess : 0x1 ‘’
> +0x028 DeleteAccess : 0 ‘’
> +0x029 SharedRead : 0x1 ‘’
> +0x02a SharedWrite : 0x1 ‘’
> +0x02b SharedDelete : 0x1 ‘’
> +0x02c Flags : 0x44040
> +0x030 FileName : _UNICODE_STRING
> “\folder1\folder2\folder3\folder4\folder6\file2”
> +0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
> +0x040 Waiters : 0
> +0x044 Busy : 0
> +0x048 LastLock : (null)
> +0x04c Lock : _KEVENT
> +0x05c Event : _KEVENT
> +0x06c CompletionContext : (null)
>
> Note that folder1…4 are same.
>
> Any idea why this would happen? It’s on W2K3 SP1.
>
> Thanks,
> - Hrishikesh.
>
>
Any time outside the IRP_MJ_CREATE path. Keep in mind that I can do the
following:
Open Directory
Open File Relative To Directory
Close Directory (note the file is still open)
Open Different Directory
Set File EOF
…
Now if the file object that was used for the directory gets recycled and
used for the 2nd directory, the file object for the *file* might point
to it.
There is no protection of the FileObject->RelatedFileObject outside the
IRP_MJ_CREATE path. Indeed, this is the reason this isn’t transitive
(FileObject->RelatedFileObject->RelatedFileObject is not necessarily
valid, although it might seem it will be valid - it can - and sometimes
is - garbage.)
So the rule is that unless your driver owns the file objects you can’t
count on this relationship outside the IRP_MJ_CREATE path.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 24-27, 2006.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Suresh
Gopalakrishnan
Sent: Tuesday, December 20, 2005 7:02 PM
To: ntfsd redirect
Subject: Re:[ntfsd] wierd problem with NTFS file objects…
I guess the question is when/how can the related fileobject point to a
completely different path?
–suresh
“Hrishikesh Vidwans” wrote in message
news:xxxxx@ntfsd…
> Hi,
>
> I am working on pseudo file system driver that uses NTFS as a backing
> store.
> Recently a customer got two crashes both in NTFS after my driver
closed
> the file.
>
> The stack shows
> 1: kd> kb
> ChildEBP RetAddr Args to Child
> b8f73834 80938373 badb0d00 00000000 00000001 nt!KiTrap0E+0x2a7
> b8f738e4 f721a0ac 8a13d798 b8f73914 00000400 nt!CcMapData+0x8c
> b8f73904 f721a6e6 853fe008 8a160008 58543800 Ntfs!NtfsMapStream+0x4b
> b8f73978 f721a045 853fe008 8a011100 e892d010
Ntfs!NtfsReadMftRecord+0x86
> b8f739b0 f721a0f4 853fe008 8a011100 e892d010
Ntfs!NtfsReadFileRecord+0x7a
> b8f739e8 f7212db5 853fe008 e892d008 e892d010
> Ntfs!NtfsLookupInFileRecord+0x37
> b8f73ac0 f7212c6a 853fe008 e6e5f738 b8f73b84
Ntfs!NtfsWriteFileSizes+0x76
> b8f73ba8 f7213699 853fe008 8847feb8 86a7a8d0
> Ntfs!NtfsSetEndOfFileInfo+0xaa
> b8f73c18 f71e62fb 853fe008 86a7a8d0 8a127ee8
> Ntfs!NtfsCommonSetInformation+0x474
> b8f73c80 8083f9d0 8a011020 86a7a8d0 8a6a6898
> Ntfs!NtfsFsdSetInformation+0xa3
> b8f73c94 f72c6c53 8a6a6898 8847feb8 0000000a nt!IofCallDriver+0x45
> b8f73cbc 8083f9d0 8a127ee8 86a7a8d0 8a127ee8 fltmgr!FltpDispatch+0x6f
> b8f73cd0 80831293 00000000 8833b858 80a790e0 nt!IofCallDriver+0x45
> b8f73d04 80830983 8847feb8 b8f73d2c 808acbb0 nt!CcSetValidData+0xa6
> b8f73d40 8082fbf4 87f0b918 808b70a0 8a77ea18 nt!CcWriteBehind+0x25a
> b8f73d80 8083f72e 8a77ea18 00000000 87f0b918 nt!CcWorkerThread+0x12c
> b8f73dac 8092ccff 8a77ea18 00000000 00000000 nt!ExpWorkerThread+0xeb
> b8f73ddc 80841a96 8083f671 80000000 00000000
> nt!PspSystemThreadStartup+0x2e
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
> The file object passed to CcMapData is $Mft.
>
> The IRP for Ntfs!NtfsFsdSetInformation contains
>
> 1: kd> !irp 86a7a8d0
> Irp is active with 10 stacks 10 is current (= 0x86a7aa84)
> No Mdl Irp count = b8f73cfc Thread 87f0b918: Irp stack trace.
> …
> Args: 00000000 00000000 00000000 00000000
>>[6, 0] 0 0 8a011020 8847feb8 00000000-00000000
> \FileSystem\Ntfs
> Args: 00000008 00000014 00000000 00000100
>
> The file object at 8847feb8 shows
>
> 1: kd> dt nt!_FILE_OBJECT 8847feb8
> +0x000 Type : 5
> +0x002 Size : 112
> +0x004 DeviceObject : 0x8a7456e0
> +0x008 Vpb : 0x8a745658
> +0x00c FsContext : 0xe6e5f738
> +0x010 FsContext2 : 0xe7997708
> +0x014 SectionObjectPointer : 0x873a881c
> +0x018 PrivateCacheMap : (null)
> +0x01c FinalStatus : 0
> +0x020 RelatedFileObject : 0x87c6aea0
> +0x024 LockOperation : 0 ‘’
> +0x025 DeletePending : 0 ‘’
> +0x026 ReadAccess : 0x1 ‘’
> +0x027 WriteAccess : 0x1 ‘’
> +0x028 DeleteAccess : 0 ‘’
> +0x029 SharedRead : 0x1 ‘’
> +0x02a SharedWrite : 0x1 ‘’
> +0x02b SharedDelete : 0x1 ‘’
> +0x02c Flags : 0x44040
> +0x030 FileName : _UNICODE_STRING
> “\folder1\folder2\folder3\folder4\folder5\file1”
> +0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
> +0x040 Waiters : 0
> +0x044 Busy : 0
> +0x048 LastLock : (null)
> +0x04c Lock : _KEVENT
> +0x05c Event : _KEVENT
> +0x06c CompletionContext : (null)
>
> 1: kd> dt nt!_FILE_OBJECT 0x87c6aea0
> +0x000 Type : 5
> +0x002 Size : 112
> +0x004 DeviceObject : 0x8a7456e0
> +0x008 Vpb : 0x8a745658
> +0x00c FsContext : 0xf18379a8
> +0x010 FsContext2 : 0xe9e16398
> +0x014 SectionObjectPointer : 0x87c573a4
> +0x018 PrivateCacheMap : (null)
> +0x01c FinalStatus : 0
> +0x020 RelatedFileObject : 0x87a52640
> +0x024 LockOperation : 0 ‘’
> +0x025 DeletePending : 0 ‘’
> +0x026 ReadAccess : 0x1 ‘’
> +0x027 WriteAccess : 0x1 ‘’
> +0x028 DeleteAccess : 0 ‘’
> +0x029 SharedRead : 0x1 ‘’
> +0x02a SharedWrite : 0x1 ‘’
> +0x02b SharedDelete : 0x1 ‘’
> +0x02c Flags : 0x44040
> +0x030 FileName : _UNICODE_STRING
> “\folder1\folder2\folder3\folder4\folder6\file2”
> +0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
> +0x040 Waiters : 0
> +0x044 Busy : 0
> +0x048 LastLock : (null)
> +0x04c Lock : _KEVENT
> +0x05c Event : _KEVENT
> +0x06c CompletionContext : (null)
>
> Note that folder1…4 are same.
>
> Any idea why this would happen? It’s on W2K3 SP1.
>
> Thanks,
> - Hrishikesh.
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks Tony,
Is it safe to assume that for a valid file object, the file name pointer
will always contain the same string that was passed during IRP_MJ_CREATE or
can that too get recycled?
Thanks,
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Any time outside the IRP_MJ_CREATE path. Keep in mind that I can do the
following:
Open Directory
Open File Relative To Directory
Close Directory (note the file is still open)
Open Different Directory
Set File EOF
…
Now if the file object that was used for the directory gets recycled and
used for the 2nd directory, the file object for the file might point
to it.
There is no protection of the FileObject->RelatedFileObject outside the
IRP_MJ_CREATE path. Indeed, this is the reason this isn’t transitive
(FileObject->RelatedFileObject->RelatedFileObject is not necessarily
valid, although it might seem it will be valid - it can - and sometimes
is - garbage.)
So the rule is that unless your driver owns the file objects you can’t
count on this relationship outside the IRP_MJ_CREATE path.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 24-27, 2006.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Suresh
Gopalakrishnan
Sent: Tuesday, December 20, 2005 7:02 PM
To: ntfsd redirect
Subject: Re:[ntfsd] wierd problem with NTFS file objects…
I guess the question is when/how can the related fileobject point to a
completely different path?
–suresh
“Hrishikesh Vidwans” wrote in message
news:xxxxx@ntfsd…
> Hi,
>
> I am working on pseudo file system driver that uses NTFS as a backing
> store.
> Recently a customer got two crashes both in NTFS after my driver
closed
> the file.
>
> The stack shows
> 1: kd> kb
> ChildEBP RetAddr Args to Child
> b8f73834 80938373 badb0d00 00000000 00000001 nt!KiTrap0E+0x2a7
> b8f738e4 f721a0ac 8a13d798 b8f73914 00000400 nt!CcMapData+0x8c
> b8f73904 f721a6e6 853fe008 8a160008 58543800 Ntfs!NtfsMapStream+0x4b
> b8f73978 f721a045 853fe008 8a011100 e892d010
Ntfs!NtfsReadMftRecord+0x86
> b8f739b0 f721a0f4 853fe008 8a011100 e892d010
Ntfs!NtfsReadFileRecord+0x7a
> b8f739e8 f7212db5 853fe008 e892d008 e892d010
> Ntfs!NtfsLookupInFileRecord+0x37
> b8f73ac0 f7212c6a 853fe008 e6e5f738 b8f73b84
Ntfs!NtfsWriteFileSizes+0x76
> b8f73ba8 f7213699 853fe008 8847feb8 86a7a8d0
> Ntfs!NtfsSetEndOfFileInfo+0xaa
> b8f73c18 f71e62fb 853fe008 86a7a8d0 8a127ee8
> Ntfs!NtfsCommonSetInformation+0x474
> b8f73c80 8083f9d0 8a011020 86a7a8d0 8a6a6898
> Ntfs!NtfsFsdSetInformation+0xa3
> b8f73c94 f72c6c53 8a6a6898 8847feb8 0000000a nt!IofCallDriver+0x45
> b8f73cbc 8083f9d0 8a127ee8 86a7a8d0 8a127ee8 fltmgr!FltpDispatch+0x6f
> b8f73cd0 80831293 00000000 8833b858 80a790e0 nt!IofCallDriver+0x45
> b8f73d04 80830983 8847feb8 b8f73d2c 808acbb0 nt!CcSetValidData+0xa6
> b8f73d40 8082fbf4 87f0b918 808b70a0 8a77ea18 nt!CcWriteBehind+0x25a
> b8f73d80 8083f72e 8a77ea18 00000000 87f0b918 nt!CcWorkerThread+0x12c
> b8f73dac 8092ccff 8a77ea18 00000000 00000000 nt!ExpWorkerThread+0xeb
> b8f73ddc 80841a96 8083f671 80000000 00000000
> nt!PspSystemThreadStartup+0x2e
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
> The file object passed to CcMapData is $Mft.
>
> The IRP for Ntfs!NtfsFsdSetInformation contains
>
> 1: kd> !irp 86a7a8d0
> Irp is active with 10 stacks 10 is current (= 0x86a7aa84)
> No Mdl Irp count = b8f73cfc Thread 87f0b918: Irp stack trace.
> …
> Args: 00000000 00000000 00000000 00000000
>>[6, 0] 0 0 8a011020 8847feb8 00000000-00000000
> \FileSystem\Ntfs
> Args: 00000008 00000014 00000000 00000100
>
> The file object at 8847feb8 shows
>
> 1: kd> dt nt!_FILE_OBJECT 8847feb8
> +0x000 Type : 5
> +0x002 Size : 112
> +0x004 DeviceObject : 0x8a7456e0
> +0x008 Vpb : 0x8a745658
> +0x00c FsContext : 0xe6e5f738
> +0x010 FsContext2 : 0xe7997708
> +0x014 SectionObjectPointer : 0x873a881c
> +0x018 PrivateCacheMap : (null)
> +0x01c FinalStatus : 0
> +0x020 RelatedFileObject : 0x87c6aea0
> +0x024 LockOperation : 0 ‘’
> +0x025 DeletePending : 0 ‘’
> +0x026 ReadAccess : 0x1 ‘’
> +0x027 WriteAccess : 0x1 ‘’
> +0x028 DeleteAccess : 0 ‘’
> +0x029 SharedRead : 0x1 ‘’
> +0x02a SharedWrite : 0x1 ‘’
> +0x02b SharedDelete : 0x1 ‘’
> +0x02c Flags : 0x44040
> +0x030 FileName : _UNICODE_STRING
> “\folder1\folder2\folder3\folder4\folder5\file1”
> +0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
> +0x040 Waiters : 0
> +0x044 Busy : 0
> +0x048 LastLock : (null)
> +0x04c Lock : _KEVENT
> +0x05c Event : _KEVENT
> +0x06c CompletionContext : (null)
>
> 1: kd> dt nt!_FILE_OBJECT 0x87c6aea0
> +0x000 Type : 5
> +0x002 Size : 112
> +0x004 DeviceObject : 0x8a7456e0
> +0x008 Vpb : 0x8a745658
> +0x00c FsContext : 0xf18379a8
> +0x010 FsContext2 : 0xe9e16398
> +0x014 SectionObjectPointer : 0x87c573a4
> +0x018 PrivateCacheMap : (null)
> +0x01c FinalStatus : 0
> +0x020 RelatedFileObject : 0x87a52640
> +0x024 LockOperation : 0 ‘’
> +0x025 DeletePending : 0 ‘’
> +0x026 ReadAccess : 0x1 ‘’
> +0x027 WriteAccess : 0x1 ‘’
> +0x028 DeleteAccess : 0 ‘’
> +0x029 SharedRead : 0x1 ‘’
> +0x02a SharedWrite : 0x1 ‘’
> +0x02b SharedDelete : 0x1 ‘’
> +0x02c Flags : 0x44040
> +0x030 FileName : _UNICODE_STRING
> “\folder1\folder2\folder3\folder4\folder6\file2”
> +0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
> +0x040 Waiters : 0
> +0x044 Busy : 0
> +0x048 LastLock : (null)
> +0x04c Lock : _KEVENT
> +0x05c Event : _KEVENT
> +0x06c CompletionContext : (null)
>
> Note that folder1…4 are same.
>
> Any idea why this would happen? It’s on W2K3 SP1.
>
> Thanks,
> - Hrishikesh.
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Not only is this not guaranteed, it isn’t even true with the current
file systems. Never trust the contents of that buffer once it comes
back from the layer below you. Either ASK the underlying FSD (and cache
the information because this is “expensive”) or cache the information
during first create.
As a testing mechanism in some of my own file systems I’ve deleted the
file name from the file object (why waste the paged pool after all - it
IS a scarce resource these days…) No reasonable file system is going
to rely upon the name in the file object after the initial create anyway
(I think every one I’ve ever seen saves away the “real” name somewhere.)
For example, don’t count on that name being updated properly during a
rename operation.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hrishikesh Vidwans
Sent: Wednesday, December 21, 2005 5:28 PM
To: ntfsd redirect
Subject: Re:[ntfsd] wierd problem with NTFS file objects…
Thanks Tony,
Is it safe to assume that for a valid file object, the file name pointer
will always contain the same string that was passed during IRP_MJ_CREATE
or
can that too get recycled?
Thanks,
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Any time outside the IRP_MJ_CREATE path. Keep in mind that I can do the
following:
Open Directory
Open File Relative To Directory
Close Directory (note the file is still open)
Open Different Directory
Set File EOF
…
Now if the file object that was used for the directory gets recycled and
used for the 2nd directory, the file object for the file might point
to it.
There is no protection of the FileObject->RelatedFileObject outside the
IRP_MJ_CREATE path. Indeed, this is the reason this isn’t transitive
(FileObject->RelatedFileObject->RelatedFileObject is not necessarily
valid, although it might seem it will be valid - it can - and sometimes
is - garbage.)
So the rule is that unless your driver owns the file objects you can’t
count on this relationship outside the IRP_MJ_CREATE path.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 24-27, 2006.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Suresh
Gopalakrishnan
Sent: Tuesday, December 20, 2005 7:02 PM
To: ntfsd redirect
Subject: Re:[ntfsd] wierd problem with NTFS file objects…
I guess the question is when/how can the related fileobject point to a
completely different path?
–suresh
“Hrishikesh Vidwans” wrote in message
news:xxxxx@ntfsd…
> Hi,
>
> I am working on pseudo file system driver that uses NTFS as a backing
> store.
> Recently a customer got two crashes both in NTFS after my driver
closed
> the file.
>
> The stack shows
> 1: kd> kb
> ChildEBP RetAddr Args to Child
> b8f73834 80938373 badb0d00 00000000 00000001 nt!KiTrap0E+0x2a7
> b8f738e4 f721a0ac 8a13d798 b8f73914 00000400 nt!CcMapData+0x8c
> b8f73904 f721a6e6 853fe008 8a160008 58543800 Ntfs!NtfsMapStream+0x4b
> b8f73978 f721a045 853fe008 8a011100 e892d010
Ntfs!NtfsReadMftRecord+0x86
> b8f739b0 f721a0f4 853fe008 8a011100 e892d010
Ntfs!NtfsReadFileRecord+0x7a
> b8f739e8 f7212db5 853fe008 e892d008 e892d010
> Ntfs!NtfsLookupInFileRecord+0x37
> b8f73ac0 f7212c6a 853fe008 e6e5f738 b8f73b84
Ntfs!NtfsWriteFileSizes+0x76
> b8f73ba8 f7213699 853fe008 8847feb8 86a7a8d0
> Ntfs!NtfsSetEndOfFileInfo+0xaa
> b8f73c18 f71e62fb 853fe008 86a7a8d0 8a127ee8
> Ntfs!NtfsCommonSetInformation+0x474
> b8f73c80 8083f9d0 8a011020 86a7a8d0 8a6a6898
> Ntfs!NtfsFsdSetInformation+0xa3
> b8f73c94 f72c6c53 8a6a6898 8847feb8 0000000a nt!IofCallDriver+0x45
> b8f73cbc 8083f9d0 8a127ee8 86a7a8d0 8a127ee8 fltmgr!FltpDispatch+0x6f
> b8f73cd0 80831293 00000000 8833b858 80a790e0 nt!IofCallDriver+0x45
> b8f73d04 80830983 8847feb8 b8f73d2c 808acbb0 nt!CcSetValidData+0xa6
> b8f73d40 8082fbf4 87f0b918 808b70a0 8a77ea18 nt!CcWriteBehind+0x25a
> b8f73d80 8083f72e 8a77ea18 00000000 87f0b918 nt!CcWorkerThread+0x12c
> b8f73dac 8092ccff 8a77ea18 00000000 00000000 nt!ExpWorkerThread+0xeb
> b8f73ddc 80841a96 8083f671 80000000 00000000
> nt!PspSystemThreadStartup+0x2e
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
> The file object passed to CcMapData is $Mft.
>
> The IRP for Ntfs!NtfsFsdSetInformation contains
>
> 1: kd> !irp 86a7a8d0
> Irp is active with 10 stacks 10 is current (= 0x86a7aa84)
> No Mdl Irp count = b8f73cfc Thread 87f0b918: Irp stack trace.
> …
> Args: 00000000 00000000 00000000 00000000
>>[6, 0] 0 0 8a011020 8847feb8 00000000-00000000
> \FileSystem\Ntfs
> Args: 00000008 00000014 00000000 00000100
>
> The file object at 8847feb8 shows
>
> 1: kd> dt nt!_FILE_OBJECT 8847feb8
> +0x000 Type : 5
> +0x002 Size : 112
> +0x004 DeviceObject : 0x8a7456e0
> +0x008 Vpb : 0x8a745658
> +0x00c FsContext : 0xe6e5f738
> +0x010 FsContext2 : 0xe7997708
> +0x014 SectionObjectPointer : 0x873a881c
> +0x018 PrivateCacheMap : (null)
> +0x01c FinalStatus : 0
> +0x020 RelatedFileObject : 0x87c6aea0
> +0x024 LockOperation : 0 ‘’
> +0x025 DeletePending : 0 ‘’
> +0x026 ReadAccess : 0x1 ‘’
> +0x027 WriteAccess : 0x1 ‘’
> +0x028 DeleteAccess : 0 ‘’
> +0x029 SharedRead : 0x1 ‘’
> +0x02a SharedWrite : 0x1 ‘’
> +0x02b SharedDelete : 0x1 ‘’
> +0x02c Flags : 0x44040
> +0x030 FileName : _UNICODE_STRING
> “\folder1\folder2\folder3\folder4\folder5\file1”
> +0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
> +0x040 Waiters : 0
> +0x044 Busy : 0
> +0x048 LastLock : (null)
> +0x04c Lock : _KEVENT
> +0x05c Event : _KEVENT
> +0x06c CompletionContext : (null)
>
> 1: kd> dt nt!_FILE_OBJECT 0x87c6aea0
> +0x000 Type : 5
> +0x002 Size : 112
> +0x004 DeviceObject : 0x8a7456e0
> +0x008 Vpb : 0x8a745658
> +0x00c FsContext : 0xf18379a8
> +0x010 FsContext2 : 0xe9e16398
> +0x014 SectionObjectPointer : 0x87c573a4
> +0x018 PrivateCacheMap : (null)
> +0x01c FinalStatus : 0
> +0x020 RelatedFileObject : 0x87a52640
> +0x024 LockOperation : 0 ‘’
> +0x025 DeletePending : 0 ‘’
> +0x026 ReadAccess : 0x1 ‘’
> +0x027 WriteAccess : 0x1 ‘’
> +0x028 DeleteAccess : 0 ‘’
> +0x029 SharedRead : 0x1 ‘’
> +0x02a SharedWrite : 0x1 ‘’
> +0x02b SharedDelete : 0x1 ‘’
> +0x02c Flags : 0x44040
> +0x030 FileName : _UNICODE_STRING
> “\folder1\folder2\folder3\folder4\folder6\file2”
> +0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
> +0x040 Waiters : 0
> +0x044 Busy : 0
> +0x048 LastLock : (null)
> +0x04c Lock : _KEVENT
> +0x05c Event : _KEVENT
> +0x06c CompletionContext : (null)
>
> Note that folder1…4 are same.
>
> Any idea why this would happen? It’s on W2K3 SP1.
>
> Thanks,
> - Hrishikesh.
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com