Mount issues with a filesystem...

Hi All,

I have gone through the archive looking for a similar problem but could not find
anything. So the problem I am having is with a File System driver (not a filter
based driver), and Windows XP. Note: the filesystem is currently functional
(i.e. the filesystem is mounted without any issues) on the NT4, W2K, and to some
extent on XP platforms.

The problem is I am not getting the IRP_MN_MOUNT_VOLUME ioctl from the XP
IOManager, and I don’t understand why? I used the OSR Device Tree application
to determine if any of the devices that I have initialized during driver start
up where invalid, but they looked fine.

So a psuedo code rundown of driver startup is:

DriverEntry()
{
generic initialization…

IoCreateDevice(); /* creates the FILE_DEVICE_DISK_FILE_SYSTEM device */

IoCreateSymbolicLink(); /* init the user visible name */

more driver initialization
which includes IoCreateDevice() /* create a virtual FILE_DISK_DEVICE device */

return Status;
}

Something I should mention (re: FILE_DISK_DEVICE above), although ashamedly, we
also create a virtual disk device which we use to mount our filesystem(s) on.
This is what I expect to get a mount request for, the Device Tree shows these
devices to be intialized correctly…

Also I have not been able to reproduce this problem on any of my test systems
locally, unfortunately this problem has, typically, only shown iteslf on
customer sites (and not all of them) running XP Profesional. So it has been hard
debugging this one, so I have been primarily inspecting the code (which is
proprietry so I can’t give too much away, if anything).

Thanks,

Ian Costello
R&D Engineer SGI

Where is your call to IoRegisterFileSystem? Without that, you won’t get
a mount call.

Regards,

Tony

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
Sent: Thursday, July 22, 2004 10:06 AM
To: ntfsd redirect
Subject: [ntfsd] Mount issues with a filesystem…

Hi All,

I have gone through the archive looking for a similar problem but could
not find anything. So the problem I am having is with a File System
driver (not a filter based driver), and Windows XP. Note: the filesystem
is currently functional (i.e. the filesystem is mounted without any
issues) on the NT4, W2K, and to some extent on XP platforms.

The problem is I am not getting the IRP_MN_MOUNT_VOLUME ioctl from the
XP IOManager, and I don’t understand why? I used the OSR Device Tree
application to determine if any of the devices that I have initialized
during driver start up where invalid, but they looked fine.

So a psuedo code rundown of driver startup is:

DriverEntry()
{
generic initialization…

IoCreateDevice(); /* creates the FILE_DEVICE_DISK_FILE_SYSTEM device */

IoCreateSymbolicLink(); /* init the user visible name */

more driver initialization
which includes IoCreateDevice() /* create a virtual FILE_DISK_DEVICE
device */

return Status;
}

Something I should mention (re: FILE_DISK_DEVICE above), although
ashamedly, we also create a virtual disk device which we use to mount
our filesystem(s) on.
This is what I expect to get a mount request for, the Device Tree shows
these devices to be intialized correctly…

Also I have not been able to reproduce this problem on any of my test
systems locally, unfortunately this problem has, typically, only shown
iteslf on customer sites (and not all of them) running XP Profesional.
So it has been hard debugging this one, so I have been primarily
inspecting the code (which is proprietry so I can’t give too much away,
if anything).

Thanks,

Ian Costello
R&D Engineer SGI


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

Tony,

Whoops, I neglected to add that call in the pseudo code below. It is one of the
last things that is done in DriverEntry(). Is there anything else that would
cause this, i.e. as I create a “virtual disk” this may cause problems with the
IoManager, particularly the way it is created? I don’t actually specify any
device characteristics (although I thought that was not necessary).

I know that we where getting IOCTL_DISK_CHECK_VERIFY ioctls for the virtual disk
device, and incorrectly handling them (which I now do) via a
STATUS_INVALID_PARAMTER return code. Ever since I discovered that, I added that
handler and put the driver on a system in the field the problem went away, but I
was not getting the IOCTL_DISK_CHECK_VERIFY ioctls??? This makes no sense to me
and I don’t want to mark this as a fixed when I don’t understand what is
occurring…

Thanks,

  • Ian Costello

----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, July 23, 2004 4:04 AM
Subject: RE: [ntfsd] Mount issues with a filesystem…

> Where is your call to IoRegisterFileSystem? Without that, you won’t get
> a mount call.
>
> Regards,
>
> Tony
>
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
> Sent: Thursday, July 22, 2004 10:06 AM
> To: ntfsd redirect
> Subject: [ntfsd] Mount issues with a filesystem…
>
> Hi All,
>
> I have gone through the archive looking for a similar problem but could
> not find anything. So the problem I am having is with a File System
> driver (not a filter based driver), and Windows XP. Note: the filesystem
> is currently functional (i.e. the filesystem is mounted without any
> issues) on the NT4, W2K, and to some extent on XP platforms.
>
> The problem is I am not getting the IRP_MN_MOUNT_VOLUME ioctl from the
> XP IOManager, and I don’t understand why? I used the OSR Device Tree
> application to determine if any of the devices that I have initialized
> during driver start up where invalid, but they looked fine.
>
> So a psuedo code rundown of driver startup is:
>
> DriverEntry()
> {
> generic initialization…
>
> IoCreateDevice(); /* creates the FILE_DEVICE_DISK_FILE_SYSTEM device /
>
> IoCreateSymbolicLink(); /
init the user visible name /
>
> more driver initialization
> which includes IoCreateDevice() /
create a virtual FILE_DISK_DEVICE
> device */
>
> return Status;
> }
>
> Something I should mention (re: FILE_DISK_DEVICE above), although
> ashamedly, we also create a virtual disk device which we use to mount
> our filesystem(s) on.
> This is what I expect to get a mount request for, the Device Tree shows
> these devices to be intialized correctly…
>
> Also I have not been able to reproduce this problem on any of my test
> systems locally, unfortunately this problem has, typically, only shown
> iteslf on customer sites (and not all of them) running XP Profesional.
> So it has been hard debugging this one, so I have been primarily
> inspecting the code (which is proprietry so I can’t give too much away,
> if anything).
>
> Thanks,
>
> Ian Costello
> R&D Engineer SGI
>
>
> —
> 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
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@sgi.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

