Hello,
I ran into a situation (fairly reproducible) where FGFNI takes way too much time to return for a local file name query. I even got this reproduced when OPENED file name format is queried.
Strangely, only on Srv2016 for now. The load on the system is not low, but there is ample RAM to handle more than twice the system need.
Could some contention be so high? Oplock? Unfortunately, while reproducible, it is not in the same spot, file name etc… so I can’t enter WinDBG at the right time and poke around anything 
Any idea what to look for?
Regards, Dejan.
SWAGS:
Might wireshark help? Or even procmon on the server?
WireShark for a local disk? I didn’t know they added something in that arena. ProcMon… can only confirm long times, but even when I placed it at altitude 20.000 I do not see anything more. It doesn’t show high wait times then, but likely because it is the one calling FGFNI before ours gets completed. BTW, the Server is a local machine, no network drives. It isn’t a server, just a standalone test VM. Dejan.
I didn’t know they added something in that arena.
I beg your pardon, I saw “Server” and read “SRV”.
This is a stumper I had always assumed that when you asked for “Opened” it would just haul it out from the Context (so no additional file system activity at all).
but likely because it is the one calling FGFNI before ours gets completed.
Ugh sounds feasible. It has been too long but do you happen to remember if FileSpy calls FGFNI? I would guess not and certainly if you used fspy rather than mspy.
FSpy allows choosing Opened file name… might be an option if I can reduce the altidude.
Hmm, FSpy/MSpy don’t havr Duration column working from what I can tell
I can sort of reproduce the issue by creating a lot of files, when a minifilter asks for normalized file names in pre-create (due to write access, normalized path is needed in PreCreate).