Cool question - a FILE_OPEN request does not need an exclusive lock, IMO.
Bur FILE_OPEN_IF or any other do, though FltMgr should not be asking that
type of Disposition.
Do you have MEX extensions for Windbg? If not, get them from MS’s site, and
run !mex.t on the threads and post it please.
Long shot, but I wonder exactly what time they spent waiting.
@Dejan_Maksimovic said:
Cool question - a FILE_OPEN request does not need an exclusive lock, IMO.
Bur FILE_OPEN_IF or any other do, though FltMgr should not be asking that
type of Disposition.
Do you have MEX extensions for Windbg? If not, get them from MS’s site, and
run !mex.t on the threads and post it please.
Long shot, but I wonder exactly what time they spent waiting.
Here you go, so indeed this is really related to these chrome cache files. Note that from these three files, we are the one who have created the index.txt.tmp.backup using FltCreateFile (with share read/write/delete) + FltWriteFile. But the other two files are not created by us. Considering that the driver for index.txt.tmp is FltMgr, maybe the minifilter for Kaspersky is the one that has created that file?
Also as a reminder, in the following call stack which is in the pre close of the index.txt.tmp.backup, we are using FltCreateFile to get the file object corresponding to the file (so we are using FILE_OPEN, with share read/write/delete), so we can get more info related to that file.