I seem to be having a lot of problems with FltGetFileNameInformation when I call it for file objects that contain certain types of DFS paths. The results are very inconsistent and vary from folder to folder, machine to machine, and environment to environment.
The “\Server\Share\Domain.com\share\path” file path seems to be particularly troublesome for this function. I get this sort of a path when the DC and file server are the same machine and the root target is the parent folder path.
I am calling this from near the beginning of PreOpDC like this:
status = FltGetFileNameInformation(Data,
FLT_FILE_NAME_NORMALIZED |
FLT_FILE_NAME_QUERY_DEFAULT,
&pNameInfo);
Environment A:
Works fine for all paths.
Environment B:
Different machines and different domain from Environment A. Works fine for one path and for another path I get 0xC00000BE. These are two folders with the same parent folder and the user the thread is impersonating has full control on these paths. If I go to another machine, I don’t get any errors, but my mini-filter doesn’t even seem to see the directory queries at all.
Environment C:
In a customer’s environment we see access denied returned from FltGetFileNameInformation here.
Can someone please offer me some guidance here on how to troubleshoot these problems and why this is so inconsistent and unreliable?
I forgot to mention that these are all W2K3 servers and/or XP workstations.
* driverdev wrote, On 09/11/09 17:18:
I seem to be having a lot of problems with FltGetFileNameInformation when I call it for file objects that contain certain types of DFS paths. The results are very inconsistent and vary from folder to folder, machine to machine, and environment to environment.
The “\Server\Share\Domain.com\share\path” file path seems to be particularly troublesome for this function. I get this sort of a path when the DC and file server are the same machine and the root target is the parent folder path.
I am calling this from near the beginning of PreOpDC like this:
Do you mean Pre-op on IRP_MJ_DIRECTORY_CONTROL, IRP_MJ_DEVICE_CONTROL or
even IRP_MJ_QUERY_INFORMATION or have I missed something ?
status = FltGetFileNameInformation(Data,
FLT_FILE_NAME_NORMALIZED |
FLT_FILE_NAME_QUERY_DEFAULT,
&pNameInfo);
…
Different machines and different domain from Environment A. Works fine for one path and for another path I get 0xC00000BE. These are two folders with the same parent folder and the user the thread is impersonating has full control on these paths. If I go to another machine, I don’t get any errors, but my mini-filter doesn’t even seem to see the directory queries at all.
…
Can someone please offer me some guidance here on how to troubleshoot these problems and why this is so inconsistent and unreliable?
Wireshark somewhere on the link can also be a very helpful indicator as
to how lower layers have interpreted your filters actions and as to
where the error is occurring - maybe due to failure of network calls.
Sam
> Do you mean Pre-op on IRP_MJ_DIRECTORY_CONTROL, IRP_MJ_DEVICE_CONTROL or
even IRP_MJ_QUERY_INFORMATION or have I missed something ?
PreOpDC == Pre Operation Directory Control. More specifically, I am filtering directory queries.
I will try Wireshark. Thanks for that suggestion.
Yesterday I changed the second parameter to FltGetFileNameInformation to FLT_FILE_NAME_OPENED | FLT_FILE_NAME_QUERY_DEFAULT and that seems to make that call succeed now.
I also observed that FltGetFileNameInformation was also failing in Pre-Create with the same errors I was seeing in PreOpDC. The parameter change above solves that as well.
However, another observation from yesterday is that FltCreateFile also fails with 0xC00000BE. I use this occassionaly to see if a file exists.
Data->Iopb->TargetFileObject->FileName contains \Server\share\domain.com\share\path\filename.
FltGetFileNameInformation returns \Device\Lanmanredirector\domain.com\share\path\filename.
FltCreateFile fails with both of those paths even though I can open \domain.com\share\path\filename in notepad.
>FltCreateFile fails with both of those paths even though I can open
\domain.com\share\path\filename in notepad.
I suspect that notepad calls WNetUseConnection()/WnetAddConnection() before it opens the file. I would create UM console application to test if just CreateFile() works.
Bronislav Gabrhelik
* driverdev wrote, On 10/11/09 14:43:
> Do you mean Pre-op on IRP_MJ_DIRECTORY_CONTROL, IRP_MJ_DEVICE_CONTROL or
> even IRP_MJ_QUERY_INFORMATION or have I missed something ?
PreOpDC == Pre Operation Directory Control. More specifically, I am filtering directory queries.
I will try Wireshark. Thanks for that suggestion.
Yesterday I changed the second parameter to FltGetFileNameInformation to FLT_FILE_NAME_OPENED | FLT_FILE_NAME_QUERY_DEFAULT and that seems to make that call succeed now.
I also observed that FltGetFileNameInformation was also failing in Pre-Create with the same errors I was seeing in PreOpDC. The parameter change above solves that as well.
However, another observation from yesterday is that FltCreateFile also fails with 0xC00000BE. I use this occassionaly to see if a file exists.
Data->Iopb->TargetFileObject->FileName contains \Server\share\domain.com\share\path\filename.
FltGetFileNameInformation returns \Device\Lanmanredirector\domain.com\share\path\filename.
FltCreateFile fails with both of those paths even though I can open \domain.com\share\path\filename in notepad.
0xC00000BE seems to be STATUS_BAD_NETWORK_PATH
The two filenames you give above do not directly correspond to
each-other it seems to me.
Data->Iopb->TargetFileObject->FileName seems to have been re-written
according to the DFS rules and FltGetFileNameInformation has not
(because of FLT_FILE_NAME_OPENED no doubt).
Can you give a specific path that has actually failed with 0xC00000BE
(instead of a general path pattern) and also tell us what wireshark saw
for that failure. It may be that it is actually a bad path, and one that
you did not anticipate.
Sam
These are the paths (as real as I can make them).
This is in the file object:
\DC01\profiles\domain.com\profiles\username\ntuser.dat
This is what FltGetFileNameInformation returns:
\Device\LanmanRedirector\domain.com\profiles\username\ntuser.dat
The second path is what I am passing to FltCreateFile and it is failing with 0xC00000BE. That is a perfectly valid path. I can open \domain.com\profiles\username\ntuser.dat using any tool I choose except my mini-filter. I specifically opened it yesterday with File Test Utility from the OSR download page using \domain.com\profiles\username\ntuser.dat as the path and it works fine.
Also, I am trying to work out a scenario where I can test this with Wireshark enabled. Not an easy task. When Wireshark is running it spits out so much stuff to the debug port that my machine basically grinds to a halt when the kernel debugger is attached. Further, this is an XP machine, so it’s hard to capture this b/c it happens during a logon. So, I am trying to find a way to test it that doesn’t require a logon. I am trying a newer version of Wireshark to see if the debug messages are better.
>When Wireshark is running it spits out so much stuff to the debug port that
my machine basically grinds to a halt when the kernel >debugger is
attached.
I just had this same issue. According to Gianluca it’s fixed if you install
WinPcap 4.1.1, though I haven’t had a chance to try that.
As a workaround, set a breakpoint on DbgPrint and step out so that you’re
inside npf.sys. If you look right above the call to DbgPrint there’s a test
of a global variable, if you set it to 0 then the DbgPrints will stop.
-scott
ps->We fight with DFS all of the time. What makes it worse is that most
issues our customers have are configuration specific, so we waste a lot of
time just trying to get the right config to repro with.
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@ntfsd…
> Also, I am trying to work out a scenario where I can test this with
> Wireshark enabled. Not an easy task. When Wireshark is running it spits
> out so much stuff to the debug port that my machine basically grinds to a
> halt when the kernel debugger is attached. Further, this is an XP
> machine, so it’s hard to capture this b/c it happens during a logon. So,
> I am trying to find a way to test it that doesn’t require a logon. I am
> trying a newer version of Wireshark to see if the debug messages are
> better.
>
Thanks Scott. The 1.2.3 version of Wireshark installs the 4.1.1 version of Winpcap. It’s better in the sense that my mouse moves, but it’s not fixed. It’s still very slow and spits out way too much useless info to the debugger window (looks like one line per packet). Also, don’t break into the debugger or all of the DbgPrints will queue up on you and you’ll have to wait for queue to drain before you can use your machine again after resuming.
What makes it worse is that most
issues our customers have are configuration specific
DFS has so little configuration it seems like it shouldn’t be so hard to use it.
We found a duplicate host record in our DNS configuration and removed it. FltCreateFile is now returning 0xC00000CC/STATUS_BAD_NETWORK_NAME instead. I am not seeing much interesting data from Wireshark now. I don’t see any apparent failures (i.e. not NTSTATUS codes in the SMB header beside STATUS_SUCCESS). I see a directory query (FindFirstFile/FindNextFile) that returns a list of all of the files in my folder, including the file I am trying to open.
I am still digging, but hoping this data might help trigger a memory in someone.
> Thanks Scott. The 1.2.3 version of Wireshark installs the
4.1.1 version of Winpcap. It’s better in the sense that my
mouse moves, but it’s not fixed. It’s still very slow and
spits out way too much useless info to the debugger window
(looks like one line per packet). Also, don’t break into the
debugger or all of the DbgPrints will queue up on you and
you’ll have to wait for queue to drain before you can use
your machine again after resuming.
Can you put a host filter for some unrelated host on your capture, start
WireShark, ping it from the unrelated host, and break it there to set
the global to disable the DbgPrint? Then you can set up your filters to
whatever you actually want and resume working as normal.
Or is the DbgPrint happening regardless of whether or not the packets
make it through a filter? If so, that sucks. Is there any way to turn
off the service you’re trying to diagnose while you tweak WireShark with
the debugger, thus keeping the packets down?
Hope that helps some.
Eric
Scott’s suggestion to zero the global helps tremendously. It cuts down the DbgPrint volume significantly. It will still log a ton of stuff when you first start the capture and when you stop it, which will hang your machine for bit, but once it logs out everything it stops logging then.
Well, I appreciate everyone’s help. Wireshark was the key to resolving this issue. Over years of changes to your DNS configuration we had multiple IPs pointing to our root, which caused various machines at various times to pick the wrong IP and a machine that didn’t have the folder on it, which caused the STATUS_BAD_NETWORK_PATH errors.