> So what should I do? The user is able to copy files to the USB
drive using explorer, which means that it is mounted properly. Does
that mean there is some bug in the Filter Manager?
Try this: Download filespy (http://www.zezula.net/fstools.html)
and setup using minispy as kernel driver. Then try to attach
the volume by volume letter. If it fails, try to use the
“Volumes\attach to device by name” and enter the native NT
name there (it usually is in format of “\device\DP-0-1-(1)”
or something like this.
If the first does not work and the second does, there’s
a possible bug in filter manager.
I tried all these before posting this thread including the “Volumes{GUID}” symbolic link to the device. It does not work. We built a new machine using XP installer CD, this works, which means that over the period of time there is some patch that got downloaded or some software that is conflicting with FltMgr Operation.
I also found a registry key under FltMgr called “attachwhenloaded”, I thought may be this key affects the attachment to drives, but this key only affects how FltMgr attaches to exisiting volumes i.e. either at boot time or when any filter driver is loaded. e.g. if this key is set to 0 then executing fltmgr volumes will display “No Volumes Found” message. But once you load a filter driver using the load command and then rerun the fltmc volumes command it will display all volumes.
I wonder what do you gain by this functionality? How does it matter when Fltmgr attaches to exisiting volumes.
Why would you want it to attach before it is needed. It is more code that
has to run and they way it hooks around legacy filters means it impact can
be significant.
–
David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation
wrote in message news:xxxxx@ntfsd… >I tried all these before posting this thread including the “Volumes{GUID}” >symbolic link to the device. It does not work. We built a new machine using >XP installer CD, this works, which means that over the period of time there >is some patch that got downloaded or some software that is conflicting with >FltMgr Operation. > I also found a registry key under FltMgr called “attachwhenloaded”, I > thought may be this key affects the attachment to drives, but this key > only affects how FltMgr attaches to exisiting volumes i.e. either at boot > time or when any filter driver is loaded. e.g. if this key is set to 0 > then executing fltmgr volumes will display “No Volumes Found” message. But > once you load a filter driver using the load command and then rerun the > fltmc volumes command it will display all volumes. > > I wonder what do you gain by this functionality? How does it matter when > Fltmgr attaches to exisiting volumes. > > Thanks. >
I found that the antivirus software is causing the problem, If I turn off the TDI driver installed by the antivirus, the minifilter driver is able to attach to the USB drives. TDI drivers usually monitor socket calls, why would it fiddle with the filter manager’s activity?
Perhaps the same driver handles FS filtering, as well?
A fairly well used AV product used to cut off other filters by calling IoAttachxxx incorrectly several years ago, it could be the cause here, as well.
I found that the antivirus software is causing the problem, If I turn off the TDI driver installed by the antivirus, the minifilter driver is able to attach to the USB drives. TDI drivers usually monitor socket calls, why would it fiddle with the filter manager’s activity?
Any thoughts on this?
–
Kind regards, Dejan http://www.alfasp.com
File system audit, security and encryption kits.
Thanks for the hint. I found that the TDI driver actually loads a file system driver which is actually causing the problem. Here are a few more questions:
I did some debugging using the checked build version of OS to see how and why the AV driver is cutting off other filters from attaching. I want to do this so that I can provide the AV vendor with some specific information on the problem. So far I do not have any luck except for the fact that I noticed that in a normal attachment scenario FltpCommonDeviceIoControl() call is followed by FltpAttachVolume call. which does not happen when the AV driver is present.
I tried using FileSpy and it is able to attach to the USB drives, where as my filter driver and the scanner sample driver are not able to. The difference between FileSpy and other drivers is that FileSpy is listed as a Activity Monitor driver whereas my filter driver and the scanner driver are content screener.
FileSpy uses the same loadOrderGroup as the AV driver, however, I do not know the altitude for the filespy, it is not listed in the alloc-alt.xls. Does anybody know what altitude is used by FileSpy so that I can determine whether it is attached above or below the AV driver?
The FileSpy and FileSpyUser application do not use the FltAttach() and FilterAttach() functions. Instead the FileSpyUser app sends a DeviceIoControl with a user defined CTLCODE which eventually leads to FileSpy calling IoAttachXXX function. Is there a difference between the two method?
Here’s the thing: if an FSFD loads AFTER the faulty AV driver, then it will not be cut off (the case with File Spy, FileMon or many non-boot start FSFDs).
A mini-filter on the other hand loads in the FltMgr FS filter stack frame - a mini-filter does not attach to the FSD in the legacy way but rather registers to the FltMgr callbacks.
Since FltMgr by default loads at Boot time, and the AV loads after it, the AV filter cuts FltMgr off.
This is a pretty simple thing, and you should simply notify the AV maker that their AV filter is cutting off other filters by incorrectly attaching (calling IoAttachxxx with incorrect driver object parameters). In essence it attaches right above the FSD, instead of attaching at the top of the FSD stack.
Is the AV filter the latest release?
Thanks for the hint. I found that the TDI driver actually loads a file system driver which is actually causing the problem. Here are a few more questions:
I did some debugging using the checked build version of OS to see how and why the AV driver is cutting off other filters from attaching. I want to do this so that I can provide the AV vendor with some specific information on the problem. So far I do not have any luck except for the fact that I noticed that in a normal attachment scenario FltpCommonDeviceIoControl() call is followed by FltpAttachVolume call. which does not happen when the AV driver is present.
I tried using FileSpy and it is able to attach to the USB drives, where as my filter driver and the scanner sample driver are not able to. The difference between FileSpy and other drivers is that FileSpy is listed as a Activity Monitor driver whereas my filter driver and the scanner driver are content screener.
FileSpy uses the same loadOrderGroup as the AV driver, however, I do not know the altitude for the filespy, it is not listed in the alloc-alt.xls. Does anybody know what altitude is used by FileSpy so that I can determine whether it is attached above or below the AV driver?
The FileSpy and FileSpyUser application do not use the FltAttach() and FilterAttach() functions. Instead the FileSpyUser app sends a DeviceIoControl with a user defined CTLCODE which eventually leads to FileSpy calling IoAttachXXX function. Is there a difference between the two method?
Thanks. Any help is much appreciated.
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit: http://www.osr.com/seminars
Strange how an AV would make such a naive mistake this late in the game.
Let us know if they fix it fast, otherwise, we should give them collective pressure to do so
The “fltmc instances” command displays this information for filters that are loaded.
Ken
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Thursday, September 13, 2007 5:47 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Re[2]: Minifilter fails to attach to USB drives
How can I find out the altitude of fileSpy and if it is using one how is it specified as it is not there in the INF file?
Thanks.
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit: http://www.osr.com/seminars
It doesn’t display that for fileSpy, infact filespy entry does not even show up and this is true even for the problematic AV driver, which has an allocated altitude and is mentioned in the Alloc-Alt.xls. It seems any filter driver that is not implemented using IFS or that does not register with fltmgr is not displayed using fltmc command. I may be wrong in this observation but on my machine I see only those driver that uses IFS.
On a separate note, we found out from the AV vendor that they have fixed the problem, however, they haven’t made an official release.
