FltGetFileNameInformation fails with STATUS_INVALID_DEVICE_REQUEST

I am trying to use FltGetFileNameInformation in my post create callback function from my mini filter driver to get the file name. I tried with the below 2 flag combinations
1.FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT.
2. FLT_FILE_NAME_OPENED | FLT_FILE_NAME_QUERY_DEFAULT
Both fails.
Error code : STATUS_INVALID_DEVICE_REQUEST when I use “FLT_FILE_NAME_OPENED | FLT_FILE_NAME_QUERY_DEFAULT”

This post create function gets called when I try to do “Save as” on a network file. Due to this error I couldn’t do a “save As”. Error pops up and when I click the save button again it gets saved. when I looked into my driver logs I could see during the first save it failed it post create FltGetFileNameInformation function. The second save did not call post create callback. To see the behaviour I tried doing the same with procmon enabled. surprisingly I did not get any errors. when procmon is running I could successfully save the changes to the network file.
I am thinking if there are any other APIs or should we use any other flags to get the filename.
Any thoughts on this?

  1. What’s the file object for in this case? Use !fileobj in the debugger
  2. It’s generally a bad idea to fail file system operations due to your own infrastructure failure. For example, if you’re failing based on file path then you shouldn’t fail the operation in a case where you can’t get the file path. It’s way too easy to end up in situations like this where you break a normal case because of something you don’t understand/expect

Is this a regular, simple network path, or cross device, with drive
letters, symlinks…?

Regular simple network path. The issue is seen when we map the Network share as a Drive. iF we are access the files via share path like \system1\test\file1.txt amd do save as it works fine. Also issue is not seen in lower OS like win 8.
@“Scott_Noone_(OSR)” we need file name for few house keeping operation. we use the above API to get that information.

Ok, then it is the FGFNI bug I thought of. Just affects Windows 10 (if you
can check pre-1703 builds and find it works, it is that bug).
Issue? IoCreateFile is used and it does not resolve network paths in s few
cases and returns an error, which FGFNI propagates back to you.

Only solution is to roll your own here.

U mean roll my FltGetFileNameInformation ?
Also another observation is that when this error comes from FltGetFileNameInformation I don’t get pre set call though I have registered callbacks for IRP_MJ_SET_INFORMATION in my mini filter.
Also I dont block this post create. Though the FltGetFileNameInformation() returns STATUS_INVALID_DEVICE_REQUEST error post create callback returns with FLT_POSTOP_FINISHED_PROCESSING.
so I assume that my callback for IRP_MJ_SET_INFORMATION should be called. It doesnt seem so when I print the logs.
Any scenario that kernel would not send IRP_MJ_SET_INFORMATION to mini filter though we have registered?

  1. Yes
  2. No
    Are you setting Data.Iostatus.Starus? Returning
    FLT_POSTOP_FINISHED_PROCESSING does not mean it was not blocled :slight_smile:

But anyway, check if this happens pre W10 and you can be sure it’s the
IoCreateFile bug I mentioned causing FGFNI to fail (essentially FGFNI bug
also).

Dejan.

we tested in win8 as well… we see the same issue.
https://www.osr.com/blog/2019/08/13/unexpected-fltgetfilenameinformation-behavior-for-network-renames-oh-and-tunnel-caching-too/
Is the above one applicable to postcreate calls as well?

I had debugged the code further. Figured out the issue is not with FltGetFileNameInformation. Issue is somewhere else.
Let me explain. In my minifilter driver which is basically part of security product whenever a file event happens I put it into pending state. Once I get the result from my business logic I either deny/allow the event.