I’m wondering if maybe a different FSD is trying to mount on top of your
virtual volume BEFORE your FSD gets a chance to do so. I’ve had
problems in this area before - the I/O Manager will treat certain errors
as fatal and stop mount processing, so you never get called.

For example, we had a file system that worked on WORM media. If NTFS
were asked to mount a specific volume (on the WORM drive) it would
return a STATUS_NONEXISTENT_SECTOR error (or some other clearly
distinguished error, but that’s the best match I could find this evening
in ntstatus.h) to the I/O Manager (because the sector it tried to read
hadn’t been written yet) and our WORM media file system would not be
called to mount (of course all we saw was that our mount was never
called). It was volume specific because for a different volume it was
fine - the region read by NTFS was valid and then NTFS failed the mount
with a recoverable error (STATUS_UNRECOGNIZED_MEDIA most likely). We
had to resolve this by adding logic to make sure that when a different
file system registered, we would unregister and then re-register. While
not generally applicable (can’t have two such file systems together) it
solved the problem - and for the customer’s environment it was workable
because it was controlled.

Personally, I think the I/O Manager is far too conservative in this
arena (it should allow other FSDs to try, even if there are “I/O Errors”
on the drive) but when I last inquired (many years ago) I was told by
the powers-that-be that they saw no reason to change it.

It would fit your description, but presumes that some other FSD is
registering AFTER you register, and from the information provided, I
can’t tell if that is the case or not.

Regards,

Tony

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
Sent: Thursday, July 22, 2004 7:02 PM
To: ntfsd redirect
Subject: Re: [ntfsd] Mount issues with a filesystem…

Tony,

Whoops, I neglected to add that call in the pseudo code below. It is one
of the last things that is done in DriverEntry(). Is there anything else
that would cause this, i.e. as I create a “virtual disk” this may cause
problems with the IoManager, particularly the way it is created? I don’t
actually specify any device characteristics (although I thought that was
not necessary).

I know that we where getting IOCTL_DISK_CHECK_VERIFY ioctls for the
virtual disk device, and incorrectly handling them (which I now do) via
a STATUS_INVALID_PARAMTER return code. Ever since I discovered that, I
added that handler and put the driver on a system in the field the
problem went away, but I was not getting the IOCTL_DISK_CHECK_VERIFY
ioctls??? This makes no sense to me and I don’t want to mark this as a
fixed when I don’t understand what is occurring…

Thanks,

  • Ian Costello

----- Original Message -----
From: “Tony Mason”
To: “Windows File Systems Devs Interest List”
Sent: Friday, July 23, 2004 4:04 AM
Subject: RE: [ntfsd] Mount issues with a filesystem…

> Where is your call to IoRegisterFileSystem? Without that, you won’t
get
> a mount call.
>
> Regards,
>
> Tony
>
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
> Sent: Thursday, July 22, 2004 10:06 AM
> To: ntfsd redirect
> Subject: [ntfsd] Mount issues with a filesystem…
>
> Hi All,
>
> I have gone through the archive looking for a similar problem but
could
> not find anything. So the problem I am having is with a File System
> driver (not a filter based driver), and Windows XP. Note: the
filesystem
> is currently functional (i.e. the filesystem is mounted without any
> issues) on the NT4, W2K, and to some extent on XP platforms.
>
> The problem is I am not getting the IRP_MN_MOUNT_VOLUME ioctl from the
> XP IOManager, and I don’t understand why? I used the OSR Device Tree
> application to determine if any of the devices that I have initialized
> during driver start up where invalid, but they looked fine.
>
> So a psuedo code rundown of driver startup is:
>
> DriverEntry()
> {
> generic initialization…
>
> IoCreateDevice(); /* creates the FILE_DEVICE_DISK_FILE_SYSTEM device
/
>
> IoCreateSymbolicLink(); /
init the user visible name /
>
> more driver initialization
> which includes IoCreateDevice() /
create a virtual FILE_DISK_DEVICE
> device */
>
> return Status;
> }
>
> Something I should mention (re: FILE_DISK_DEVICE above), although
> ashamedly, we also create a virtual disk device which we use to mount
> our filesystem(s) on.
> This is what I expect to get a mount request for, the Device Tree
shows
> these devices to be intialized correctly…
>
> Also I have not been able to reproduce this problem on any of my test
> systems locally, unfortunately this problem has, typically, only shown
> iteslf on customer sites (and not all of them) running XP Profesional.
> So it has been hard debugging this one, so I have been primarily
> inspecting the code (which is proprietry so I can’t give too much
away,
> if anything).
>
> Thanks,
>
> Ian Costello
> R&D Engineer SGI
>
>
> —
> 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
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@sgi.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@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Tony,

