I can't detect page file at boot time

I have a problem with operations on \pagefile.sys at boot time. Many FltMgr
calls don’t work on this file, they even cause asserts. I would like to
detect that it is a paging file before trying to do anything with it but I’m
finding that is impossible no matter what I try in any operation.

In create I am supposed to be able to use FlagOn(
Data->Iopb->Parameters->Create->Options, SL_OPEN_PAGING_FILE) but this is
not working. The Options value is 0x1000028 and SL_OPEN_PAGING_FILE is
0x02. I’ve looked at lots of other Options and Flags values and none have
this bit set.

Meanwhile FsRtlIsPagingFile returns FALSE on all calls in all pre and post
operations.

Can someone please help me? I am out of ideas.

Could I reliably assume that the file object name is always \pagefile.sys ?

Mark,

You need to keep in mind here that just because someone opens “the
paging file” it does not mean that they are opening it AS a paging file.
Thus, your comment that this bit is not set (and therefore your
algorithm doesn’t work for checking the bit) just can’t be true - the
Memory Manager calls a special function to open the paging file and that
function sets the bit.

HOWEVER, before that happens, other programs can (and do) open the
paging file for normal I/O. Crash dumps (for example) are written out
to pagefile.sys and the application that saves away the data contents
opens the file but NOT for use as a paging file.

There is no requirement the file be called pagefile.sys and I believe
you can change this in the registry. BUT you should not need to embed a
name to make this work right.

How about this: you just breakpoint every time the file opened is
called “pagefile.sys” and grab the stack backtrace and the flags field
from the I/O Stack location (where SL_OPEN_PAGING_FILE is set). I
believe you will find that at least one of them shows the bit set.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Friday, April 01, 2005 5:12 PM
To: ntfsd redirect
Subject: [ntfsd] I can’t detect page file at boot time

I have a problem with operations on \pagefile.sys at boot time. Many
FltMgr
calls don’t work on this file, they even cause asserts. I would like to

detect that it is a paging file before trying to do anything with it but
I’m
finding that is impossible no matter what I try in any operation.

In create I am supposed to be able to use FlagOn(
Data->Iopb->Parameters->Create->Options, SL_OPEN_PAGING_FILE) but this
is
not working. The Options value is 0x1000028 and SL_OPEN_PAGING_FILE is
0x02. I’ve looked at lots of other Options and Flags values and none
have
this bit set.

Meanwhile FsRtlIsPagingFile returns FALSE on all calls in all pre and
post
operations.

Can someone please help me? I am out of ideas.

Could I reliably assume that the file object name is always
\pagefile.sys ?


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

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

Of course when thinking about it the problem is obvious: you are looking
for I/O Stack Location flags in the Options parameter. Doesn’t work
that way.

I/O Stack Location flags have an SL_ prefix. You are not looking in the
right place.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Hahn
Sent: Friday, April 01, 2005 5:12 PM
To: ntfsd redirect
Subject: [ntfsd] I can’t detect page file at boot time

I have a problem with operations on \pagefile.sys at boot time. Many
FltMgr
calls don’t work on this file, they even cause asserts. I would like to

detect that it is a paging file before trying to do anything with it but
I’m
finding that is impossible no matter what I try in any operation.

In create I am supposed to be able to use FlagOn(
Data->Iopb->Parameters->Create->Options, SL_OPEN_PAGING_FILE) but this
is
not working. The Options value is 0x1000028 and SL_OPEN_PAGING_FILE is
0x02. I’ve looked at lots of other Options and Flags values and none
have
this bit set.

Meanwhile FsRtlIsPagingFile returns FALSE on all calls in all pre and
post
operations.

Can someone please help me? I am out of ideas.

Could I reliably assume that the file object name is always
\pagefile.sys ?


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

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

> you are looking for I/O Stack Location flags in the Options parameter

