Re[2]: PAGE code sections

NTFSD
1

> What about IRP_MJ_FILE_SYSTEM_CONTROL, particularly mount and load?

I don’t know, maybe it’s fine to place it in PAGE section.

Let me explain the problem:

If you touch a memory which is not there but paged out,
the system will (after a few preparations) call IoPageRead
to let the page be loaded into memory. IoPageRead is a short
function, it just constructs an IRP and call the FS driver/filter.

Now if your filter’s IRP_MJ_READ handler is in PAGE section and
is currently paged out, you will get another page fault.

This page fault will again (after some preparations) call IoPageRead,
which will (again) call your filter’s IRP_MJ_READ function,
which will still be paged out, and the process will repeat until you
blow your stack.

I have met this effect in Vista when was testing FileSpy.
Neil told me that Vista does more aggresive paging out on PAGE
sections than earlier OSes, so you have good chance
to meet this error.

And BTW, I’ve also encountered this “page-fault endless loop”
caused by fltmgr.sys itself, when I was testing FileSpy with minifilter
driver. Can anyone confirm or deny if the bug is still there ?
(Read: Did anyone who works on minifilter experienced this kind
of deadlock when testing minifilter under Vista and under heavy-stress
situations ?)

L.

2

I’m going to go out on a limb, and disagree with the esteemed Mr. Craig.
Maybe it’ll get him to light that cigar.

Whether a legacy FSFD or a mini-filter, MOST of the code can be pageable.
The exact proportions will naturally depend on the nature of the filter, but
heres an attempt at the basic guidelines the OP asked for:

All dispatch (pre-processing) routines may be paged, with the exception of
read and write. Read and write need to be non-paged to handle I/O to the
paging file (see FsRtlIsPagingFile()). If you are not interested in I/O to
the paging file, then your dispatch routine can be a stub that calls a paged
routine to do the real work.

All I/O completion routines (post-processing) must be non-paged. However,
in many cases (See IoIsOperationSynchronous), the completion routine can
simply synchronize back to the dispatch routine, which is paged.

If the completion cannot be synchronized to dispatch, it can often be posted
to a worker thread, which may be pageable. The complex rules regarding what
can and cannot be posted, and what you can and cannot do from posted
completion processing are beyond the scope of the OP’s question, so I’ll
refuse to address it.

All of this assumes that you are using synchronization mechanisms that are
reasonable and appropriate for file systems, e.g. ERESOURCEs, not spin
locks. It also assumes the driver is written in C, as God and Dave
intended.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
Sent: Monday, March 26, 2007 5:23 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] PAGE code sections

If the FSFD is a legacy driver, then probably only the DriverEntry() path is

good for paging. If you are using C++, then never use paged code or data.
The placement of functions called from C++ is very unpredictable and one
might get placed in paged memory where it might be referenced in the paging
path. If your driver was to only attach to volumes that cannot contain the
page file, then paging might work, but analyze carefully.

If it is a minifilter, I guess most of the same rules apply. Watch out for
function that can be called on a volume that can contain a page file. Also
watch out for use of C++. Create a .map file and see where each function
gets placed. All this can be done and will have to be done with each
build - automate with python, if you like.

“Neil Weicher” wrote in message news:xxxxx@ntfsd…
>I have seen discussions that using #pragma alloc_text(PAGE, …) can do
>more
> harm than good if not done right.
>
> Can someone in the know give some rules of thumb as when it might be
> helpful, if ever? Particularly in a FSFD.
>
> Thanks.
>
>

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

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

3

This is an interesting scenario, which does argue for the read path to be
non-paged for all paging I/O, not just pagefile I/O.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Tuesday, March 27, 2007 8:31 AM
To: Windows File Systems Devs Interest List
Subject: Re[2]: [ntfsd] PAGE code sections

What about IRP_MJ_FILE_SYSTEM_CONTROL, particularly mount and load?

I don’t know, maybe it’s fine to place it in PAGE section.

Let me explain the problem:

If you touch a memory which is not there but paged out,
the system will (after a few preparations) call IoPageRead
to let the page be loaded into memory. IoPageRead is a short function, it
just constructs an IRP and call the FS driver/filter.

Now if your filter’s IRP_MJ_READ handler is in PAGE section and is currently
paged out, you will get another page fault.