Thanks for the prompt reply. This is really interesting as we also had a
similar problem a while back with zip drives, that is we where handling the
mount request ourselves incorrectly and the zip drive was inaccessible as a
result. From your explanation this was the reason in that case.

The problem I am looking at is also probably the same, I don’t have info
regarding whether the system has another (other than NTFS and FAST FAT)
filesystem installed but will get that shortly. If there is something there
that is installed before us, then will add the logic into the registration
of the filesystem that you discussed (maybe getting a little ahead of
myself)…

Anyway thanks for your help.

PS have been nagging my boss about a trip over to the states for one of your
filesystem seminars :wink: (he is also subscribed to this list so maybe another
hint will help)…

Thanks,

Ian Costello

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Tony Mason
Sent: Friday, 23 July 2004 10:17 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Mount issues with a filesystem…

I’m wondering if maybe a different FSD is trying to mount on top of your
virtual volume BEFORE your FSD gets a chance to do so. I’ve had
problems in this area before - the I/O Manager will treat certain errors
as fatal and stop mount processing, so you never get called.

For example, we had a file system that worked on WORM media. If NTFS
were asked to mount a specific volume (on the WORM drive) it would
return a STATUS_NONEXISTENT_SECTOR error (or some other clearly
distinguished error, but that’s the best match I could find this evening
in ntstatus.h) to the I/O Manager (because the sector it tried to read
hadn’t been written yet) and our WORM media file system would not be
called to mount (of course all we saw was that our mount was never
called). It was volume specific because for a different volume it was
fine - the region read by NTFS was valid and then NTFS failed the mount
with a recoverable error (STATUS_UNRECOGNIZED_MEDIA most likely). We
had to resolve this by adding logic to make sure that when a different
file system registered, we would unregister and then re-register. While
not generally applicable (can’t have two such file systems together) it
solved the problem - and for the customer’s environment it was workable
because it was controlled.

Personally, I think the I/O Manager is far too conservative in this
arena (it should allow other FSDs to try, even if there are “I/O Errors”
on the drive) but when I last inquired (many years ago) I was told by
the powers-that-be that they saw no reason to change it.

It would fit your description, but presumes that some other FSD is
registering AFTER you register, and from the information provided, I
can’t tell if that is the case or not.

Regards,

Tony

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
Sent: Thursday, July 22, 2004 7:02 PM
To: ntfsd redirect
Subject: Re: [ntfsd] Mount issues with a filesystem…

Tony,

Whoops, I neglected to add that call in the pseudo code below. It is one
of the last things that is done in DriverEntry(). Is there anything else
that would cause this, i.e. as I create a “virtual disk” this may cause
problems with the IoManager, particularly the way it is created? I don’t
actually specify any device characteristics (although I thought that was
not necessary).

I know that we where getting IOCTL_DISK_CHECK_VERIFY ioctls for the
virtual disk device, and incorrectly handling them (which I now do) via
a STATUS_INVALID_PARAMTER return code. Ever since I discovered that, I
added that handler and put the driver on a system in the field the
problem went away, but I was not getting the IOCTL_DISK_CHECK_VERIFY
ioctls??? This makes no sense to me and I don’t want to mark this as a
fixed when I don’t understand what is occurring…

Thanks,

  • Ian Costello

----- Original Message -----
From: “Tony Mason”
> To: “Windows File Systems Devs Interest List”
> Sent: Friday, July 23, 2004 4:04 AM
> Subject: RE: [ntfsd] Mount issues with a filesystem…
>
>
> > Where is your call to IoRegisterFileSystem? Without that, you won’t
> get
> > a mount call.
> >
> > Regards,
> >
> > Tony
> >
> >
> > Tony Mason
> > Consulting Partner
> > OSR Open Systems Resources, Inc.
> > http://www.osr.com
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
> > Sent: Thursday, July 22, 2004 10:06 AM
> > To: ntfsd redirect
> > Subject: [ntfsd] Mount issues with a filesystem…
> >
> > Hi All,
> >
> > I have gone through the archive looking for a similar problem but
> could
> > not find anything. So the problem I am having is with a File System
> > driver (not a filter based driver), and Windows XP. Note: the
> filesystem
> > is currently functional (i.e. the filesystem is mounted without any
> > issues) on the NT4, W2K, and to some extent on XP platforms.
> >
> > The problem is I am not getting the IRP_MN_MOUNT_VOLUME ioctl from the
> > XP IOManager, and I don’t understand why? I used the OSR Device Tree
> > application to determine if any of the devices that I have initialized
> > during driver start up where invalid, but they looked fine.
> >
> > So a psuedo code rundown of driver startup is:
> >
> > DriverEntry()
> > {
> > generic initialization…
> >
> > IoCreateDevice(); /* creates the FILE_DEVICE_DISK_FILE_SYSTEM device
> /
> >
> > IoCreateSymbolicLink(); /
init the user visible name /
> >
> > more driver initialization
> > which includes IoCreateDevice() /
create a virtual FILE_DISK_DEVICE
> > device */
> >
> > return Status;
> > }
> >
> > Something I should mention (re: FILE_DISK_DEVICE above), although
> > ashamedly, we also create a virtual disk device which we use to mount
> > our filesystem(s) on.
> > This is what I expect to get a mount request for, the Device Tree
> shows
> > these devices to be intialized correctly…
> >
> > Also I have not been able to reproduce this problem on any of my test
> > systems locally, unfortunately this problem has, typically, only shown
> > iteslf on customer sites (and not all of them) running XP Profesional.
> > So it has been hard debugging this one, so I have been primarily
> > inspecting the code (which is proprietry so I can’t give too much
> away,
> > if anything).
> >
> > Thanks,
> >
> > Ian Costello
> > R&D Engineer SGI
> >
> >
> > —
> > 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
> >
> >
> >
> > —
> > Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: xxxxx@sgi.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@osr.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@sgi.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Ian,

