Anomalous behavior with filtering and an auto-mount

I am encountering some anomalous behavior with a mini-filter I am
developing for a shared SAN storage system. The filter has characteristics
of both a filter and a redirector, as a redirector it sends some calls to a
server including creates. The filter comes into play to maintain a state
machine of creates to handle sharing questions.

The behavior that is causing the problem is that if bring up the system,
then mount the SAN volume everything works as expected and the client
creates pass through the server mini-filter. If I let the system see the
volume and auto-mount it as Windows is coming up, the calls from the client
work fine but are never seen by the mini-filters create callback routines,
and my state machine fails.

I believed that a mini-filter would see all the create calls, unless they
were explicitly passed to a device object below it on the stack. Can
anyone explain the strange anomaly to me?


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com

Don,

I’m reluctant to suggest the obvious, especially to you, but here goes: Are
you sure that your attach function is returning sucess and that you really
do get attached? I’ve been bitten by that toooo often (as well as forgetting
to set the magic value in the registry to enable auto-attach).

/Rod

Rod,

Thanks for the reply. I went back and checked to be sure and I am
seeing local creates through my mini-filter but not the ZwCreateFile calls
I issue in the mini-filter on behalf of the client! Note: I am useing the
ZwXXX calls specifically because I wanted the recursion through the filter,
and the system is acting like the call is being done with a FltMgr call
that is bypassing the filter.

Note: suggesting the obvious is never a bad idea because it may not be
obvious. In this case I am no guru, I have done three redirectors
commercially for Windows, but the only file system filter was my own
experiment, and this is the first time with a mini-filter what so ever.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Rod Widdowson” wrote in message
news:xxxxx@ntfsd…
> Don,
>
> I’m reluctant to suggest the obvious, especially to you, but here goes:
> Are you sure that your attach function is returning sucess and that you
> really do get attached? I’ve been bitten by that toooo often (as well as
> forgetting to set the magic value in the registry to enable auto-attach).
>
> /Rod
>
>

I am still looking for suggestions on this. I am to the point of thinking
seriously about ripping out the mini-filter code and making this thing a
legacy filter! There have been a number of surprises on this project that
make me think, that the filtmgr is “not ready for prime time”.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Don Burn” wrote in message news:xxxxx@ntfsd…
>I am encountering some anomalous behavior with a mini-filter I am
>developing for a shared SAN storage system. The filter has
>characteristics of both a filter and a redirector, as a redirector it
>sends some calls to a server including creates. The filter comes into
>play to maintain a state machine of creates to handle sharing questions.
>
> The behavior that is causing the problem is that if bring up the system,
> then mount the SAN volume everything works as expected and the client
> creates pass through the server mini-filter. If I let the system see the
> volume and auto-mount it as Windows is coming up, the calls from the
> client work fine but are never seen by the mini-filters create callback
> routines, and my state machine fails.
>
> I believed that a mini-filter would see all the create calls, unless they
> were explicitly passed to a device object below it on the stack. Can
> anyone explain the strange anomaly to me?
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
>
>