This page fault will again (after some preparations) call IoPageRead, which
will (again) call your filter’s IRP_MJ_READ function, which will still be
paged out, and the process will repeat until you blow your stack.

I have met this effect in Vista when was testing FileSpy.
Neil told me that Vista does more aggresive paging out on PAGE sections than
earlier OSes, so you have good chance to meet this error.

And BTW, I’ve also encountered this “page-fault endless loop” caused by
fltmgr.sys itself, when I was testing FileSpy with minifilter driver. Can
anyone confirm or deny if the bug is still there ?
(Read: Did anyone who works on minifilter experienced this kind of deadlock
when testing minifilter under Vista and under heavy-stress situations ?)

L.

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

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

4

Thanks. I would probably not page any routines that were called with any
frequency since either (a) they would never be paged out anyway or (b) they
would be doing a lot of thrashing. So that would rule out Read, Write,
Lock, Bake, Broil, etc.

But what about the (supposed) rule that the sum total of all your paged code
has to be at least one page (4096 bytes) or it will never be paged out
anyway? I’m talking legacy filter here.

----- Original Message -----
From: “Dan Kyler”
To: “Windows File Systems Devs Interest List”
Sent: Tuesday, March 27, 2007 10:48 AM
Subject: RE: [ntfsd] PAGE code sections

> I’m going to go out on a limb, and disagree with the esteemed Mr. Craig.
> Maybe it’ll get him to light that cigar.
>
> Whether a legacy FSFD or a mini-filter, MOST of the code can be pageable.
> The exact proportions will naturally depend on the nature of the filter,
> but
> heres an attempt at the basic guidelines the OP asked for:
>
> All dispatch (pre-processing) routines may be paged, with the exception of
> read and write. Read and write need to be non-paged to handle I/O to the
> paging file (see FsRtlIsPagingFile()). If you are not interested in I/O
> to
> the paging file, then your dispatch routine can be a stub that calls a
> paged
> routine to do the real work.
>
> All I/O completion routines (post-processing) must be non-paged. However,
> in many cases (See IoIsOperationSynchronous), the completion routine can
> simply synchronize back to the dispatch routine, which is paged.
>
> If the completion cannot be synchronized to dispatch, it can often be
> posted
> to a worker thread, which may be pageable. The complex rules regarding
> what
> can and cannot be posted, and what you can and cannot do from posted
> completion processing are beyond the scope of the OP’s question, so I’ll
> refuse to address it.
>
> All of this assumes that you are using synchronization mechanisms that are
> reasonable and appropriate for file systems, e.g. ERESOURCEs, not spin
> locks. It also assumes the driver is written in C, as God and Dave
> intended.
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
> Sent: Monday, March 26, 2007 5:23 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] PAGE code sections
>
>
> If the FSFD is a legacy driver, then probably only the DriverEntry() path
> is
>
> good for paging. If you are using C++, then never use paged code or data.
> The placement of functions called from C++ is very unpredictable and one
> might get placed in paged memory where it might be referenced in the
> paging
> path. If your driver was to only attach to volumes that cannot contain
> the
> page file, then paging might work, but analyze carefully.
>
> If it is a minifilter, I guess most of the same rules apply. Watch out
> for
> function that can be called on a volume that can contain a page file.
> Also
> watch out for use of C++. Create a .map file and see where each function
> gets placed. All this can be done and will have to be done with each
> build - automate with python, if you like.
>
> “Neil Weicher” wrote in message news:xxxxx@ntfsd…
>>I have seen discussions that using #pragma alloc_text(PAGE, …) can do
>>more
>> harm than good if not done right.
>>
>> Can someone in the know give some rules of thumb as when it might be
>> helpful, if ever? Particularly in a FSFD.
>>
>> Thanks.
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com
> 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@netlib.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

5

I don’t know whether that’s true or not, but who cares? If the system
decides that a driver with less than one page of pageable code isn’t worth
paging, what’s the harm?

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Neil Weicher
Sent: Tuesday, March 27, 2007 10:12 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] PAGE code sections

Thanks. I would probably not page any routines that were called with any
frequency since either (a) they would never be paged out anyway or (b) they
would be doing a lot of thrashing. So that would rule out Read, Write,
Lock, Bake, Broil, etc.

But what about the (supposed) rule that the sum total of all your paged code
has to be at least one page (4096 bytes) or it will never be paged out
anyway? I’m talking legacy filter here.

