Hi!
I have a serious question. I have written a filter driver that is filtering the LanManRedirector device. When I checked the driver under Windows XP, everything worked good. Now I am checking the driver under Windows Vista and I get blue screens.
Then I opened FileSpy of OSR, and payed attention that I have FastIO packets and not only IRP’s. So, I thought that the problem is that my driver catches only IRP’s and pass them on, and it does not catch FastIO. Actually, I have two questions:
-
Can it be as I say?
-
I tried to learn how to work with FastIO, but without success. The point is that there is very little information about it. Can anyone help me with FastIO? I would be very thankful!
> So, I thought that the problem is that my driver catches only
IRP’s and pass them on, and it does not catch FastIO. Actually, I have two questions:
- Can it be as I say?
Although lack of support for FastIO in a filter may have a negative impact on performance (because if it does not support FastIO, IO Manager is going to forward all requests to FSD via Dispatch interface, i.e. in the form of IRPs), I just don’t see any reason why it may result in BSOD
- I tried to learn how to work with FastIO, but without success. The point is
that there is very little information about it. Can anyone help me with FastIO?
It depends on what you are up to, but I believe the best idea here is just to pass requests down to FSD without doing anything, unless you mean callbacks (i.e. AcquireForSectionSynchronization and friends). Check filter WDK samples, and looking at FastFat sample would not hurt you either - at this point you will be able to understand what FastIO routines actually do…
Anton Bassov
wrote in message news:xxxxx@ntfsd…
>> So, I thought that the problem is that my driver catches only
>> IRP’s and pass them on, and it does not catch FastIO. Actually, I have
>> two questions:
>
>> 1. Can it be as I say?
>
> Although lack of support for FastIO in a filter may have a negative impact
> on performance (because if it does not support FastIO, IO Manager is going
> to forward all requests to FSD via Dispatch interface, i.e. in the form of
> IRPs), I just don’t see any reason why it may result in BSOD
>
Sorry, but there is cases where it will, for instance if the operations are
for the paging file it demands some FastIo IIRC. Also, there if the filter
does not handle the FastIoCheckIfPossible and for filters attached to
volumes FastIoDetachDevice there will be problems.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
So, do I really have to handle FastIO if I filter LanManRedirector?
Don,
Sorry, but there is cases where it will, for instance if the operations are
for the paging file it demands some FastIo IIRC.
Hold on - objectively, FastIO makes sense only for cached files, because it is all about avoiding disk access whenever it is possible. The very idea behind paging file operations is writing data to the disk and bringing it back. Although it can happen that page fault handler handles page fault without disk access (it happens when a page is marked as absent in PTE, but physically is still in RAM, i.e. is in a transition state), in this case execution is not going to reach FSD - instead, it will be handled internally by the Memory Manager. Therefore, paging file operations and FastIO seem to be just mutually exclusive things (at least to me), but there is a good chance that I just misunderstand something. Could you please explain your point in more detail.
Also, there if the filter does not handle the FastIoCheckIfPossible
Actually, I have always thought that if filter does not handle the FastIoCheckIfPossible, IO Manager is just going to send an IRP to FSD, and that’s it. Am I wrong?
Anton Bassov
Are you using perhaps a *checked* Vista version?
Inaki.
-----Mensaje original-----
De: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] En nombre de xxxxx@gmail.com
Enviado el: viernes, 28 de septiembre de 2007 18:53
Para: Windows File Systems Devs Interest List
Asunto: [ntfsd] Working with FastIO
Hi!
I have a serious question. I have written a filter driver that is filtering the LanManRedirector device. When I checked the driver under Windows XP, everything worked good. Now I am checking the driver under Windows Vista and I get blue screens.
Then I opened FileSpy of OSR, and payed attention that I have FastIO packets and not only IRP’s. So, I thought that the problem is that my driver catches only IRP’s and pass them on, and it does not catch FastIO. Actually, I have two questions:
-
Can it be as I say?
-
I tried to learn how to work with FastIO, but without success. The point is that there is very little information about it. Can anyone help me with FastIO? I would be very thankful!
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
You are currently subscribed to ntfsd as: xxxxx@pandasecurity.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You mean a “Checked” version of the WDK Compiler? If that’s what you mean, yes - I do use it.
What’s wrong with that?
Not sure why it is crashing if not using fastIO. IO Manager will not use
fastio if filter don;t expose it. Update !analyze output that may help to
nail down the issue.
Sisimon
Bangalore
On 9/28/07, xxxxx@gmail.com wrote:
>
> Hi!
>
> I have a serious question. I have written a filter driver that is
> filtering the LanManRedirector device. When I checked the driver under
> Windows XP, everything worked good. Now I am checking the driver under
> Windows Vista and I get blue screens.
>
> Then I opened FileSpy of OSR, and payed attention that I have FastIO
> packets and not only IRP’s. So, I thought that the problem is that my driver
> catches only IRP’s and pass them on, and it does not catch FastIO. Actually,
> I have two questions:
>
> 1. Can it be as I say?
>
> 2. I tried to learn how to work with FastIO, but without success. The
> point is that there is very little information about it. Can anyone help me
> with FastIO? I would be very thankful!
>
> —
> 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
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
GCS d+ s: a- c++++ U> B+ L++>$ w++++$ W++(+++) PGP+N+ t PS+PE++ tv+(++) b+++
G+++ e++>(++++) h-- r
Don’t know this? See http://www.geekcode.com/geek.html
Check if possible is done from the FsRtl routines if the FCB indicates that fast I/O is questionable. In fact, most of the file systems don’t use the FsRtl (read or write) routines and thus this entry point is seldom used.
The I/O Manager makes the determination - for read and write - if the PrivateCacheMap is non-NULL and the relevant fast I/O function is supported.
However, this is a published, exported entry point interface. I have seen cases where OTHER OS components call this entry point and just assume that it exists. SRV builds a table of these entry points when it opens a particular file (which leads to some rather strange behavior, because the IRPs will go through the full I/O path, but the fast I/O operations will go to the fast I/O function at the top of the stack at the time the file was opened.) Third party drivers might also call this entry point.
As someone else noted, the only way to provide greater insight would be for the OP to provide specific detail - a stack backtrace would be helpful (as long as it is done with the right kernel symbols.) The output from !analyze -v will provide that information as well (again, assuming the kernel symbols are set up properly.)
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Tony,
I have seen cases where OTHER OS components call this entry point and just assume
that it exists.
This is just unbelievable - normally you would expect such behaviour from some crappy third-party driver, rather from the OS-provided component. I hope you can agree that the blame for the crash
lies 100% with a component that dereferences a pointer without checking whether it is NULL
(and, once the support for FastIO is optional, in this contex it is perfectly reasonable to expect a pointer to be NULL) , rather that with a driver that does not provide support for FastIO. If it is, indeed, a system-provided component that unconditionally calls FastIO routines responsible for the BSOD here… well, then this thread can be renamed into something like “One more bug in Vista has been discovered”…
Anton Bassov
There is another rule that applies. If your filesystem filter driver is
installed and the system crashes, it is your driver’s fault. The
documentation may indicate you don’t have to support fastio, but the
following quote leads to some confusion: “File system filter drivers are not
required to support I/O on control device objects. However, filter device
objects that are attached to file systems or volumes are required to pass
all unrecognized or unwanted IRPs to the next-lower driver on the driver
stack. In addition, filter device objects that are attached to volumes must
implement FastIoDetachDevice.” The information about how the minifilter
manager handles fastio when some filter indicates it does not handle fastio
is interesting. It is fully detailed as to how drivers below and above your
driver are managed. I think Fastio support should be mandatory and
considering not supporting it because you are lazy is really stupid. Fat
doesn’t seem to need fastio the way ntfs requires it. I also think this is
another reason why the file system filter group has said that some future MS
OS will require all file system filters be written as minifilters. The only
permitted legacy file system filter driver will be the filter manager
itself.
wrote in message news:xxxxx@ntfsd…
> Tony,
>
>> I have seen cases where OTHER OS components call this entry point and
>> just assume
>> that it exists.
>
> This is just unbelievable - normally you would expect such behaviour from
> some crappy third-party driver, rather from the OS-provided component. I
> hope you can agree that the blame for the crash
> lies 100% with a component that dereferences a pointer without checking
> whether it is NULL
> (and, once the support for FastIO is optional, in this contex it is
> perfectly reasonable to expect a pointer to be NULL) , rather that with a
> driver that does not provide support for FastIO. If it is, indeed, a
> system-provided component that unconditionally calls FastIO routines
> responsible for the BSOD here… well, then this thread can be renamed
> into something like “One more bug in Vista has been discovered”…
>
>
> Anton Bassov
>
> There is another rule that applies. If your filesystem filter driver is
installed and the system crashes, it is your driver’s fault.
Actually, this is what Mr.Kaspersky said in response to complaints that his AV crashes even *properly-written* drivers. Sorry, but this logic is faulty. Don’t get me wrong - I am not saying that providing no support for FastIO in your filter is right thing to do (as you have properly pointed out, it is just stupid). What I am saying is that dereferencing a pointer that can be NULL (and if it is NULL, there is no violation of the documented rules whatsoever) is even more stupid than failing to provide support for FastIO…
I also think this is another reason why the file system filter group has said that some future MS
OS will require all file system filters be written as minifilters. The only permitted legacy
file system filter driver will be the filter manager itself.
If they want to do that, they have to do quite a lot of work on their minifilter model, in the first place - for the time being it is not an adequate replacement of legacy filters…
Anton Bassov
The minifilter model may be Microsoft’s definition of ‘adequate’. It is
their OS and they can write the rules as they want. They do listen,
especially to those who attend PlugFest, but some of the limitations of the
current minifilter model may be overcome but some may not.
In the theme that Windows is Microsoft’s OS, the fact that some part of the
OS requires fastio support and doesn’t check for filters that don’t provide
support is up to them. You and I may agree it is a bad design, but I think
that not being able to drop down to the full NT driver model from other
miniports such as network hardware miniports is a bad limitation. I
understand why they have the rules and want to keep things within a cage,
though some of the reasons have expired with the demise of Windows 9x. I
have to live with those rules, but sometimes want more. Luckily I have not
found a good reason to jump outside the box except for testing.
wrote in message news:xxxxx@ntfsd…
>> There is another rule that applies. If your filesystem filter driver is
>> installed and the system crashes, it is your driver’s fault.
>
> Actually, this is what Mr.Kaspersky said in response to complaints that
> his AV crashes even properly-written drivers. Sorry, but this logic is
> faulty. Don’t get me wrong - I am not saying that providing no support for
> FastIO in your filter is right thing to do (as you have properly pointed
> out, it is just stupid). What I am saying is that dereferencing a pointer
> that can be NULL (and if it is NULL, there is no violation of the
> documented rules whatsoever) is even more stupid than failing to provide
> support for FastIO…
>
>> I also think this is another reason why the file system filter group has
>> said that some future MS
>> OS will require all file system filters be written as minifilters. The
>> only permitted legacy
>> file system filter driver will be the filter manager itself.
>
> If they want to do that, they have to do quite a lot of work on their
> minifilter model, in the first place - for the time being it is not an
> adequate replacement of legacy filters…
>
>
> Anton Bassov
>
> I think that not being able to drop down to the full NT driver model from other
miniports such as network hardware miniports is a bad limitation. I
understand why they have the rules and want to keep things within a cage,
though some of the reasons have expired with the demise of Windows 9x. I
have to live with those rules, but sometimes want more.
Well, if, for this or that reason, you believe WDM is more appropriate for your NIC, compared to NDIS miniport model, you can always write a WDM driver X that deals with your NIC , plus NDIS virtual miniport driver Y that deals with driver X on its lower adge and with NDIS on its upper one.
Therefore, you can replace the word “limitation” with “inconvenience” - certainly, some extra work has to be done (which is inconvenient), but still you can achieve exactly what you want, and do it
without hackery of any description…
Anton Bassov
Not quite since the rules are even more restrictive in some circumstances.
Do you know of any inbox driver that does this?
wrote in message news:xxxxx@ntfsd…
>> I think that not being able to drop down to the full NT driver model from
>> other
>> miniports such as network hardware miniports is a bad limitation. I
>> understand why they have the rules and want to keep things within a cage,
>> though some of the reasons have expired with the demise of Windows 9x. I
>> have to live with those rules, but sometimes want more.
>
> Well, if, for this or that reason, you believe WDM is more appropriate for
> your NIC, compared to NDIS miniport model, you can always write a WDM
> driver X that deals with your NIC , plus NDIS virtual miniport driver Y
> that deals with driver X on its lower adge and with NDIS on its upper one.
> Therefore, you can replace the word “limitation” with “inconvenience” -
> certainly, some extra work has to be done (which is inconvenient), but
> still you can achieve exactly what you want, and do it
> without hackery of any description…
>
> Anton Bassov
>
> Not quite since the rules are even more restrictive in some circumstances.
To be honest, I don’t fuly understand you - first you say that sometimes you want to write NIC driver as WDM one, because NDIS model imposes some limitations, and then you say that WDM may be even more restrictive than NDIS. How am I supposed to understand you???
Do you know of any inbox driver that does this?
To be honest, I don’t know if someone ever did it in practice, but PCIDRV sample demonstarates how Intel 82557/82558 based PCI Ethernet Adapter can be written as either WDM or KMDF driver
(WDK even provides 2 separate samples), and NDISWDM (or ndisedge, if you prefer KMDF) sample demonstarates how PCIDRV can be interfaced to NDIS…
Anton Bassov
If so, I understand that FastIO support is essential… The main problem is that I can’t find information about it. Where can I learn from how to implement FastIO support in my filter driver?
You are going to have to read the samples in the WDK and the OSR article
http://www.osronline.com/article.cfm?id=166. Searching the WDK
documentation for the Fast I/O entry routines in many cases points you to
the underlying support routines.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntfsd…
> If so, I understand that FastIO support is essential… The main problem
> is that I can’t find information about it. Where can I learn from how to
> implement FastIO support in my filter driver?
>
Ok, I will do it. Thank you very much!