Keep in mind, mount ordering is LIFO - so last registered file system is
first called file system. RAW, for example, registers FIRST, and thus
gets called LAST.

If another FSD registers AFTER your FSD, then it will be called BEFORE
you to mount!

Regards,

Tony

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
Sent: Thursday, July 22, 2004 8:44 PM
To: ntfsd redirect
Subject: RE: [ntfsd] Mount issues with a filesystem…

Tony,

Thanks for the prompt reply. This is really interesting as we also had a
similar problem a while back with zip drives, that is we where handling
the mount request ourselves incorrectly and the zip drive was
inaccessible as a result. From your explanation this was the reason in
that case.

The problem I am looking at is also probably the same, I don’t have info
regarding whether the system has another (other than NTFS and FAST FAT)
filesystem installed but will get that shortly. If there is something
there that is installed before us, then will add the logic into the
registration of the filesystem that you discussed (maybe getting a
little ahead of myself)…

Anyway thanks for your help.

PS have been nagging my boss about a trip over to the states for one of
your filesystem seminars :wink: (he is also subscribed to this list so maybe
another hint will help)…

Thanks,

Ian Costello

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Tony Mason
Sent: Friday, 23 July 2004 10:17 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Mount issues with a filesystem…

I’m wondering if maybe a different FSD is trying to mount on top of
your virtual volume BEFORE your FSD gets a chance to do so. I’ve had
problems in this area before - the I/O Manager will treat certain
errors as fatal and stop mount processing, so you never get called.

For example, we had a file system that worked on WORM media. If NTFS
were asked to mount a specific volume (on the WORM drive) it would
return a STATUS_NONEXISTENT_SECTOR error (or some other clearly
distinguished error, but that’s the best match I could find this
evening in ntstatus.h) to the I/O Manager (because the sector it tried

to read hadn’t been written yet) and our WORM media file system would
not be called to mount (of course all we saw was that our mount was
never called). It was volume specific because for a different volume
it was fine - the region read by NTFS was valid and then NTFS failed
the mount with a recoverable error (STATUS_UNRECOGNIZED_MEDIA most
likely). We had to resolve this by adding logic to make sure that
when a different file system registered, we would unregister and then
re-register. While not generally applicable (can’t have two such file

systems together) it solved the problem - and for the customer’s
environment it was workable because it was controlled.

Personally, I think the I/O Manager is far too conservative in this
arena (it should allow other FSDs to try, even if there are “I/O
Errors”
on the drive) but when I last inquired (many years ago) I was told by
the powers-that-be that they saw no reason to change it.

It would fit your description, but presumes that some other FSD is
registering AFTER you register, and from the information provided, I
can’t tell if that is the case or not.

Regards,

Tony

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
Sent: Thursday, July 22, 2004 7:02 PM
To: ntfsd redirect
Subject: Re: [ntfsd] Mount issues with a filesystem…

Tony,

Whoops, I neglected to add that call in the pseudo code below. It is
one of the last things that is done in DriverEntry(). Is there
anything else that would cause this, i.e. as I create a “virtual disk”

this may cause problems with the IoManager, particularly the way it is

created? I don’t actually specify any device characteristics (although

I thought that was not necessary).

I know that we where getting IOCTL_DISK_CHECK_VERIFY ioctls for the
virtual disk device, and incorrectly handling them (which I now do)
via a STATUS_INVALID_PARAMTER return code. Ever since I discovered
that, I added that handler and put the driver on a system in the field

the problem went away, but I was not getting the
IOCTL_DISK_CHECK_VERIFY ioctls??? This makes no sense to me and I
don’t want to mark this as a fixed when I don’t understand what is
occurring…

Thanks,

  • Ian Costello

