Hi all,
Does anyone have experience with disk drivers under Windows 7, and how the operating system decides whether it can create a pagefile on the volume or not? When we boot off our virtual disk system, the o/s informs us that there is no pagefile on the volume, and when I try to setup a pagefile on it, the pagefile is not created - after a reboot the pagefile is still not there, and the o/s pops a dialog saying that there is no pagefile.
I’m assuming their’s some IOCTL on the device, or extended properties that I’m not answering correctly - perhaps something that wasn’t previously checked, but is in Windows 7. Anyone else see anything similar?
> When we boot off our virtual disk system, the o/s informs us that there
is no pagefile on the volume, and when I try to setup a pagefile on it,
the pagefile is not created - after a reboot the pagefile is still not
there,
and the o/s pops a dialog saying that there is no pagefile.
Can you check if NtCreatePagingFile is getting called, and if so, what
status it returns?
–
Pavel Lebedinsky/Windows Kernel Test
This posting is provided “AS IS” with no warranties, and confers no rights.
Hi Pavel,
I don’t have any insight to NtCreatePagingFile, is that a file-system level call? I took a look at the IRP’s that our disk driver and bus driver handle, and I saw something that looks like it causes the issue - I’m just not sure why it is the way it is.
The IRP IRP_MN_DEVICE_USAGE_NOTIFICATION is used to tell the driver that a pagefile has been created. When we handle that for the partition (the PDO - at least according to the comments), we count the pagefile requests and handle the request appropriately, answering with status success. I noticed, though, that when we handle that IRP on a request for the whole disk (the FDO, I think), we were returning “STATUS_MEDIA_WRITE_PROTECTED”. I’m not sure why this code was originally introduced, but it doesn’t seem right.
Looking at the online docs now, it says that all drivers in the path have to support paging, in order for the device to support paging. I’m just not sure what we’re supposed to do when we receive this request on the FDO - should we mark the driver non-pageable and increment the count, or is Windows just checking to see if the capability is supported?
At the moment, the FDO refuses and IRP_MN_DEVICE_USAGE_NOTIFICATION with “STATUS_MEDIA_WRITE_PROTECTED”, whereas the PDO checks the type and handles the page file add / drops correctly.
Just adding - when I look at it, it seems like the partition should be the FDO, and the disk should be the PDO, but perhaps I misunderstand PDO and FDO…Back to reading Oney, I think.
Anyone know the answer, though, to which object should handle this IRP, and if both should respond with “SUCCESS”, or just one?
On 26/10/2009 21:44, john.robinson@hp.com wrote:
Just adding - when I look at it, it seems like the partition should be the FDO, and the disk should be the PDO, but perhaps I misunderstand PDO and FDO…Back to reading Oney, I think.
Anyone know the answer, though, to which object should handle this IRP, and if both should respond with “SUCCESS”, or just one?
Does this help:
http://www.osronline.com/DDKx/storage/01scsidr_6nfr.htm
?
Every devobj down the stack and the entire ancestry of parents needs to answer with success. The pdo is responsible for sending the usage notification down its parent stack (and so on)
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: john.robinson@hp.com <john.robinson>
Sent: Monday, October 26, 2009 1:45 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] pagefile on Windows 7
Just adding - when I look at it, it seems like the partition should be the FDO, and the disk should be the PDO, but perhaps I misunderstand PDO and FDO…Back to reading Oney, I think.
Anyone know the answer, though, to which object should handle this IRP, and if both should respond with “SUCCESS”, or just one?
—
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</john.robinson>
> I don’t have any insight to NtCreatePagingFile, is that a file-system
level
call?
It’s a system call. SMSS.EXE and the pagefile applet in the control panel
use it to create pagefiles. You could set a breakpoint on it from the kernel
debugger (bp nt!NtCreatePagingFile) and see what it returns.
–
Pavel Lebedinsky/Windows Kernel Test
This posting is provided “AS IS” with no warranties, and confers no rights.
> At the moment, the FDO refuses and IRP_MN_DEVICE_USAGE_NOTIFICATION
“STATUS_MEDIA_WRITE_PROTECTED”
Are you sure you do not ban pagefiles by this? look at the docs.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
I have a related question.
I noticed that there are functions to create Page Files
(NTCreatePagingFile/ZwCreatePagingFile) but there does not seem to be
any support to delete PagingFile (no ZwDeletePagingFile for instance).
So how is the PagingPathCount property modified (decreased) when a
system is shutting down?
I used to monitor this PagingPathCount property in a disk class driver
(in its routine to process IRP_MN_DEVICE_USAGE_NOTIFICATION) and I never
saw it being decreased at shutdown…
Does Windows assume that once created, a Paging File stays here and is
available up to the very last moment when the system is actually powered
down?
Is IoAdjustPagingPathCount called at a higher level (maybe by PartMgr)
and my driver just don’t get the call? But then, how can I adjust my own
count of paging files, in order to process the DO_POWER_PAGABLE flag
accordingly?
I understand that ZwDeletePagingFile would have to “Page Out” all the
remaining pages, which might be a problem, but still, there is something
I don’t get here.
And if I ask this question, it’s because I sometimes get
KERNEL_DATA_INPAGE_ERROR with my disk driver, which happens AFTER my
disk driver has stopped at shutdown time (and thus no Page File is there
to allow the Page Fault to be processed). It is usually SERIAL.SYS or
VIDEOPRT.SYS that causes this KDIP Error, but AFAIU, any paged data or
code could still be generating a page fault after my disk driver has
ceased answering requests.
Maybe I miss something and what I would have to do would be to make
things so that my driver and all the drivers that it depends on are the
very last to shutdown.
I think I process DO_POWER_PAGABLE correctly and I do not think that the
issue comes from there (actually I even tried to force DO_POWER_PAGABLE
to 0 or 1 to diagnose the issue and it did not change anything).
Any help regarding Paging Files processing at shutdown would be highly
appreciated
TIA
> Does Windows assume that once created, a Paging File stays here and is
available up to the very last moment when the system is actually powered
down?
I think yes.
Windows does not clean up the things at shutdown, this is not needed since the memory is going away anyway.
Delete the pagefile explicitly from the control panel.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
On 27/10/2009 18:51, Maxim S. Shatskih wrote:
type=“cite”>
Does Windows assume that once created, a Paging File stays here and is
available up to the very last moment when the system is actually powered
down?
I think yes.
Windows does not clean up the things at shutdown, this is not needed since the memory is going away anyway.
Delete the pagefile explicitly from the control panel.
But this requires a reboot.
And if a reboot can’t be completed because of some kind of race
condition with the disk driver that is not available anymore to
complete the shutdown/reboot operation, we are kind of stuck…
Now I understand why MS recommends not to put pagefiles on iSCSi drives!
href="http://download.microsoft.com/download/A/E/9/AE91DEA1-66D9-417C-ADE4-92D824B871AF/uGuide.doc"\>http://download.microsoft.com/download/A/E/9/AE91DEA1-66D9-417C-ADE4-92D824B871AF/uGuide.doc
And yet, there are some remote/virtual disks systems such as Citrix
Provisioning Server, that do support paging files on remote drives
(that by definition need the network stack to operate)
Maybe they are “lucky enough” not to face the kind of issue I saw
Hi all,
I want to post an update to the original problem - and ask for some suggestions. What I discovered is that Windows XP creates a partition object on top of our disk object, and it is to this that the IRP_MN_DEVICE_USAGE_NOTIFICATION was being posted to. Windows 7 is not creating a partition on top of our drive, and so is posting the IRP_MN_DEVICE_USAGE_NOTIFICATION directly to the FDO of our disk object.
Our handling routine for the partition is probably incorrect. What it does at the moment is notes the pagefile addition and completes the IRP without passing it to any other drivers. Hence the rest of the stack is unaware that the pagefile is in place, which is wrong. Our pagefile for the disk PDO is wrong also - it rejects the pagefile request, which I think was someone misunderstanding what a PDO was. Obviously I can fix that, though. But my questions are:
Should the partition hook to the disk PDO’s stack with IoAttachDeviceToDeviceStack? Walter Oney’s DevView knows that the partition is a FiDO on the stack, but I don’t call IoAttachDeviceToDeviceStack. I have nowhere to send the IRP down to, except I can find the disk FDO from the deviceextension in the partition, and forward it manually.
And a clarification, it looks from the online docs that I send the IRP down to the PDO for the disk, which is handled by the bus-driver. Is that how far it is recommended to go? If the bus-driver actually handles the read and write access on behalf of the child PDO, would you also need to notify the bus-driver FDO that it is in the paging path?
BTW, I much appreciate everyone’s help and answers to date. Handling of these control IRPs is new to me, and the pointers you have given have been most helpful.