There is a bug in the W2K version of the DFS file system filter. When
processing mount requests it is calling KeEnterCriticalRegion before
passing the request to the next driver below it on the stack. This does
not normally cause problems except when accessing a floppy drive.
The FAT file system always queues and APC and then pends the mount
operation when mounting floppies. The purpose of the APC is to
determine if there is media in the drive and send the “no media in
drive” pop-up to the console when appropriate.
If a file system filter is loaded below the DFS file system filter (say
sfilter), and that filter synchronizes back to its dispatch routine by
waiting for its completion routine to signal an event (which is what
sfilter did), then that thread will hang forever because the queued APC
will never be delivered because APC’s are disabled by the DFS filter’s
call to KeEnterCriticalRegion.
SFilter works around this hang by not synchronizing back to its dispatch
routine but instead doing its completion processing in a worker thread
when necessary.
The reason this bug was never noticed back when W2K was released is
because the sfilter and filespy samples at that time did its completion
processing in its mount completion routine. We changed the samples to
synchronize back to their dispatch routines for mount because their
completion routines were calling API’s which are not safe to call at DPC
level. We wanted our samples to follow all of the rules. When the
latest sfilter & filespy samples were ported back to run on W2K we
discovered this bug and came up with the workaround you see in the
latest sample.
By the way, this bug is fairly common. I have helped several 3rd party
vendors debug this exact same hang in their products at file system
filter PlugFests.
Note that the DFS file system filter is only present on Server version
of Windows 2000.
This bug has NOT been fixed by any of the Windows 2000 Service Packs and
there are no plans to fix it.
This bug does not exist in Windows XP and later.
You may have not seen this bug with your product because:
- Your product does not run on any of the server version of windows 2000
- Your product does not attach to the fastfat control device object.
- Your product loads after the dfs file system filter loads.
- This filter loads at boot time
- It is in the “filter” group but does not have a “tag” value
so it loads after all tagged filters in the “filter” group
I hope this clarifies why this change was made.
Neal Christiansen
Microsoft File System Filter Group
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: Nicholas Ryan [mailto:xxxxx@nryan.com]
Sent: Tuesday, January 14, 2003 10:39 AM
To: File Systems Developers
So do I, but now Microsoft is claiming otherwise. Apparently they’ve
come upon a corner case under Win2k that they’ve modified their samples
to handle. Before I can justify making the same change, I would like to
know what that corner case is.
(Neal?)
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
Sent: Monday, January 13, 2003 7:59 PM
To: File Systems Developers
Subject: [ntfsd] RE: Mount processing in W2K vs WXP
Sure you can, we have several filter drivers that sync mount
back to dispatch.
jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nicholas Ryan
Sent: Monday, January 13, 2003 5:07 PM
To: File Systems Developers
Subject: [ntfsd] RE: Mount processing in W2K vs WXP
You’re right, it’s new in the SP1 IFS kit. If it’s true that
one cannot synchronize back to the dispatch routine under
Win2k, it’s news to me. Could somebody from the filter team
enlighten us as to the gory details so we can explain to our
bosses why we should fix this in a patch :)?
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of James Hanko
> Sent: Monday, January 13, 2003 4:13 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: Mount processing in W2K vs WXP
>
>
> Perhaps I should have been more specific. The comment is in
> the “XP Service Pack 1 DDK” IFS Kit, version 2600.1106. It
> appears in several places, including
> SfFsControlMountVolume(). The “sfilter.c” file’s modification
> date in the kit is August 28, 2002.
>
> I was surprised to see the comment, that’s why I asked if
> anyone knew to what issue it was referring.
>
> - Jim Hanko
>
> > Huh? I don’t see this comment anywhere in the XP IFS samples. Both
> > sfilter and filespy in the XP IFS kit use the standard
> > ‘calldown-and-delay’ to post-process mount requests in the
> context of
> > the original dispatch routine (mount requests are
> guaranteed to be at
> > passive level). Do this and you will be fine.
> >
> > - Nicholas Ryan
> >
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of
James Hanko
> > > Sent: Monday, January 13, 2003 2:57 PM
> > > To: File Systems Developers
> > > Subject: [ntfsd] Mount processing in W2K vs WXP
> > >
> > >
> > > In the sfilter and filespy examples in the XP IFS Kit,
there is a
> > > comment in the handling of IRP_MN_MOUNT_VOLUME that:
> > >
> > > “On Windows 2000, we cannot simply synchronize back to the
> > > dispatch routine to do our post-mount processing. We
need to do
> > > this work at passive level, so we will queue that work
to a worker
> > > thread from the completion routine.”
> > >
> > > Does anyone know why it is the case that you cannot just have a
> > > completion routine that signals an event (leaving the IRP with
> > > “STATUS_MORE_PROCESSING_REQUIRED”) and finishing the mount
> > > processing in the dispatch routine in W2K, like you can in WXP?
> > >
> > > - Jim Hanko
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@nryan.com To
> > > unsubscribe send a blank email to
xxxxx@lists.osr.com
> > >
>
> —
> You are currently subscribed to ntfsd as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
You are currently subscribed to ntfsd as:
xxxxx@storagecraft.com To unsubscribe send a blank email to
xxxxx@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com