Hello.
I know I already posted another newbie question today, but I’m having other problems and maybe someone can help me.
As i said in a previous thread, I’m trying to create a small minifilter that, when receives a IRP_MJ_CREATE that can potentially modify the file creates a backup file in
\Device\HardDiskVolumeX\Backup\ORIGINALPATH. To achieve this I’m checking for
FILE_WRITE_DATA and DELETE flags. So, for example, if the user is trying to open
C:\NewFolder\TextFile.txt, the backup that will be created will be
C:\Backup\NewFolder\TextFile.txt.
So, I implemented my small routine to take care for the creation of all the folders along a path (I try to create the file in the right folder, if it does not work I try to create the previous folder, and so on until I manage to create a folder, than going back to the subfolder and the file).
This works fine, the first time I open a file for which the backup tree (in the above case, C:\Backup\NewFolder) does not exists, it is created. Problem arises when I cant to open another file in the same original tree (C:\NewFolder) which causes a INVALID_KERNEL_HANDLE when closing the handle.
I posted here the code for the path creation: http://pastebin.com/jW4gYAiJ
and here the code that crashes: http://pastebin.com/Aiwdn6Ss
The flow that I managed to test is the following (I’ve a VM that is currently updating, so the IRPs are not under my control).
- First create with write flag arrives for C:\NewFolder\TextFile.txt (it is actually a windows update folder, but I think it is not important): C:\Backup\NewFolder does not exists, so the first FltCreateFile fails with error STATUS_OBJECT_PATH_NOT_FOUND
- The RWBRollPathFunction creates all the folders needed, then FltCreateFile works, and with windbg I see that it actually returns 0 (STATUS_SUCCESS), even if I did not currently check this return value (I’ll do it ASAP).
- FltClose is executed and does not raise problems.
- Second create with write flag arrives for C:\NewFolder\TextFile2.txt. The first FltCreate works (since the folders are already there) and the return code for the first FltCreaFile is STATUS_SUCCESS. FltCreateFile inside the IF statement is not executed since the status is STATUS_SUCCESS
- FltClose raises INVALID_KERNEL_OBJECT (0x93) error.
I’m stuck and I can not understand what I’m doing wrong. I can’t even understand what this error means, since the FltCreateFile is the same in both cases. I’m missing something, but I can’t figure out what. Any help would be really appreciated
FltClose requires a HANDLE, in the code that crashes you are passing a
pointer to a HANDLE, hence the INVALID_KERNEL_HANDLE. In the code for path
creation you are passing the handle correctly.
As a side note, I suggest you use the try-finally construct for cleanups
(see doc here https://msdn.microsoft.com/en-us/library/9xtt5hxz.aspx).
On 23 November 2015 at 23:46, wrote:
> Hello.
>
> I know I already posted another newbie question today, but I’m having
> other problems and maybe someone can help me.
>
> As i said in a previous thread, I’m trying to create a small minifilter
> that, when receives a IRP_MJ_CREATE that can potentially modify the file
> creates a backup file in
> \Device\HardDiskVolumeX\Backup\ORIGINALPATH. To achieve this I’m checking
> for
> FILE_WRITE_DATA and DELETE flags. So, for example, if the user is trying
> to open
> C:\NewFolder\TextFile.txt, the backup that will be created will be
> C:\Backup\NewFolder\TextFile.txt.
>
> So, I implemented my small routine to take care for the creation of all
> the folders along a path (I try to create the file in the right folder, if
> it does not work I try to create the previous folder, and so on until I
> manage to create a folder, than going back to the subfolder and the file).
>
> This works fine, the first time I open a file for which the backup tree
> (in the above case, C:\Backup\NewFolder) does not exists, it is created.
> Problem arises when I cant to open another file in the same original tree
> (C:\NewFolder) which causes a INVALID_KERNEL_HANDLE when closing the
> handle.
>
> I posted here the code for the path creation: http://pastebin.com/jW4gYAiJ
> and here the code that crashes: http://pastebin.com/Aiwdn6Ss
>
> The flow that I managed to test is the following (I’ve a VM that is
> currently updating, so the IRPs are not under my control).
>
> - First create with write flag arrives for C:\NewFolder\TextFile.txt (it
> is actually a windows update folder, but I think it is not important):
> C:\Backup\NewFolder does not exists, so the first FltCreateFile fails with
> error STATUS_OBJECT_PATH_NOT_FOUND
> - The RWBRollPathFunction creates all the folders needed, then
> FltCreateFile works, and with windbg I see that it actually returns 0
> (STATUS_SUCCESS), even if I did not currently check this return value (I’ll
> do it ASAP).
> - FltClose is executed and does not raise problems.
> - Second create with write flag arrives for C:\NewFolder\TextFile2.txt.
> The first FltCreate works (since the folders are already there) and the
> return code for the first FltCreaFile is STATUS_SUCCESS. FltCreateFile
> inside the IF statement is not executed since the status is STATUS_SUCCESS
> - FltClose raises INVALID_KERNEL_OBJECT (0x93) error.
>
> I’m stuck and I can not understand what I’m doing wrong. I can’t even
> understand what this error means, since the FltCreateFile is the same in
> both cases. I’m missing something, but I can’t figure out what. Any help
> would be really appreciated
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars 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
>
>FltClose requires a HANDLE, in the code that crashes you are passing a
pointer to a HANDLE, hence the INVALID_KERNEL_HANDLE. In the code for path
creation you are passing the handle correctly.
Oh my, I reallyt didn’t see that! I thought that the error was so sneaky that I couldn’t see the elephant in the room! Thank you! There’s still one thing I can’t understand: leaving apart the path creation (which was correct), and by looking only at the code for the file creation, the first time FltClose was executed it didn’t crash, even if I was using the pointer. The second time, it failed. Shouldn’t have it failed also the first time? This was the reason why I thought that the FltClose was correct and why I thought that the error was on how I was creating the file
As a side note, I suggest you use the try-finally construct for cleanups
(see doc here https://msdn.microsoft.com/en-us/library/9xtt5hxz.aspx)
Thank you! I’ll take a look at that right now! As you may have understood by now, I’m still a newbie on kernel programming, and every advice is very appreciated
Well not exactly, the checks done on the handle received as a parameter are
not exhaustive and by chance it is possible the pointer you sent to
correspond to a different valid handle from the handle table and the
function invocation might actually close a different handle (which is bad).
As another suggestion, you should always test your code using driver
verifier. It tends to catch these kinds of errors. One of its detection
methods is to add additional checks in existent kernel mode functions thus
increasing the chances for a BSOD in case of improper function usage. It is
also useful for catching things such as functions calls at improper IRQLs
and accessing paged-pool memory at IRQs >= DISPATCH_LEVEL.
On 24 November 2015 at 12:06, wrote:
> >FltClose requires a HANDLE, in the code that crashes you are passing a
> >pointer to a HANDLE, hence the INVALID_KERNEL_HANDLE. In the code for path
> >creation you are passing the handle correctly.
>
> Oh my, I reallyt didn’t see that! I thought that the error was so sneaky
> that I couldn’t see the elephant in the room! Thank you! There’s still one
> thing I can’t understand: leaving apart the path creation (which was
> correct), and by looking only at the code for the file creation, the first
> time FltClose was executed it didn’t crash, even if I was using the
> pointer. The second time, it failed. Shouldn’t have it failed also the
> first time? This was the reason why I thought that the FltClose was correct
> and why I thought that the error was on how I was creating the file
>
> >As a side note, I suggest you use the try-finally construct for cleanups
> >(see doc here https://msdn.microsoft.com/en-us/library/9xtt5hxz.aspx)
>
> Thank you! I’ll take a look at that right now! As you may have understood
> by now, I’m still a newbie on kernel programming, and every advice is very
> appreciated
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars 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
>
I’ll use it for sure! Have a nice day and thank you again 