"Dispatch Routines and IRQLs" - documentation understanding

Hi,

I’m writing a File System Filter Driver. It is based upon sfilter from
the IFSkit. I have some open issues and questions and maybe some of them
are because of my English is not so great (So Please forgive me)
If any of you know of a certain bug in the sfilter, please reply.
Thanks!
Yesterday I read this in the msdn Library: (mainly take a look at the
last paragraph! - I can’t be sure if we can say that a file system
filter is an intermediate driver, and if so why I see this in sfilter
sample code
#pragma alloc_text(PAGE, SfFastIoRead) )

"Dispatch Routines and IRQLs
Most drivers’ dispatch routines are called in an arbitrary thread
context at IRQL = PASSIVE_LEVEL, with the following exceptions:

Any highest-level driver’s dispatch routines are called in the context
of the thread that originated the I/O request, which is commonly a
user-mode application thread.
In other words, the dispatch routines of file system drivers and other
highest-level drivers are called in a nonarbitrary thread context at
IRQL = PASSIVE_LEVEL.

The DispatchRead, DispatchWrite, and DispatchDeviceControl routines of
lowest-level device drivers, and of intermediate drivers layered above
them in the system paging path, can be called at IRQL = APC_LEVEL and in
an arbitrary thread context.
The DispatchRead and/or DispatchWrite routines, and any other routine
that also processes read and/or write requests in such a lowest-level
device or intermediate driver, must be resident at all times. These
driver routines can neither be pageable nor be part of a driver’s
pageable-image section; they must not access any pageable memory.
Furthermore, they should not be dependent on any blocking calls (such as
KeWaitForSingleObject with a nonzero time-out).
"

#pragma alloc_text(PAGE, SfFastIoRead)

Thanks, and have a great week!
Daniel

Get the latest news on SurfControl and our products,
subscribe to our monthly e-newsletter, SurfAdvisory at:
http://www.surfcontrol.com/resources/surfadvisory/surfadvisory_signup.aspx

*********************************************************************
The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. If you believe that you have received this email in error,
please contact the sender.
*********************************************************************

SfFastIoRead is fastIO, it’s a call to the cache man, it is not IRP based
like what this text is talking about.

m.

Daniel Arosh wrote:

Hi,

I’m writing a File System Filter Driver. It is based upon sfilter from
the IFSkit. I have some open issues and questions and maybe some of them
are because of my English is not so great (So Please forgive me)
If any of you know of a certain bug in the sfilter, please reply.
Thanks!
Yesterday I read this in the msdn Library: (mainly take a look at the
last paragraph! - I can’t be sure if we can say that a file system
filter is an intermediate driver, and if so why I see this in sfilter
sample code
#pragma alloc_text(PAGE, SfFastIoRead) )

"Dispatch Routines and IRQLs
Most drivers’ dispatch routines are called in an arbitrary thread
context at IRQL = PASSIVE_LEVEL, with the following exceptions:

Any highest-level driver’s dispatch routines are called in the context
of the thread that originated the I/O request, which is commonly a
user-mode application thread.
In other words, the dispatch routines of file system drivers and other
highest-level drivers are called in a nonarbitrary thread context at
IRQL = PASSIVE_LEVEL.

The DispatchRead, DispatchWrite, and DispatchDeviceControl routines of
lowest-level device drivers, and of intermediate drivers layered above
them in the system paging path, can be called at IRQL = APC_LEVEL and in
an arbitrary thread context.
The DispatchRead and/or DispatchWrite routines, and any other routine
that also processes read and/or write requests in such a lowest-level
device or intermediate driver, must be resident at all times. These
driver routines can neither be pageable nor be part of a driver’s
pageable-image section; they must not access any pageable memory.
Furthermore, they should not be dependent on any blocking calls (such as
KeWaitForSingleObject with a nonzero time-out).
"

#pragma alloc_text(PAGE, SfFastIoRead)

Thanks, and have a great week!
Daniel

Get the latest news on SurfControl and our products,
subscribe to our monthly e-newsletter, SurfAdvisory at:
http://www.surfcontrol.com/resources/surfadvisory/surfadvisory_signup.aspx

*********************************************************************
The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. If you believe that you have received this email in error,
please contact the sender.
*********************************************************************


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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Thanks a lot for your time !
(Sorry, just slipped my mind)
Does anyone know about Any known bug in the sfilter sample?
Thanks

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Monday, October 16, 2006 11:26 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] “Dispatch Routines and IRQLs” - documentation
understanding

SfFastIoRead is fastIO, it’s a call to the cache man, it is not IRP
based
like what this text is talking about.

m.

Daniel Arosh wrote:

Hi,

I’m writing a File System Filter Driver. It is based upon sfilter from
the IFSkit. I have some open issues and questions and maybe some of
them
are because of my English is not so great (So Please forgive me)
If any of you know of a certain bug in the sfilter, please reply.
Thanks!
Yesterday I read this in the msdn Library: (mainly take a look at the
last paragraph! - I can’t be sure if we can say that a file system
filter is an intermediate driver, and if so why I see this in sfilter
sample code
#pragma alloc_text(PAGE, SfFastIoRead) )

"Dispatch Routines and IRQLs
Most drivers’ dispatch routines are called in an arbitrary thread
context at IRQL = PASSIVE_LEVEL, with the following exceptions:

Any highest-level driver’s dispatch routines are called in the context
of the thread that originated the I/O request, which is commonly a
user-mode application thread.
In other words, the dispatch routines of file system drivers and other
highest-level drivers are called in a nonarbitrary thread context at
IRQL = PASSIVE_LEVEL.

The DispatchRead, DispatchWrite, and DispatchDeviceControl routines of
lowest-level device drivers, and of intermediate drivers layered above
them in the system paging path, can be called at IRQL = APC_LEVEL and
in
an arbitrary thread context.
The DispatchRead and/or DispatchWrite routines, and any other routine
that also processes read and/or write requests in such a lowest-level
device or intermediate driver, must be resident at all times. These
driver routines can neither be pageable nor be part of a driver’s
pageable-image section; they must not access any pageable memory.
Furthermore, they should not be dependent on any blocking calls (such
as
KeWaitForSingleObject with a nonzero time-out).
"

#pragma alloc_text(PAGE, SfFastIoRead)

Thanks, and have a great week!
Daniel

Get the latest news on SurfControl and our products,
subscribe to our monthly e-newsletter, SurfAdvisory at:
http://www.surfcontrol.com/resources/surfadvisory/surfadvisory_signup.a
spx

*********************************************************************
The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. If you believe that you have received this email in error,
please contact the sender.
*********************************************************************


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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

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

Get the latest news on SurfControl and our products,
subscribe to our monthly e-newsletter, SurfAdvisory at:
http://www.surfcontrol.com/resources/surfadvisory/surfadvisory_signup.aspx

*********************************************************************
The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. If you believe that you have received this email in error,
please contact the sender.
*********************************************************************

You haven’t said what version of the IFS kit, also one has to ask why you
are not doing a mini-filter instead of a legacy filter?


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

“Daniel Arosh” wrote in message
news:xxxxx@ntfsd…
Thanks a lot for your time !
(Sorry, just slipped my mind)
Does anyone know about Any known bug in the sfilter sample?
Thanks

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Monday, October 16, 2006 11:26 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] “Dispatch Routines and IRQLs” - documentation
understanding

SfFastIoRead is fastIO, it’s a call to the cache man, it is not IRP
based
like what this text is talking about.

m.

Daniel Arosh wrote:

>Hi,
>
>I’m writing a File System Filter Driver. It is based upon sfilter from
>the IFSkit. I have some open issues and questions and maybe some of
them
>are because of my English is not so great (So Please forgive me)
>If any of you know of a certain bug in the sfilter, please reply.
>Thanks!
>Yesterday I read this in the msdn Library: (mainly take a look at the
>last paragraph! - I can’t be sure if we can say that a file system
>filter is an intermediate driver, and if so why I see this in sfilter
>sample code
>#pragma alloc_text(PAGE, SfFastIoRead) )
>
>“Dispatch Routines and IRQLs
>Most drivers’ dispatch routines are called in an arbitrary thread
>context at IRQL = PASSIVE_LEVEL, with the following exceptions:
>
>Any highest-level driver’s dispatch routines are called in the context
>of the thread that originated the I/O request, which is commonly a
>user-mode application thread.
>In other words, the dispatch routines of file system drivers and other
>highest-level drivers are called in a nonarbitrary thread context at
>IRQL = PASSIVE_LEVEL.
>
>The DispatchRead, DispatchWrite, and DispatchDeviceControl routines of
>lowest-level device drivers, and of intermediate drivers layered above
>them in the system paging path, can be called at IRQL = APC_LEVEL and
in
>an arbitrary thread context.
>The DispatchRead and/or DispatchWrite routines, and any other routine
>that also processes read and/or write requests in such a lowest-level
>device or intermediate driver, must be resident at all times. These
>driver routines can neither be pageable nor be part of a driver’s
>pageable-image section; they must not access any pageable memory.
>Furthermore, they should not be dependent on any blocking calls (such
as
>KeWaitForSingleObject with a nonzero time-out).
>”
>
>#pragma alloc_text(PAGE, SfFastIoRead)
>
>Thanks, and have a great week!
>Daniel
>
>Get the latest news on SurfControl and our products,
>subscribe to our monthly e-newsletter, SurfAdvisory at:
>http://www.surfcontrol.com/resources/surfadvisory/surfadvisory_signup.a
spx
>
>
>The information in this email is confidential and may be legally
>privileged. It is intended solely for the addressee. Access to this
>email by anyone else is unauthorized. If you are not the intended
>recipient, any disclosure, copying, distribution or any action taken
>or omitted to be taken in reliance on it, is prohibited and may be
>unlawful. If you believe that you have received this email in error,
>please contact the sender.
>

>
>
>—
>Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>


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

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

Get the latest news on SurfControl and our products,
subscribe to our monthly e-newsletter, SurfAdvisory at:
http://www.surfcontrol.com/resources/surfadvisory/surfadvisory_signup.aspx


The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. If you believe that you have received this email in error,
please contact the sender.

depends on the version, search the archive… there are some known older
ones, but I don’t know of
any in the current version.

m.

Daniel Arosh wrote:

Thanks a lot for your time !
(Sorry, just slipped my mind)
Does anyone know about Any known bug in the sfilter sample?
Thanks

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Monday, October 16, 2006 11:26 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] “Dispatch Routines and IRQLs” - documentation
understanding

SfFastIoRead is fastIO, it’s a call to the cache man, it is not IRP
based
like what this text is talking about.

m.

Daniel Arosh wrote:

>Hi,
>
>I’m writing a File System Filter Driver. It is based upon sfilter from
>the IFSkit. I have some open issues and questions and maybe some of
>
>
them

>are because of my English is not so great (So Please forgive me)
>If any of you know of a certain bug in the sfilter, please reply.
>Thanks!
>Yesterday I read this in the msdn Library: (mainly take a look at the
>last paragraph! - I can’t be sure if we can say that a file system
>filter is an intermediate driver, and if so why I see this in sfilter
>sample code
>#pragma alloc_text(PAGE, SfFastIoRead) )
>
>"Dispatch Routines and IRQLs
>Most drivers’ dispatch routines are called in an arbitrary thread
>context at IRQL = PASSIVE_LEVEL, with the following exceptions:
>
>Any highest-level driver’s dispatch routines are called in the context
>of the thread that originated the I/O request, which is commonly a
>user-mode application thread.
>In other words, the dispatch routines of file system drivers and other
>highest-level drivers are called in a nonarbitrary thread context at
>IRQL = PASSIVE_LEVEL.
>
>The DispatchRead, DispatchWrite, and DispatchDeviceControl routines of
>lowest-level device drivers, and of intermediate drivers layered above
>them in the system paging path, can be called at IRQL = APC_LEVEL and
>
>
in

>an arbitrary thread context.
>The DispatchRead and/or DispatchWrite routines, and any other routine
>that also processes read and/or write requests in such a lowest-level
>device or intermediate driver, must be resident at all times. These
>driver routines can neither be pageable nor be part of a driver’s
>pageable-image section; they must not access any pageable memory.
>Furthermore, they should not be dependent on any blocking calls (such
>
>
as

>KeWaitForSingleObject with a nonzero time-out).
>"
>
>#pragma alloc_text(PAGE, SfFastIoRead)
>
>Thanks, and have a great week!
>Daniel
>
>Get the latest news on SurfControl and our products,
>subscribe to our monthly e-newsletter, SurfAdvisory at:
>http://www.surfcontrol.com/resources/surfadvisory/surfadvisory_signup.a
>
>
spx

>*********************************************************************
>The information in this email is confidential and may be legally
>privileged. It is intended solely for the addressee. Access to this
>email by anyone else is unauthorized. If you are not the intended
>recipient, any disclosure, copying, distribution or any action taken
>or omitted to be taken in reliance on it, is prohibited and may be
>unlawful. If you believe that you have received this email in error,
>please contact the sender.
>*********************************************************************
>
>
>—
>Questions? First check the IFS FAQ at
>
>
https://www.osronline.com/article.cfm?id=17

>You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
>
>
‘’

>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>


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

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

Get the latest news on SurfControl and our products,
subscribe to our monthly e-newsletter, SurfAdvisory at:
http://www.surfcontrol.com/resources/surfadvisory/surfadvisory_signup.aspx

*********************************************************************
The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. If you believe that you have received this email in error,
please contact the sender.
*********************************************************************


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

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

I don’t really know how to tell the version number,
That what is written in the install.htm

Microsoft Windows Server 2003 SP1
IFS Development Kit

and in the release note :

C:\WINDDK\3790.1830\relnote.htm

Windows Server 2003 Service Pack 1 (SP1)
Driver Development Kit (DDK)

I am not sure why they chose the legacy filter instead of mini filter.(
it wasn’t at my age. And I don’t have the time to revise it I just need
to finish this up in a month time. :frowning: ) (any bets on my head already)
(I can tell you the main functionality that were required, maybe they
can give you an hint…(if there is one):
Updateable functionality, interceptable (while the usermode holds the
logic of whom to intercept), performance.
There are actually two drivers. One is a “fixed” FSFD, based on the
SFilter ifskit example. And the other is dynamic (removable/updateable)
functional driver that holds an interception functionality
(communicating with each other by ioctl(Registration) & a sink of
Readers-writer mechanism) and with the user mode with IOCTL and IrpQueue
(IoCsq…).
)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, October 16, 2006 4:37 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] “Dispatch Routines and IRQLs” - documentation
understanding

You haven’t said what version of the IFS kit, also one has to ask why
you
are not doing a mini-filter instead of a legacy filter?


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

“Daniel Arosh” wrote in message
news:xxxxx@ntfsd…
Thanks a lot for your time !
(Sorry, just slipped my mind)
Does anyone know about Any known bug in the sfilter sample?
Thanks

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Monday, October 16, 2006 11:26 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] “Dispatch Routines and IRQLs” - documentation
understanding

