I have a volume filter driver layering on top of every volume in the system.
On the first write request to the volumes, I am trying to query for the
volume’s GUID through IOCTL_MOUNTMGR_QUERY_POINTS ioctl (by supplying the
device name \Device\HarddiskVolumeX). I see that the ioctl always completes
with buffer overrun status irrespective of the buffer size. Also, the output
buffer does not contain the size required for me to retry the request with
the appropriate buffer size.
When I modify the driver to issue the query points ioctl upon an application
request (triggered through a private ioctl), the query points ioctl works as
documented. I have double checked that there is absolutely no difference in
the way the ioctl is set up in both these secnarios.
From my understanding it looks like the mount manager is not completely
initialized when the ioctl is issued in the context of the first write
request and hence returning the error (of course, I did not understand the
concept of returning buffer overflow in such cases). Should my driver wait
for any particular state of the mount manager before issuing the ioctl? If
yes, how do I figure out the status of the mount manager? I could not find
much documentation around this.
P.S. One observation I had is that the ioctl succeeds (in the context of the
first write request) if there are no parameters specified as part of the
input. The mount manager then returns all the available mount point details
at that point in time.
Regards,
Girish.
Process IOCTL_MOUNTDEV_LINK_CREATED in your filter driver
- Get volume unique id anytime after PNP start has finished on the
stack below your device.
- Use that unique id to query mount point manager to get the guid.
How are you getting \Device\HarddiskVolumeX name for the device. ?
Harish
-----Original Message-----
From: Girish Aithal [mailto:xxxxx@hotmail.com]
Sent: Tuesday, September 22, 2009 10:41 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Mount manager query
I have a volume filter driver layering on top of every volume in the
system.
On the first write request to the volumes, I am trying to query for the
volume’s GUID through IOCTL_MOUNTMGR_QUERY_POINTS ioctl (by supplying
the
device name \Device\HarddiskVolumeX). I see that the ioctl always
completes
with buffer overrun status irrespective of the buffer size. Also, the
output
buffer does not contain the size required for me to retry the request
with
the appropriate buffer size.
When I modify the driver to issue the query points ioctl upon an
application
request (triggered through a private ioctl), the query points ioctl
works as
documented. I have double checked that there is absolutely no difference
in
the way the ioctl is set up in both these secnarios.
From my understanding it looks like the mount manager is not completely
initialized when the ioctl is issued in the context of the first write
request and hence returning the error (of course, I did not understand
the
concept of returning buffer overflow in such cases). Should my driver
wait
for any particular state of the mount manager before issuing the ioctl?
If
yes, how do I figure out the status of the mount manager? I could not
find
much documentation around this.
P.S. One observation I had is that the ioctl succeeds (in the context of
the
first write request) if there are no parameters specified as part of the
input. The mount manager then returns all the available mount point
details
at that point in time.
Regards,
Girish.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars 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
Could you please help me understand what special processing needs to be done
for this IOCTL? At this point in time, my filter driver just passes it down
to the stack and does not do any thing special.
wrote in message news:xxxxx@ntdev…
> Process IOCTL_MOUNTDEV_LINK_CREATED in your filter driver
>
The sequence of steps in my filter driver are as follows:
- Create and attach the filter device object to the volume device stack as
part of the AddDevice routine.
- After the IRP_MJ_START has been completed by the drivers below my filter
driver, issue IOCTL_MOUNTDEV_QUERY_DEVICE_NAME and store the device name as
part of the device extension.
- When IRP_MJ_WRITE is issued for the first time, issue the
IOCTL_MOUNTMGR_QUERY_POINTS to \Device\MountManager. The input to this ioctl
is the MOUNTMGR_MOUNT_POINT structure containing the device name obtained in
step 2.
Regards,
Girish.
“Arora, Harish” wrote in message
news:xxxxx@ntdev…
1. Get volume unique id anytime after PNP start has finished on the
stack below your device.
2. Use that unique id to query mount point manager to get the guid.
How are you getting \Device\HarddiskVolumeX name for the device. ?
Harish
-----Original Message-----
From: Girish Aithal [mailto:xxxxx@hotmail.com]
Sent: Tuesday, September 22, 2009 10:41 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Mount manager query
I have a volume filter driver layering on top of every volume in the
system.
On the first write request to the volumes, I am trying to query for the
volume’s GUID through IOCTL_MOUNTMGR_QUERY_POINTS ioctl (by supplying
the
device name \Device\HarddiskVolumeX). I see that the ioctl always
completes
with buffer overrun status irrespective of the buffer size. Also, the
output
buffer does not contain the size required for me to retry the request
with
the appropriate buffer size.
When I modify the driver to issue the query points ioctl upon an
application
request (triggered through a private ioctl), the query points ioctl
works as
documented. I have double checked that there is absolutely no difference
in
the way the ioctl is set up in both these secnarios.
>From my understanding it looks like the mount manager is not completely
initialized when the ioctl is issued in the context of the first write
request and hence returning the error (of course, I did not understand
the
concept of returning buffer overflow in such cases). Should my driver
wait
for any particular state of the mount manager before issuing the ioctl?
If
yes, how do I figure out the status of the mount manager? I could not
find
much documentation around this.
P.S. One observation I had is that the ioctl succeeds (in the context of
the
first write request) if there are no parameters specified as part of the
input. The mount manager then returns all the available mount point
details
at that point in time.
Regards,
Girish.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars 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
The mount manager uses this IOCTL_MOUNTDEV_LINK_CREATEDto alert the client driver that a persistent name has been assigned to its volume.
You can typecast Irp->AssociatedIrp.SystemBuffer to PMOUNTDEV_NAME and check for name