----- Original Message -----
From: “Tony Mason”
> To: “Windows File Systems Devs Interest List”
> Sent: Friday, July 23, 2004 4:04 AM
> Subject: RE: [ntfsd] Mount issues with a filesystem…
>
>
> > Where is your call to IoRegisterFileSystem? Without that, you won’t
> get
> > a mount call.
> >
> > Regards,
> >
> > Tony
> >
> >
> > Tony Mason
> > Consulting Partner
> > OSR Open Systems Resources, Inc.
> > http://www.osr.com
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
> > Sent: Thursday, July 22, 2004 10:06 AM
> > To: ntfsd redirect
> > Subject: [ntfsd] Mount issues with a filesystem…
> >
> > Hi All,
> >
> > I have gone through the archive looking for a similar problem but
> could
> > not find anything. So the problem I am having is with a File System
> > driver (not a filter based driver), and Windows XP. Note: the
> filesystem
> > is currently functional (i.e. the filesystem is mounted without any
> > issues) on the NT4, W2K, and to some extent on XP platforms.
> >
> > The problem is I am not getting the IRP_MN_MOUNT_VOLUME ioctl from
> > the XP IOManager, and I don’t understand why? I used the OSR Device
> > Tree application to determine if any of the devices that I have
> > initialized during driver start up where invalid, but they looked
fine.
> >
> > So a psuedo code rundown of driver startup is:
> >
> > DriverEntry()
> > {
> > generic initialization…
> >
> > IoCreateDevice(); /* creates the FILE_DEVICE_DISK_FILE_SYSTEM device
> /
> >
> > IoCreateSymbolicLink(); /
init the user visible name /
> >
> > more driver initialization
> > which includes IoCreateDevice() /
create a virtual FILE_DISK_DEVICE

> > device */
> >
> > return Status;
> > }
> >
> > Something I should mention (re: FILE_DISK_DEVICE above), although
> > ashamedly, we also create a virtual disk device which we use to
> > mount our filesystem(s) on.
> > This is what I expect to get a mount request for, the Device Tree
> shows
> > these devices to be intialized correctly…
> >
> > Also I have not been able to reproduce this problem on any of my
> > test systems locally, unfortunately this problem has, typically,
> > only shown iteslf on customer sites (and not all of them) running XP
Profesional.
> > So it has been hard debugging this one, so I have been primarily
> > inspecting the code (which is proprietry so I can’t give too much
> away,
> > if anything).
> >
> > Thanks,
> >
> > Ian Costello
> > R&D Engineer SGI
> >
> >
> > —
> > 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
> >
> >
> >
> > —
> > Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
> >
> > You are currently subscribed to ntfsd as: xxxxx@sgi.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@osr.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@sgi.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@osr.com To unsubscribe
send a blank email to xxxxx@lists.osr.com

Tony,

What is the best way to see if our device object is being hit
by another file system, or alternatively, how can we tell if
another filesystem is started after us?

If we start our filesystem after login, after all other file
systems have started, then we do not see this problem, which
supports your theory. Since this happens not long after boot,
is there an irptracker-like tool that can capture info on
boot?

Another option might be to review the driver/service dependencies
and ensure that we depend on more, even other standard
filesystems, and start last?

On one system, where I can no longer reproduce the problem,
I see only the standard filesystems installed. I’ll check
with those that still hit this problem to see if they have
any other filesystems or filters installed.

Thanks,

David

Tony Mason wrote:

Ian,

Keep in mind, mount ordering is LIFO - so last registered file system is
first called file system. RAW, for example, registers FIRST, and thus
gets called LAST.

If another FSD registers AFTER your FSD, then it will be called BEFORE
you to mount!

Regards,

Tony

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
Sent: Thursday, July 22, 2004 8:44 PM
To: ntfsd redirect
Subject: RE: [ntfsd] Mount issues with a filesystem…

Tony,

Thanks for the prompt reply. This is really interesting as we also had a
similar problem a while back with zip drives, that is we where handling
the mount request ourselves incorrectly and the zip drive was
inaccessible as a result. From your explanation this was the reason in
that case.

The problem I am looking at is also probably the same, I don’t have info
regarding whether the system has another (other than NTFS and FAST FAT)
filesystem installed but will get that shortly. If there is something
there that is installed before us, then will add the logic into the
registration of the filesystem that you discussed (maybe getting a
little ahead of myself)…

Anyway thanks for your help.

PS have been nagging my boss about a trip over to the states for one of
your filesystem seminars :wink: (he is also subscribed to this list so maybe
another hint will help)…

Thanks,

Ian Costello

>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com]On Behalf Of Tony Mason
>Sent: Friday, 23 July 2004 10:17 AM
>To: Windows File Systems Devs Interest List
>Subject: RE: [ntfsd] Mount issues with a filesystem…
>
>
>I’m wondering if maybe a different FSD is trying to mount on top of
>your virtual volume BEFORE your FSD gets a chance to do so. I’ve had
>problems in this area before - the I/O Manager will treat certain
>errors as fatal and stop mount processing, so you never get called.
>
>For example, we had a file system that worked on WORM media. If NTFS
>were asked to mount a specific volume (on the WORM drive) it would
>return a STATUS_NONEXISTENT_SECTOR error (or some other clearly
>distinguished error, but that’s the best match I could find this
>evening in ntstatus.h) to the I/O Manager (because the sector it tried

>to read hadn’t been written yet) and our WORM media file system would
>not be called to mount (of course all we saw was that our mount was
>never called). It was volume specific because for a different volume
>it was fine - the region read by NTFS was valid and then NTFS failed
>the mount with a recoverable error (STATUS_UNRECOGNIZED_MEDIA most
>likely). We had to resolve this by adding logic to make sure that
>when a different file system registered, we would unregister and then
>re-register. While not generally applicable (can’t have two such file

>systems together) it solved the problem - and for the customer’s
>environment it was workable because it was controlled.
>
>Personally, I think the I/O Manager is far too conservative in this
>arena (it should allow other FSDs to try, even if there are "I/O

Errors"

>on the drive) but when I last inquired (many years ago) I was told by
>the powers-that-be that they saw no reason to change it.
>
>It would fit your description, but presumes that some other FSD is
>registering AFTER you register, and from the information provided, I
>can’t tell if that is the case or not.
>
>Regards,
>
>Tony
>
>Tony Mason
>Consulting Partner
>OSR Open Systems Resources, Inc.
>http://www.osr.com
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
>Sent: Thursday, July 22, 2004 7:02 PM
>To: ntfsd redirect
>Subject: Re: [ntfsd] Mount issues with a filesystem…
>
>Tony,
>
>Whoops, I neglected to add that call in the pseudo code below. It is
>one of the last things that is done in DriverEntry(). Is there
>anything else that would cause this, i.e. as I create a “virtual disk”

