Re[2]: Re[2]: Anomalous behavior with filtering and an auto-mount

> I can reproduce this anytime I want, but there is a heck of a lot to trace

in assember, and unfortunately multi-threaded so tracing through fltmgr is
a PITA.

Ok, so you have a “correct call” (create arrives to your filter)
and “incorrect call” (create does not arrive to your filter).

If you write down the stack trace of a correct create call,
you get a few checkpoints. Set breakpoints to those checkpoints
and reproduce the incorrect call. You should be able
to find where the paths start to differ. It will
considerably limit the amount of dissassembling to do.

Although this is still far from being easy and fast,
it will limit the lot of assembly garbage you need to
deal with.

L.

I found out what the problem was here, and wanted to pass it along so the
next poor dev who got there would not be hit. Basically, tracing through
the filter manager code there are some files that if a thread accesses it
is assumed that it is part of the mount manger and all operations by that
thread are hidden until the cleanup occurs on the special file from the
thread. In particular the “special files” are:

:$MountMgrRemoteDatabase
\System Volume Information
$Extend$Reparse:$R:$INDEX_ALLOCATION
\System Volume Information\MountPointManagerRemoteDatabase


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
>
>

Don,

This code is in filter manager to work around the very nasty bug in the
mount manager where it issues file IO requests with a lock held. This
mount manager bug manifests itself to minifilters when they deadlock in
their instance setup routine trying to retrieve a volumes GUID name or a
dos device name.

What you are seeing is my attempt to work around this issue which
unfortunately was not entirely successful. You are the first person I
have seen who has been negatively impacted by this.

Let me describe what we are doing:

  • InstanceSetup is called on the first create after a volume mounts.
  • Unfortunately if this first create is from the mount manager it is
    called with a lock held and if we call instance setup and the minifilter
    does a mount manager operation you deadlock.
  • To work around this Filter manager looks for open requests to very
    specific files (those listed below - good sleuthing job) which
    originated from kernel mode, which were not from a remote file system
    (srv), were not originated by a minifilter, and occur before our
    instance setup notify processing is complete.
  • In that scenario we assume this is a mount manager request and do not
    pass the create operation to minifilters.

The problem with this solution is that it never resolved the hang
problem 100% of the time so it probably should have been pulled.

The good news for all of this is that the mount manager bug was fixed in
Vista so this code in filter manager was pulled for Vista. I know this
does not help you today but someday this problem will be gone.

I am curious why this negatively impacted your product?

I wish to address one comment of yours. Filter manager has proven
itself to be a very reliable component over the last several years and
it is very ready for prime time. All filter development inside of
Microsoft is minifilter based and there are over 20 minifilters in
various stages of development/release. With the cross-OS support we
have today anyone considering developing a new filter should definitely
develop it as a minifilter. Those who have legacy filters should
consider moving to a minifilter sometime in the next year or two. There
will come a time when Microsoft will no longer support legacy filters.

Neal Christiansen
Microsoft NTFS Development Lead
This posting is provided “AS IS” with no warranties, and confers no
Rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Thursday, February 01, 2007 8:19 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Anomalous behavior with filtering and an auto-mount

I found out what the problem was here, and wanted to pass it along so
the
next poor dev who got there would not be hit. Basically, tracing
through
the filter manager code there are some files that if a thread accesses
it
is assumed that it is part of the mount manger and all operations by
that
thread are hidden until the cleanup occurs on the special file from the
thread. In particular the “special files” are:

:$MountMgrRemoteDatabase
\System Volume Information
$Extend$Reparse:$R:$INDEX_ALLOCATION
\System Volume Information\MountPointManagerRemoteDatabase


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
>
>


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Neal,

As I stated in the initial post, the filter acts as both a filter and
a redirector for a SAN storage system. As part of being a redirector it
was sending the requests to another system, where the filter also runs.
Unfortunately, in the case of an auto mount, the mount manager requests
were getting passed to the other system, where a pool of threads serviced
them. This caused the situation where Thread A processed the Create of one
of the “special files” and then all other processing by thread A did not
pass through the filter. Since at least creates and closes needed to go
through the filter (they contain a state machine), things got very bad,
very fast.

What drove me nuts was the code worked without auto-mount, and there
was no clue as to what sent things into the mess. It took a lot of
stepping through assembler to find the problem.

I think the filter manager is a good product, but have unfortunately
found several surprises (due to the strange nature of my filter) in this
effort.


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

“Neal Christiansen” wrote in message
news:xxxxx@ntfsd…

I am curious why this negatively impacted your product?

I wish to address one comment of yours. Filter manager has proven
itself to be a very reliable component over the last several years and
it is very ready for prime time. All filter development inside of
Microsoft is minifilter based and there are over 20 minifilters in
various stages of development/release. With the cross-OS support we
have today anyone considering developing a new filter should definitely
develop it as a minifilter. Those who have legacy filters should
consider moving to a minifilter sometime in the next year or two. There
will come a time when Microsoft will no longer support legacy filters.

Neal Christiansen
Microsoft NTFS Development Lead
This posting is provided “AS IS” with no warranties, and confers no
Rights