during the write and a save as to network file I see an issue. I get STATUS_SHARING_VIOLATION in my postcreate callback.below is the call stack
I tried to see the status during the precreate function just before postcreate.I checked before I returned precreate. status was success. However when I check the callback data just after receiving the postcreate I see the status is changed to STATUS_SHARING_VIOLATION . Not sure who changed this status. I am not changing/setting the status in my driver. Any pointers?
44 21:02:32.726 notepad.exe IRP_MJ_CREATE 00000884 0000000000000000 \Device\Mup\QXX\C$\temp\sir9.txt STATUS_OBJECT_NAME_NOT_FOUND FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 00000080
45 21:02:32.726 notepad.exe IRP_MJ_CREATE 00000884 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS FILE_OPEN CreOpts: 00000020 Access: 00100081 Share: 00000007 Attrib: 0 Result: FILE_OPENED
46 21:02:32.726 notepad.exe IRP_MJ_QUERY_INFORMATION 00060870 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS 00000037
47 21:02:32.726 notepad.exe IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY 00060800 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_NO_SUCH_FILE FileIdBothDirectoryInformation FileMask: sir9.txt
48 21:02:32.726 notepad.exe IRP_MJ_CLEANUP 00000404 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS
49 21:02:32.726 notepad.exe IRP_MJ_CLOSE 00000404 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS
50 21:02:32.726 notepad.exe IRP_MJ_CREATE 00000884 0000000000000000 \Device\Mup\QXX\C$\temp\sir9.txt STATUS_OBJECT_NAME_NOT_FOUND FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 00000080
51 21:02:32.726 notepad.exe IRP_MJ_CREATE 00000884 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS FILE_OPEN CreOpts: 00000020 Access: 00100081 Share: 00000007 Attrib: 0 Result: FILE_OPENED
52 21:02:32.726 notepad.exe IRP_MJ_QUERY_INFORMATION 00060870 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS 00000037
53 21:02:32.726 notepad.exe IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY 00060800 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_NO_SUCH_FILE FileIdBothDirectoryInformation FileMask: sir9.txt
54 21:02:32.726 notepad.exe IRP_MJ_CLEANUP 00000404 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS
55 21:02:32.726 notepad.exe IRP_MJ_CLOSE 00000404 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS
56 21:02:32.726 notepad.exe IRP_MJ_CREATE 00000884 0000000000000000 \Device\Mup\QXX\C$\temp\sir9.txt STATUS_OBJECT_NAME_NOT_FOUND FILE_OPEN CreOpts: 00000020 Access: 00100080 Share: 00000007 Attrib: 00000080
57 21:02:32.726 15 notepad.exe IRP_MJ_CREATE 00000884 FFFFA986ADD42AA0 \Device\Mup\QXX\C$\temp\sir9.txt STATUS_SUCCESS FILE_CREATE CreOpts: 00000060 Access: 00120196 Share: 00000003 Attrib: 00000080 Result: FILE_CREATED
58 21:02:32.741 notepad.exe IRP_MJ_CLEANUP 00000404 FFFFA986ADD42AA0 \Device\Mup\QXX\C$\temp\sir9.txt STATUS_SUCCESS
59 21:02:32.741 notepad.exe IRP_MJ_CREATE 00000884 0000000000000000 \Device\Mup\QXX\C$\temp\sir9.txt STATUS_SHARING_VIOLATION FILE_OPEN CreOpts: 00200040 Access: 00010080 Share: 00000007 Attrib: 0
60 21:02:33.747 2 notepad.exe IRP_MJ_CREATE 00000884 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS FILE_OPEN CreOpts: 00000020 Access: 00100081 Share: 00000007 Attrib: 0 Result: FILE_OPENED
61 21:02:33.749 notepad.exe IRP_MJ_QUERY_INFORMATION 00060870 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS 00000037
62 21:02:33.749 1 notepad.exe IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY 00060800 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS FileIdBothDirectoryInformation FileMask: sir9.txt
63 21:02:33.751 notepad.exe IRP_MJ_CLEANUP 00000404 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS
64 21:02:33.752 1 notepad.exe IRP_MJ_CLOSE 00000404 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS
65 21:02:33.759 6 notepad.exe IRP_MJ_CREATE 00000884 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS FILE_OPEN CreOpts: 00000020 Access: 00100081 Share: 00000007 Attrib: 0 Result: FILE_OPENED
66 21:02:33.765 notepad.exe IRP_MJ_QUERY_INFORMATION 00060870 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS 00000037
67 21:02:33.765 notepad.exe IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY 00060800 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS FileIdBothDirectoryInformation FileMask:
68 21:02:33.766 notepad.exe IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY 00060800 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_NO_MORE_FILES FileIdBothDirectoryInformation FileMask:
69 21:02:33.766 notepad.exe IRP_MJ_CLEANUP 00000404 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS
70 21:02:33.766 notepad.exe IRP_MJ_CLOSE 00000404 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS
71 21:02:33.795 notepad.exe IRP_MJ_CREATE 00000884 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS FILE_OPEN CreOpts: 00000020 Access: 00100081 Share: 00000007 Attrib: 0 Result: FILE_OPENED
72 21:02:33.795 notepad.exe IRP_MJ_QUERY_INFORMATION 00060870 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS 00000037
73 21:02:33.795 notepad.exe IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY 00060800 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS FileIdBothDirectoryInformation FileMask: sir9.txt
74 21:02:33.795 notepad.exe IRP_MJ_CLEANUP 00000404 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS
75 21:02:33.795 notepad.exe IRP_MJ_CLOSE 00000404 FFFFA986B1FE6570 \Device\Mup\QXX\C$\temp STATUS_SUCCESS

Status in PreCreate? Of what?

I tried to print the status which is part of our callback structure before returning precreate with status FLT_PREOP_SUCCESS_WITH_CALLBACK. The status inside the callback structure was status_success… However when I receive the next postcreate and check the status in the callback structure, it says STATUS_SHARING_VIOLATION . somebody is setting it to "STATUS_SHARING_VIOLATION ". couldnt identify who sets it…I tried using windbg, filespy. no luck. if I use procmon this issue doesn’t happen only which is wierd. with procmon the status in the callback structure is always success.

Why… do you even check the Status field in PreCreate?

No…Just for debugging I checked…I wanted to check whether this status got changed during the precreate. I dont do anything precreate, just return saying FLT_PREOP_SUCCESS_WITH_CALLBACK.
My driver is very much similar to AVScan in WDK sample.

Like AVScan driver in my postcreate after few initial checks I call FlsendMessage to send the file event to usermode which does scan/decide whether I should allow or deny the operation. After calling Fltsendmessage I call kewaitformultipleobects where I wait for the verdict. Once I receive the verdict from usermode in anotehr notification thread I set the event.
depending upon the verdict I either set status to deny/virusinfected or success. However I return from postcreate with FLT_POSTOP_FINISHED_PROCESSING.

Now I see the issue only when I call kewiatformultiple object in the above sequence…To nail down I commented the whole code where I do Kewaitformultplieobject and gave a sleep(1). basically I didn’t wait for the verdict, I hardcoded to allow the create call. even then I see STATUS_SHARING_VIOLATION issue.

so my understanding is the when I call kewaitformultipleobects thread might get suspended and hence I see the issue of STATUS_SHARING_VIOLATION. However I tried calling keentercriticalregion/fsrtlenterfilesystem before calling kewiatformultipleobject.

No luck for far…