I have tried looking at Data->Iopb->OperationFlags also, which I think is
what you are refering to. That value is zero on \pagefile.sys create at
boot time.

HOWEVER, before that happens, other programs can (and do) open the
paging file for normal I/O. Crash dumps (for example) are written out
to pagefile.sys and the application that saves away the data contents
opens the file but NOT for use as a paging file.

So you are saying that sometimes the bit is NOT set when the file is opened
the normal way? Can I put a context on
this \pagefile.sys stream in that situation?

I have verified that the bit is set properly on a later operation after the
first few boot calls. I have also verified that the asserts only happen
when irql is too high. So I guess I can ignore errors from FltMgr calls
until the bit is set and I can then switch to using the FsContext stored in
the Volume Context.

Thanks mucho for your support…

Mark,

Of course you can attach a context to a file called \pagefile.sys when
it is opened without the paging file flag. The filter manager (and the
file systems) do not check for these things by name.

FYI: the reason you can’t attach a context to a paging file is because
the file systems do not support perStreamContexts on paging files. This
is all triggered by the flag, not by name.

I am not sure what you mean by “I can ignore errors from fltmgr calls
until the bit is set”. What errors are you referring to?

Neal Christiansen
Microsoft File System Filter Group 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 Mark Hahn
Sent: Friday, April 01, 2005 4:53 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] I can’t detect page file at boot time

you are looking for I/O Stack Location flags in the Options parameter

I have tried looking at Data->Iopb->OperationFlags also, which I think
is
what you are refering to. That value is zero on \pagefile.sys create at
boot time.

HOWEVER, before that happens, other programs can (and do) open the
paging file for normal I/O. Crash dumps (for example) are written out
to pagefile.sys and the application that saves away the data contents
opens the file but NOT for use as a paging file.

So you are saying that sometimes the bit is NOT set when the file is
opened
the normal way? Can I put a context on
this \pagefile.sys stream in that situation?

I have verified that the bit is set properly on a later operation after
the
first few boot calls. I have also verified that the asserts only happen

when irql is too high. So I guess I can ignore errors from FltMgr calls
until the bit is set and I can then switch to using the FsContext stored
in
the Volume Context.

Thanks mucho for your support…


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

> I am not sure what you mean by "I can ignore errors from fltmgr calls

until the bit is set".
What errors are you referring to?

I was assuming it would be an error to try any fltmgr calls to \pagefile.sys
at any time. Now that you have explained that it is ok to deal with it like
a normal file, I understand I will not get any errors.

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

Of course you can attach a context to a file called \pagefile.sys when
it is opened without the paging file flag. The filter manager (and the
file systems) do not check for these things by name.

FYI: the reason you can’t attach a context to a paging file is because
the file systems do not support perStreamContexts on paging files. This
is all triggered by the flag, not by name.

I am not sure what you mean by “I can ignore errors from fltmgr calls
until the bit is set”. What errors are you referring to?

Neal Christiansen
Microsoft File System Filter Group 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 Mark Hahn
Sent: Friday, April 01, 2005 4:53 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] I can’t detect page file at boot time

> you are looking for I/O Stack Location flags in the Options parameter

I have tried looking at Data->Iopb->OperationFlags also, which I think
is
what you are refering to. That value is zero on \pagefile.sys create at
boot time.

> HOWEVER, before that happens, other programs can (and do) open the
> paging file for normal I/O. Crash dumps (for example) are written out
> to pagefile.sys and the application that saves away the data contents
> opens the file but NOT for use as a paging file.

So you are saying that sometimes the bit is NOT set when the file is
opened
the normal way? Can I put a context on
this \pagefile.sys stream in that situation?

I have verified that the bit is set properly on a later operation after
the
first few boot calls. I have also verified that the asserts only happen

when irql is too high. So I guess I can ignore errors from FltMgr calls
until the bit is set and I can then switch to using the FsContext stored
in
the Volume Context.

Thanks mucho for your support…


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