----- Original Message -----
From: “Dan Kyler”
To: “Windows File Systems Devs Interest List”
Sent: Tuesday, March 27, 2007 10:48 AM
Subject: RE: [ntfsd] PAGE code sections

> I’m going to go out on a limb, and disagree with the esteemed Mr.
> Craig. Maybe it’ll get him to light that cigar.
>
> Whether a legacy FSFD or a mini-filter, MOST of the code can be
> pageable. The exact proportions will naturally depend on the nature of
> the filter, but heres an attempt at the basic guidelines the OP asked
> for:
>
> All dispatch (pre-processing) routines may be paged, with the
> exception of read and write. Read and write need to be non-paged to
> handle I/O to the paging file (see FsRtlIsPagingFile()). If you are
> not interested in I/O to the paging file, then your dispatch routine
> can be a stub that calls a paged
> routine to do the real work.
>
> All I/O completion routines (post-processing) must be non-paged.
> However, in many cases (See IoIsOperationSynchronous), the completion
> routine can simply synchronize back to the dispatch routine, which is
> paged.
>
> If the completion cannot be synchronized to dispatch, it can often be
> posted to a worker thread, which may be pageable. The complex rules
> regarding what
> can and cannot be posted, and what you can and cannot do from posted
> completion processing are beyond the scope of the OP’s question, so I’ll
> refuse to address it.
>
> All of this assumes that you are using synchronization mechanisms that
> are reasonable and appropriate for file systems, e.g. ERESOURCEs, not
> spin locks. It also assumes the driver is written in C, as God and
> Dave intended.
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
> Sent: Monday, March 26, 2007 5:23 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] PAGE code sections
>
>
> If the FSFD is a legacy driver, then probably only the DriverEntry()
> path is
>
> good for paging. If you are using C++, then never use paged code or
> data. The placement of functions called from C++ is very unpredictable
> and one might get placed in paged memory where it might be referenced
> in the paging path. If your driver was to only attach to volumes that
> cannot contain the
> page file, then paging might work, but analyze carefully.
>
> If it is a minifilter, I guess most of the same rules apply. Watch
> out for function that can be called on a volume that can contain a
> page file. Also
> watch out for use of C++. Create a .map file and see where each function
> gets placed. All this can be done and will have to be done with each
> build - automate with python, if you like.
>
> “Neil Weicher” wrote in message news:xxxxx@ntfsd…
>>I have seen discussions that using #pragma alloc_text(PAGE, …) can
>>do more harm than good if not done right.
>>
>> Can someone in the know give some rules of thumb as when it might be
>> helpful, if ever? Particularly in a FSFD.
>>
>> Thanks.
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com 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@netlib.com
> 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@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

> This is an interesting scenario, which does argue for the read path to be

non-paged for all paging I/O, not just pagefile I/O.

Ladislav’s scenario gives an example of what happened if IO request to a
pagefile would generate pagefault on a read path.
All code and data for processing pagefile IO requests must be nonpaged, but
for memory mapped files the code and data can be completely paged out.

–
Slava Imameyev, xxxxx@hotmail.com

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> This is an interesting scenario, which does argue for the read path to be
> non-paged for all paging I/O, not just pagefile I/O.
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
> Sent: Tuesday, March 27, 2007 8:31 AM
> To: Windows File Systems Devs Interest List
> Subject: Re[2]: [ntfsd] PAGE code sections
>
>
>> What about IRP_MJ_FILE_SYSTEM_CONTROL, particularly mount and load?
>
> I don’t know, maybe it’s fine to place it in PAGE section.
>
> Let me explain the problem:
>
> If you touch a memory which is not there but paged out,
> the system will (after a few preparations) call IoPageRead
> to let the page be loaded into memory. IoPageRead is a short function, it
> just constructs an IRP and call the FS driver/filter.
>
> Now if your filter’s IRP_MJ_READ handler is in PAGE section and is
> currently
> paged out, you will get another page fault.
>
> This page fault will again (after some preparations) call IoPageRead,
> which
> will (again) call your filter’s IRP_MJ_READ function, which will still be
> paged out, and the process will repeat until you blow your stack.
>
> I have met this effect in Vista when was testing FileSpy.
> Neil told me that Vista does more aggresive paging out on PAGE sections
> than
> earlier OSes, so you have good chance to meet this error.
>
> And BTW, I’ve also encountered this “page-fault endless loop” caused by
> fltmgr.sys itself, when I was testing FileSpy with minifilter driver. Can
> anyone confirm or deny if the bug is still there ?
> (Read: Did anyone who works on minifilter experienced this kind of
> deadlock
> when testing minifilter under Vista and under heavy-stress situations ?)
>
> L.
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