>this may cause problems with the IoManager, particularly the way it is

>created? I don’t actually specify any device characteristics (although

>I thought that was not necessary).
>
>I know that we where getting IOCTL_DISK_CHECK_VERIFY ioctls for the
>virtual disk device, and incorrectly handling them (which I now do)
>via a STATUS_INVALID_PARAMTER return code. Ever since I discovered
>that, I added that handler and put the driver on a system in the field

>the problem went away, but I was not getting the
>IOCTL_DISK_CHECK_VERIFY ioctls??? This makes no sense to me and I
>don’t want to mark this as a fixed when I don’t understand what is

occurring…

>Thanks,
>
>- Ian Costello
>
>
>----- Original Message -----
>From: “Tony Mason”
>>To: “Windows File Systems Devs Interest List”
>>Sent: Friday, July 23, 2004 4:04 AM
>>Subject: RE: [ntfsd] Mount issues with a filesystem…
>>
>>
>>
>>>Where is your call to IoRegisterFileSystem? Without that, you won’t
>>
>>get
>>
>>>a mount call.
>>>
>>>Regards,
>>>
>>>Tony
>>>
>>>
>>>Tony Mason
>>>Consulting Partner
>>>OSR Open Systems Resources, Inc.
>>>http://www.osr.com
>>>
>>>
>>>-----Original Message-----
>>>From: xxxxx@lists.osr.com
>>>[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
>>>Sent: Thursday, July 22, 2004 10:06 AM
>>>To: ntfsd redirect
>>>Subject: [ntfsd] Mount issues with a filesystem…
>>>
>>>Hi All,
>>>
>>>I have gone through the archive looking for a similar problem but
>>
>>could
>>
>>>not find anything. So the problem I am having is with a File System
>>>driver (not a filter based driver), and Windows XP. Note: the
>>
>>filesystem
>>
>>>is currently functional (i.e. the filesystem is mounted without any
>>>issues) on the NT4, W2K, and to some extent on XP platforms.
>>>
>>>The problem is I am not getting the IRP_MN_MOUNT_VOLUME ioctl from
>>>the XP IOManager, and I don’t understand why? I used the OSR Device
>>>Tree application to determine if any of the devices that I have
>>>initialized during driver start up where invalid, but they looked
>
> fine.
>
>>>So a psuedo code rundown of driver startup is:
>>>
>>>DriverEntry()
>>>{
>>>generic initialization…
>>>
>>>IoCreateDevice(); /* creates the FILE_DEVICE_DISK_FILE_SYSTEM device
>>
>>/
>>
>>>IoCreateSymbolicLink(); /
init the user visible name /
>>>
>>>more driver initialization
>>>which includes IoCreateDevice() /
create a virtual FILE_DISK_DEVICE
>
>
>>>device */
>>>
>>>return Status;
>>>}
>>>
>>>Something I should mention (re: FILE_DISK_DEVICE above), although
>>>ashamedly, we also create a virtual disk device which we use to
>>>mount our filesystem(s) on.
>>>This is what I expect to get a mount request for, the Device Tree
>>
>>shows
>>
>>>these devices to be intialized correctly…
>>>
>>>Also I have not been able to reproduce this problem on any of my
>>>test systems locally, unfortunately this problem has, typically,
>>>only shown iteslf on customer sites (and not all of them) running XP
>
> Profesional.
>
>>>So it has been hard debugging this one, so I have been primarily
>>>inspecting the code (which is proprietry so I can’t give too much
>>
>>away,
>>
>>>if anything).
>>>
>>>Thanks,
>>>
>>>Ian Costello
>>>R&D Engineer SGI
>>>
>>>
>>>—
>>>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
>>>
>>>
>>>
>>>—
>>>Questions? First check the IFS FAQ at
>>
>>https://www.osronline.com/article.cfm?id=17
>>
>>>You are currently subscribed to ntfsd as: xxxxx@sgi.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@osr.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@sgi.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@osr.com To unsubscribe
> send a blank email to xxxxx@lists.osr.com
>
>
>

Tony,

Starting to make some progress.

We were able to prove today that it is fastfat that is mounting our
virtual device:

This is the top end of the stack:
cxfs!CxfsRead+0xb4
nt!IopfCallDriver+0x31
Fastfat!FatSingleAsync+0x74
Fastfat!FatCommonRead+0x897
Fastfat!FatFsdRead+0x10e
nt!IopfCallDriver+0x31
nt!IopPageReadInternal+0xf1
nt!IoPageRead+0x19
nt!MiDispatchFault+0x27e
nt!MmAccessFault+0x641
nt!KiTrap0E+0xbc
nt!CcMapData+0xef
Fastfat!FatReadVolumeFile+0x38
Fastfat!FatMountVolume+0x225
Fastfat!FatCommonFileSystemControl+0x47
Fastfat!FatFsdFileSystemControl+0x85
nt!IopfCallDriver+0x31

This is the bottom end of the stack:
b504c774 b512e0ab 8a1731f8 b504c798 0000003e nt!CcMapData+0xef
b504c7a0 b51306b7 899eae80 8a163b60 00000000 Fastfat!FatReadVolumeFile+0x38
b504c92c b51278f8 899eae80 8a2a4668 899ed460 Fastfat!FatMountVolume+0x225
b504c94c b512797c 899eae80 88bd7708 88bd77b8
Fastfat!FatCommonFileSystemControl+0x47
b504c998 804eb3c1 899d2460 88bd7708 88bd77dc
Fastfat!FatFsdFileSystemControl+0x85
b504c9a8 f788b785 8a1752f8 8a3439c8 88bd7708 nt!IopfCallDriver+0x31
b504c9d4 f788b82d 8a343910 8a3439c8 88bd77c0 sr!SrFsControlMount+0x99
b504c9f0 804eb3c1 8a3439c8 88bd7708 88bd7708 sr!SrFsControl+0x49
b504ca00 8056642f 806bb8cc 8a2a4668 00000000 nt!IopfCallDriver+0x31
b504ca50 804f0e36 8a343910 b504cb00 00000000 nt!IopMountVolume+0x1d1
b504ca80 8056731a 8a10d3f0 8a2a4668 b504cbb8 nt!IopCheckVpbMounted+0x5c
b504cb74 805a0f52 8a2a4668 00000000 899d1270 nt!IopParseDevice+0x3ba
b504cbec 8059da82 00000000 b504cc2c 00000040 nt!ObpLookupObjectName+0x53a
b504cc40 8055b4b3 00000000 00000000 00000001 nt!ObOpenObjectByName+0xe8
b504ccbc 8055bc2e 0092fe44 00100001 0092fe58 nt!IopCreateFile+0x407
b504cd04 8055f14b 0092fe44 00100001 0092fe58 nt!IoCreateFile+0x36
b504cd44 805306a4 0092fe44 00100001 0092fe58 nt!NtOpenFile+0x25
b504cd44 7ffe0304 0092fe44 00100001 0092fe58 nt!KiSystemService+0xc9
0092fe00 77f5bb84 77e7875a 0092fe44 00100001
SharedUserData!SystemCallStub+0x4
0092fe04 77e7875a 0092fe44 00100001 0092fe58 ntdll!ZwOpenFile+0xc
0092fe9c 77e72f0b 7ffdcc00 00000000 00000000
kernel32!GetVolumeInformationW+0xe4
0092ff24 0040d25b 0092ff5c 00000000 00000000
kernel32!GetVolumeInformationA+0xf0

And the rest of the stack is our service trying to mount a real
CXFS filesystem.

We believe we are now responding correctly to:
IOCTL_DISK_CHECK_VERIFY
IOCTL_DISK_GET_PARTITION_INFO_EX
IOCTL_DISK_GET_DRIVE_GEOMETRY
IOCTL_STORAGE_GET_HOTPLUG_INFO
which we thought would make FAT believe this is not a FAT filesystem,
but we still never see the IRP_MN_MOUNT_VOLUME request.

You suggested unregistering our filesystem and reregistering it
as a workaround, do you still suggest that as an option here?

Thanks,

David

Tony Mason wrote:

Ian,

Keep in mind, mount ordering is LIFO - so last registered file system is
first called file system. RAW, for example, registers FIRST, and thus
gets called LAST.

If another FSD registers AFTER your FSD, then it will be called BEFORE
you to mount!

Regards,

Tony

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
Sent: Thursday, July 22, 2004 8:44 PM
To: ntfsd redirect
Subject: RE: [ntfsd] Mount issues with a filesystem…

Tony,

Thanks for the prompt reply. This is really interesting as we also had a
similar problem a while back with zip drives, that is we where handling
the mount request ourselves incorrectly and the zip drive was
inaccessible as a result. From your explanation this was the reason in
that case.

The problem I am looking at is also probably the same, I don’t have info
regarding whether the system has another (other than NTFS and FAST FAT)
filesystem installed but will get that shortly. If there is something
there that is installed before us, then will add the logic into the
registration of the filesystem that you discussed (maybe getting a
little ahead of myself)…

Anyway thanks for your help.

PS have been nagging my boss about a trip over to the states for one of
your filesystem seminars :wink: (he is also subscribed to this list so maybe
another hint will help)…

Thanks,

Ian Costello

>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com]On Behalf Of Tony Mason
>Sent: Friday, 23 July 2004 10:17 AM
>To: Windows File Systems Devs Interest List
>Subject: RE: [ntfsd] Mount issues with a filesystem…
>
>
>I’m wondering if maybe a different FSD is trying to mount on top of
>your virtual volume BEFORE your FSD gets a chance to do so. I’ve had
>problems in this area before - the I/O Manager will treat certain
>errors as fatal and stop mount processing, so you never get called.
>
>For example, we had a file system that worked on WORM media. If NTFS
>were asked to mount a specific volume (on the WORM drive) it would
>return a STATUS_NONEXISTENT_SECTOR error (or some other clearly
>distinguished error, but that’s the best match I could find this
>evening in ntstatus.h) to the I/O Manager (because the sector it tried

>to read hadn’t been written yet) and our WORM media file system would
>not be called to mount (of course all we saw was that our mount was
>never called). It was volume specific because for a different volume
>it was fine - the region read by NTFS was valid and then NTFS failed
>the mount with a recoverable error (STATUS_UNRECOGNIZED_MEDIA most
>likely). We had to resolve this by adding logic to make sure that
>when a different file system registered, we would unregister and then
>re-register. While not generally applicable (can’t have two such file

>systems together) it solved the problem - and for the customer’s
>environment it was workable because it was controlled.
>
>Personally, I think the I/O Manager is far too conservative in this
>arena (it should allow other FSDs to try, even if there are "I/O

Errors"

>on the drive) but when I last inquired (many years ago) I was told by
>the powers-that-be that they saw no reason to change it.
>
>It would fit your description, but presumes that some other FSD is
>registering AFTER you register, and from the information provided, I
>can’t tell if that is the case or not.
>
>Regards,
>
>Tony
>
>Tony Mason
>Consulting Partner
>OSR Open Systems Resources, Inc.
>http://www.osr.com
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
>Sent: Thursday, July 22, 2004 7:02 PM
>To: ntfsd redirect
>Subject: Re: [ntfsd] Mount issues with a filesystem…
>
>Tony,
>
>Whoops, I neglected to add that call in the pseudo code below. It is
>one of the last things that is done in DriverEntry(). Is there
>anything else that would cause this, i.e. as I create a “virtual disk”