SfFastIoRead is fastIO, it’s a call to the cache man, it is not IRP
based
like what this text is talking about.

m.

Daniel Arosh wrote:

>Hi,
>
>I’m writing a File System Filter Driver. It is based upon sfilter from
>the IFSkit. I have some open issues and questions and maybe some of
them
>are because of my English is not so great (So Please forgive me)
>If any of you know of a certain bug in the sfilter, please reply.
>Thanks!
>Yesterday I read this in the msdn Library: (mainly take a look at the
>last paragraph! - I can’t be sure if we can say that a file system
>filter is an intermediate driver, and if so why I see this in sfilter
>sample code
>#pragma alloc_text(PAGE, SfFastIoRead) )
>
>“Dispatch Routines and IRQLs
>Most drivers’ dispatch routines are called in an arbitrary thread
>context at IRQL = PASSIVE_LEVEL, with the following exceptions:
>
>Any highest-level driver’s dispatch routines are called in the context
>of the thread that originated the I/O request, which is commonly a
>user-mode application thread.
>In other words, the dispatch routines of file system drivers and other
>highest-level drivers are called in a nonarbitrary thread context at
>IRQL = PASSIVE_LEVEL.
>
>The DispatchRead, DispatchWrite, and DispatchDeviceControl routines of
>lowest-level device drivers, and of intermediate drivers layered above
>them in the system paging path, can be called at IRQL = APC_LEVEL and
in
>an arbitrary thread context.
>The DispatchRead and/or DispatchWrite routines, and any other routine
>that also processes read and/or write requests in such a lowest-level
>device or intermediate driver, must be resident at all times. These
>driver routines can neither be pageable nor be part of a driver’s
>pageable-image section; they must not access any pageable memory.
>Furthermore, they should not be dependent on any blocking calls (such
as
>KeWaitForSingleObject with a nonzero time-out).
>”
>
>#pragma alloc_text(PAGE, SfFastIoRead)
>
>Thanks, and have a great week!
>Daniel
>
>Get the latest news on SurfControl and our products,
>subscribe to our monthly e-newsletter, SurfAdvisory at:
>http://www.surfcontrol.com/resources/surfadvisory/surfadvisory_signup.a
spx
>
>
>The information in this email is confidential and may be legally
>privileged. It is intended solely for the addressee. Access to this
>email by anyone else is unauthorized. If you are not the intended
>recipient, any disclosure, copying, distribution or any action taken
>or omitted to be taken in reliance on it, is prohibited and may be
>unlawful. If you believe that you have received this email in error,
>please contact the sender.
>

>
>
>—
>Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>


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

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

Get the latest news on SurfControl and our products,
subscribe to our monthly e-newsletter, SurfAdvisory at:
http://www.surfcontrol.com/resources/surfadvisory/surfadvisory_signup.as
px


The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. If you believe that you have received this email in error,
please contact the sender.



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

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

Get the latest news on SurfControl and our products,
subscribe to our monthly e-newsletter, SurfAdvisory at:
http://www.surfcontrol.com/resources/surfadvisory/surfadvisory_signup.aspx


The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. If you believe that you have received this email in error,
please contact the sender.