7

Ah, good point. Driver code is paged to the paging file, not the driver
.sys file, so this is the pagefile case.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Slava Imameyev
Sent: Tuesday, March 27, 2007 11:21 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Re[2]: PAGE code sections

This is an interesting scenario, which does argue for the read path to
be non-paged for all paging I/O, not just pagefile I/O.

Ladislav’s scenario gives an example of what happened if IO request to a
pagefile would generate pagefault on a read path.
All code and data for processing pagefile IO requests must be nonpaged, but
for memory mapped files the code and data can be completely paged out.

–
Slava Imameyev, xxxxx@hotmail.com

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> This is an interesting scenario, which does argue for the read path to
> be non-paged for all paging I/O, not just pagefile I/O.
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav
> Zezula
> Sent: Tuesday, March 27, 2007 8:31 AM
> To: Windows File Systems Devs Interest List
> Subject: Re[2]: [ntfsd] PAGE code sections
>
>
>> What about IRP_MJ_FILE_SYSTEM_CONTROL, particularly mount and load?
>
> I don’t know, maybe it’s fine to place it in PAGE section.
>
> Let me explain the problem:
>
> If you touch a memory which is not there but paged out,
> the system will (after a few preparations) call IoPageRead
> to let the page be loaded into memory. IoPageRead is a short function,
> it just constructs an IRP and call the FS driver/filter.
>
> Now if your filter’s IRP_MJ_READ handler is in PAGE section and is
> currently
> paged out, you will get another page fault.
>
> This page fault will again (after some preparations) call IoPageRead,
> which
> will (again) call your filter’s IRP_MJ_READ function, which will still be
> paged out, and the process will repeat until you blow your stack.
>
> I have met this effect in Vista when was testing FileSpy. Neil told me
> that Vista does more aggresive paging out on PAGE sections than
> earlier OSes, so you have good chance to meet this error.
>
> And BTW, I’ve also encountered this “page-fault endless loop” caused
> by fltmgr.sys itself, when I was testing FileSpy with minifilter
> driver. Can anyone confirm or deny if the bug is still there ?
> (Read: Did anyone who works on minifilter experienced this kind of
> deadlock
> when testing minifilter under Vista and under heavy-stress situations ?)
>
> L.
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com 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@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

I quit lighting cigars a long time ago. I do think that without far too
much work for most environments that your rules apply to legacy filters
written in ‘C’ only. The rules for C++ are far more restrictive mostly
because the compilers were not written with kernel mode code in mind. The
automatic class functions such as constructors, destructors, copy, etc. that
are not explicitly defined in the class can be generated in the wrong
segment (paged/nonpaged) as Doron has mentioned.

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
> I’m going to go out on a limb, and disagree with the esteemed Mr. Craig.
> Maybe it’ll get him to light that cigar.
>
> Whether a legacy FSFD or a mini-filter, MOST of the code can be pageable.
> The exact proportions will naturally depend on the nature of the filter,
> but
> heres an attempt at the basic guidelines the OP asked for:
>
> All dispatch (pre-processing) routines may be paged, with the exception of
> read and write. Read and write need to be non-paged to handle I/O to the
> paging file (see FsRtlIsPagingFile()). If you are not interested in I/O
> to
> the paging file, then your dispatch routine can be a stub that calls a
> paged
> routine to do the real work.
>
> All I/O completion routines (post-processing) must be non-paged. However,
> in many cases (See IoIsOperationSynchronous), the completion routine can
> simply synchronize back to the dispatch routine, which is paged.
>
> If the completion cannot be synchronized to dispatch, it can often be
> posted
> to a worker thread, which may be pageable. The complex rules regarding
> what
> can and cannot be posted, and what you can and cannot do from posted
> completion processing are beyond the scope of the OP’s question, so I’ll
> refuse to address it.
>
> All of this assumes that you are using synchronization mechanisms that are
> reasonable and appropriate for file systems, e.g. ERESOURCEs, not spin
> locks. It also assumes the driver is written in C, as God and Dave
> intended.
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
> Sent: Monday, March 26, 2007 5:23 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] PAGE code sections
>
>
> If the FSFD is a legacy driver, then probably only the DriverEntry() path
> is
>
> good for paging. If you are using C++, then never use paged code or data.
> The placement of functions called from C++ is very unpredictable and one
> might get placed in paged memory where it might be referenced in the
> paging
> path. If your driver was to only attach to volumes that cannot contain
> the
> page file, then paging might work, but analyze carefully.
>
> If it is a minifilter, I guess most of the same rules apply. Watch out
> for
> function that can be called on a volume that can contain a page file.
> Also
> watch out for use of C++. Create a .map file and see where each function
> gets placed. All this can be done and will have to be done with each
> build - automate with python, if you like.
>
> “Neil Weicher” wrote in message news:xxxxx@ntfsd…
>>I have seen discussions that using #pragma alloc_text(PAGE, …) can do
>>more
>> harm than good if not done right.
>>
>> Can someone in the know give some rules of thumb as when it might be
>> helpful, if ever? Particularly in a FSFD.
>>
>> Thanks.
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@privtek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

