Windows 10 RS4-FltGetFileNameInformation() API failed for network path

In my minifilter, I am querying file name by specifying (FLT_FILE_NAME_NORMALIZED|FLT_FILE_NAME_QUERY_DEFAULT) flags to API FltGetFileNameInformation() in Post-Create callback.
FltGetFileNameInformation() API failed with status “STATUS_FLT_INVALID_NAME_REQUEST” on network path over SMB protocol 1.0.
This issue was observed only on Windows 10 RS4 (April Update) build. Any changes in RS4?

I did 2 tryouts:

  1. Passed “FLT_FILE_NAME_OPENED|FLT_FILE_NAME_QUERY_DEFAULT” flags instead of “FLT_FILE_NAME_NORMALIZED|FLT_FILE_NAME_QUERY_DEFAULT”
  • FltGetFileNameInformation() API gets success.
  1. Passed “FLT_FILE_NAME_NORMALIZED|FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP” flags instead of “FLT_FILE_NAME_NORMALIZED|FLT_FILE_NAME_QUERY_DEFAULT”
  • FltGetFileNameInformation() API gets failed sometimes(normally only on first access).

Does anyone has encountered this issue?

Did you manage to get anywhere with this? It would be pretty bad.

First thing I would do would be to get Process Monitor running under my
filter and try to see what’s failing.

-scott
OSR
@OSRDrivers

Thanks Scott for your inputs.

>Did you manage to get anywhere with this? It would be pretty bad.
Not yet.

>First thing I would do would be to get Process Monitor running under my
filter and try to see what’s failing.
I have collected and analyzed process monitor logs by placing it below my filter, but I didn’t see any failure cases.

For fun and as a learning exercise, does this work in PreCreate?

You might need to step through FltGetFileNameInformation and see where the error value is coming from. Not fun, but might be necessary.

Also, just because I have to ask: are you 100% positive the trace happened with ProcMon beneath you? ProcMon like to self heal its altitude, so if you change it in the registry (e.g. to put ProcMon lower) the change is undone. You can change this either by moving your altitude up or removing write access from the ProcMon service key. Just want to rule out that there’s no error being thrown from someone beneath you that’s causing the failure.

-scott
OSR
@OSRDrivers

>For fun and as a learning exercise, does this work in PreCreate?
Not working with pre-create as well.

You might need to step through FltGetFileNameInformation and see where the error
value is coming from. Not fun, but might be necessary.
I am trying to step through FltGetFileNameInformation, but no luck so far.

Also, just because I have to ask: are you 100% positive the trace happened with
ProcMon beneath you?
Yes Scott, I know it’s bit tricky but I managed to attached it below my filter and confirmed by fltmc output.

Just want to rule out that there’s no error being thrown from
someone beneath you that’s causing the failure.
As the same issue is present in pre-create and there is only process monitor above my filter, from this can we conclude that issue is not due to other filter.

On 05/24/2018 08:57 AM, xxxxx@gmail.com wrote:

> You might need to step through FltGetFileNameInformation and see where the error
> value is coming from. Not fun, but might be necessary.
I am trying to step through FltGetFileNameInformation, but no luck so far.

Does this occur with SMB2 servers or only SMB1 servers? There is a bug
when using this API against SMB1 servers in RS4, but I don’t know
if/when it will be fixed. Note SMB1 is effectively deprecated and AFAIK
no longer enabled with new installs.

  • M


http://www.malsmith.net

>>Does this occur with SMB2 servers or only SMB1 servers? There is a bug

when using this API against SMB1 servers in RS4

Thanks, Malcolm for the update.
Yes, this issue occurs with only SMB1 servers.

Malcolm,

Thanks for this.

Is there any official information posted about the nature of the bug? Or
Windows versions impacted? I understand that there’s lots of reasons for
people to NOT use SMB1, but I’m trying to understand the impact on those
customers that are still in transition.

Thanks,

-scott
OSR
@OSRDrivers

Hi,

I have the same problem on WebDAV network path.
FltGetFileNameInformation(FLT_FILE_NAME_NORMALIZED) fails with STATUS_FLT_INVALID_NAME_REQUEST in PostCreate and other IRPs, like PreDirectoryControl, etc.
This is new since Win10 1803. On all previous Win10 versions (and Win7), it worked perfectly on WebDAV files or directories.

Is that new behavior intended (yet not documented) or is it a bug ?

  • Seb