In my filter driver I am attempting to change the target file name during
the rename operation (IRP_MJ_SET_INFORMATION). Basically an application
requests a rename to a.txt (say) and I am trying to rename that to b.txt.
Both files reside on the same volume.
The general approach that I am taking is:
-
Construct a FILE_RENAME_INFORMATION structure in NonPagedPool that
contains both the base structure as well as the new file target file name
for the rename operation. -
Populate the above structure with the following fields.
RootDirectory = NULL, ReplaceIfExists = FALSE, FileNameLength = ByteCount,
FileName = New file name
a. The format of the new filename is NT native file name
(\device\harddiskvolume1<path><file>). It is a fully qualified path.
3. Keep a pointer to Irp->AssociatedIrp.SystemBuffer and maintain the
value of Irp->Parameters.SetFile.Length in my dispatch routine
4. Set Irp->AssociatedIrp.SystemBuffer to my allocated structure from
(1)
5. Set Irp->Parameters.SetFile.Length to the size of memory allocated
in (1)
6. Set a completion routine that synchronizes back to the
IRP_MJ_SET_INFORMATION dispatch routine
7. Call IoCallDriver to pass the request down the stack.
8. Wait on the event until it is signaled in the completion routine
9. Upon the event being signaled I restore
Irp->Parameters.SetFile.Length and Irp->AssociatedIrp.SystemBuffer to what
they were before I replaced them.
10. Free my allocated buffer
11. IoCompleteRequest etc.
I am finding that this leads to traps in Ntfs with the stack dump (some
details hidden) below. This is a Windows 2000 Server machine. The problem
hasn’t (yet) been seen on Win2k3. The stack trace varies, however the
commonality on all of the traps is that the faulting module is either
ntfs.sys or tmfilter.sys or MYDRIVER.sys, where MYDRIVER is the filter
driver I am developing.
Questions:
1) Is this approach where I replace SystemBuffer with my own buffer
valid? If not can anyone suggest an alternative approach? If it is then
I’ve got some memory allocation screwed up somewhere.
2) Does NTFS free Irp->AssociatedIrp.SystemBuffer at all under any
circumstances (in which case I shouldn’t be freeing it)?
3) On a Windows 2000 machine is it valid to synchronize back to the
dispatch routine for IRP_MJ_SET_INFORMATION. I believe this is safe, and if
so is it valid to free memory allocated on the other side of the
IoCallDriver function call following the completion routine synchronizing
back to the dispatch routine? Again I believe this is safe, but I’m ready
to believe anything at the moment.
Thank you for any information that you can provide.
[Views expressed are not those of Citrix]
Obfuscated stack trace.
f08622c4 8042aa0f 00000003 f086230c e2d68008
nt!RtlpBreakWithStatusInstruction
f08622f4 8042b002 00000003 c038b5a0 800655e0 nt!KiBugCheckDebugBreak+0x31
f0862680 8044a99a 00000000 e2d68008 00000001 nt!KeBugCheckEx+0x390
f08626cc 804696bf 00000001 e2d68008 00000000 nt!MmAccessFault+0x7da
f08626cc f8817b52 00000001 e2d68008 00000000 nt!KiTrap0E+0xc7
f0862768 f87fc65c 818e7ee8 0000009a e29c38d8 Ntfs!NtfsMoveLcb+0x22c
f0862818 f87fabe9 818e7ee8 f08629e4 f086293c Ntfs!NtfsMoveLinkToNewDir+0x1da
f0862a18 f87cc436 818e7ee8 8199f028 f588de70 Ntfs!NtfsSetRenameInfo+0xd17
f0862ab4 f87bf8c3 818e7ee8 f588de70 81fc6020
Ntfs!NtfsCommonSetInformation+0x453
f0862b24 8041de41 81fc6020 f588de70 000000c9 Ntfs!NtfsFsdSetInformation+0xbf
f0862b38 80528e55 f588dfd4 f588dff8 f588de70 nt!IopfCallDriver+0x35
f0862b54 f8854119 00000046 81dc6de8 00000000 nt!IovCallDriver+0x77
f0862b68 f8853a9b f0862b8c 81fc74e0 f0862bf0
[MYDRIVER]!MYDRIVER_CompletionStuff+0x187
f0862be4 f88520de 81fc74e0 f588de70 f588de70
[MYDRIVER]!MYDRIVER_SetInformation_Dispatch+0x1b1
f0862c28 f884f5df 81fc74e0 f588de70 8041de41
[MYDRIVER]!MYDRIVER_Dispatch2+0xac
f0862c34 8041de41 81fc74e0 f588de70 00000000
[MYDRIVER]!MYDRIVER_dispatch+0x53
f0862c48 804ab856 f0862d64 00fccdfc 804ab2e0 nt!IopfCallDriver+0x35
f0862d48 80466389 000001c0 00fcce30 01ca9fb8 nt!NtSetInformationFile+0x576
f0862d48 77f8ee33 000001c0 00fcce30 01ca9fb8 nt!KiSystemService+0xc9
00fccde0 7c4f0edd 000001c0 00fcce30 01ca9fb8 ntdll!NtSetInformationFile+0xb
00fccebc 7c4f66b3 01afa940 01f3dfc8 00000000
KERNEL32!MoveFileWithProgressW+0x319
00fcced4 004ae1e7 01afa940 01f3dfc8 00000000 KERNEL32!MoveFileW+0x13