9

> I have seen discussions that using #pragma alloc_text(PAGE, …) can do more

harm than good if not done right.

Can someone in the know give some rules of thumb as when it might be
helpful, if ever? Particularly in a FSFD.

Code in such a section can never run on >= DISPATCH_LEVEL, this is a crash.

Data in such a section (as also data allocated from PagedPool) can never be
accessed on DISPATCH_LEVEL, this is a crash.

Code running on >= DISPATCH_LEVEL is:
a) any code holding a spinlock
b) any DPC queued by timer or by KeInsertQueueDpc
c) an ISR
d) any IRP completion routine - you do not know its IRQL actually, but it can
be == DISPATCH_LEVEL
d) any callback called by the stack below you like TDI receive indications
etc, which is documented to run at DISPATCH_LEVEL or >= DISPATCH_LEVEL.

These were the rules. To help finding their violations, use PAGED_CODE macro in
any function declared in PAGE section - the macro is “controlled BSOD if IRQL
is >= DISPATCH_LEVEL”.

Also use the Verifier option to page out all pageable stuff on each IRQL raise.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

10

Thanks Max,

All makes sense. The only thing I might disagree on (at least with a filter)
is an IRP_MJ_CREATE completion routine. I have never seen that called at
anything but PASSIVE_LEVEL. Has anyone?

Neil

----- Original Message -----
From: “Maxim S. Shatskih”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, March 28, 2007 3:32 PM
Subject: Re:[ntfsd] PAGE code sections

>> I have seen discussions that using #pragma alloc_text(PAGE, …) can do
>> more
>> harm than good if not done right.
>>
>> Can someone in the know give some rules of thumb as when it might be
>> helpful, if ever? Particularly in a FSFD.
>
> Code in such a section can never run on >= DISPATCH_LEVEL, this is a
> crash.
>
> Data in such a section (as also data allocated from PagedPool) can never
> be
> accessed on DISPATCH_LEVEL, this is a crash.
>
> Code running on >= DISPATCH_LEVEL is:
> a) any code holding a spinlock
> b) any DPC queued by timer or by KeInsertQueueDpc
> c) an ISR
> d) any IRP completion routine - you do not know its IRQL actually, but it
> can
> be == DISPATCH_LEVEL
> d) any callback called by the stack below you like TDI receive indications
> etc, which is documented to run at DISPATCH_LEVEL or >= DISPATCH_LEVEL.
>
> These were the rules. To help finding their violations, use PAGED_CODE
> macro in
> any function declared in PAGE section - the macro is “controlled BSOD if
> IRQL
> is >= DISPATCH_LEVEL”.
>
> Also use the Verifier option to page out all pageable stuff on each IRQL
> raise.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@netlib.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

11

Max,

Are there any Fastio routines that should NOT be paged?

Thanks.

----- Original Message -----

From: “Maxim S. Shatskih”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Wednesday, March 28, 2007 3:32 PM
> Subject: Re:[ntfsd] PAGE code sections
>
>
>> d) any IRP completion routine - you do not know its IRQL actually, but it