>this may cause problems with the IoManager, particularly the way it is

>created? I don’t actually specify any device characteristics (although

>I thought that was not necessary).
>
>I know that we where getting IOCTL_DISK_CHECK_VERIFY ioctls for the
>virtual disk device, and incorrectly handling them (which I now do)
>via a STATUS_INVALID_PARAMTER return code. Ever since I discovered
>that, I added that handler and put the driver on a system in the field

>the problem went away, but I was not getting the
>IOCTL_DISK_CHECK_VERIFY ioctls??? This makes no sense to me and I
>don’t want to mark this as a fixed when I don’t understand what is

occurring…

>Thanks,
>
>- Ian Costello
>
>
>----- Original Message -----
>From: “Tony Mason”
>>To: “Windows File Systems Devs Interest List”
>>Sent: Friday, July 23, 2004 4:04 AM
>>Subject: RE: [ntfsd] Mount issues with a filesystem…
>>
>>
>>
>>>Where is your call to IoRegisterFileSystem? Without that, you won’t
>>
>>get
>>
>>>a mount call.
>>>
>>>Regards,
>>>
>>>Tony
>>>
>>>
>>>Tony Mason
>>>Consulting Partner
>>>OSR Open Systems Resources, Inc.
>>>http://www.osr.com
>>>
>>>
>>>-----Original Message-----
>>>From: xxxxx@lists.osr.com
>>>[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
>>>Sent: Thursday, July 22, 2004 10:06 AM
>>>To: ntfsd redirect
>>>Subject: [ntfsd] Mount issues with a filesystem…
>>>
>>>Hi All,
>>>
>>>I have gone through the archive looking for a similar problem but
>>
>>could
>>
>>>not find anything. So the problem I am having is with a File System
>>>driver (not a filter based driver), and Windows XP. Note: the
>>
>>filesystem
>>
>>>is currently functional (i.e. the filesystem is mounted without any
>>>issues) on the NT4, W2K, and to some extent on XP platforms.
>>>
>>>The problem is I am not getting the IRP_MN_MOUNT_VOLUME ioctl from
>>>the XP IOManager, and I don’t understand why? I used the OSR Device
>>>Tree application to determine if any of the devices that I have
>>>initialized during driver start up where invalid, but they looked
>
> fine.
>
>>>So a psuedo code rundown of driver startup is:
>>>
>>>DriverEntry()
>>>{
>>>generic initialization…
>>>
>>>IoCreateDevice(); /* creates the FILE_DEVICE_DISK_FILE_SYSTEM device
>>
>>/
>>
>>>IoCreateSymbolicLink(); /
init the user visible name /
>>>
>>>more driver initialization
>>>which includes IoCreateDevice() /
create a virtual FILE_DISK_DEVICE
>
>
>>>device */
>>>
>>>return Status;
>>>}
>>>
>>>Something I should mention (re: FILE_DISK_DEVICE above), although
>>>ashamedly, we also create a virtual disk device which we use to
>>>mount our filesystem(s) on.
>>>This is what I expect to get a mount request for, the Device Tree
>>
>>shows
>>
>>>these devices to be intialized correctly…
>>>
>>>Also I have not been able to reproduce this problem on any of my
>>>test systems locally, unfortunately this problem has, typically,
>>>only shown iteslf on customer sites (and not all of them) running XP
>
> Profesional.
>
>>>So it has been hard debugging this one, so I have been primarily
>>>inspecting the code (which is proprietry so I can’t give too much
>>
>>away,
>>
>>>if anything).
>>>
>>>Thanks,
>>>
>>>Ian Costello
>>>R&D Engineer SGI