Hello everyone,
I’m developing a virtual volume [think of RamDisk, that’s close enough in
regard of my problem], and the driver
is interacting with the Mount Manager to add and remove drive letters or
mount points.
I nearly missed one problem that occurs while cleaning up (that is, removing
the virtual volume):
The Mount Manager is adding two links but later removing only one of them.
[What I noticed is that
after a driver unload, it would not re-load afterwards. It took me a while
to figure out that it’s this extra
link that causes this. Kinda annoying while debugging].
To give an example what happens while mounting a virtual disk with one
partition as drive “L:”
(…‘mount’ process…)
IOCTL_MOUNTDEV_LINK_CREATED for “\DosDevices\L:”
IOCTL_MOUNTDEV_LINK_CREATED for
“??\Volume{e3058cac-b8d5-11da-b077-000f1f87611e}”
Later then,
(…‘dismount process’… L: is locked, file system is told to dismount)
IOCTL_MOUNTDEV_LINK_DELETED for “\DosDevices\L:”
(…done…)
The guid-style link stays active.
Now I wonder, how do I tell the Mount Manager that it’s supposed to delete
this link as well? I’ve tried
various DeleteVolumeMountPoint() calls from user land to get rid of it [all
failed], and I don’t dare to just
delete it (I assume the Mount Manager would be slightly unhappy). I’m stuck
here, I just hope I’m only
missing something obvious and that it’s not a fundamental idiocy in my
source…
So, what’s the correct way to get rid of this link?
Cheers,
Michael B.
> Now I wonder, how do I tell the Mount Manager that it’s supposed to delete
this link as well?
Revoke the MOUNTDEV_MOUNTED_DEVICE_GUID interface.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Hello,
> Now I wonder, how do I tell the Mount Manager that it’s supposed
> to delete this link as well?
Revoke the MOUNTDEV_MOUNTED_DEVICE_GUID interface.
Thanks for your response. Looks simple enough, but is a sure cause
to heavy headaches…
I trigger the mount point manager’s interest in my driver with
IOCTL_MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION.
I’ve found no MOUNTMGR_VOLUME_DEPARTURE though… Is
there any other way to tell the system that the device is gone?
So, in order to revoke that interface I assume I first have to register
it by using IoRegisterDeviceInterface(). Which I didn’t because I have
no PDO. A PDO doesn’t make much sense in my case. Also, PnP support in
my driver is rudimentary, basically I only handle TargetDeviceRelations
and there I return that there’s no related device, which seems to keep
the system happy.
At some point I’ve tried to use IoReportDetectedDevice() to report
my own device and get a real PDO from the system. This has lead to
some bizarre results though (the system remembered the devices after
a reboot and got confused that they were all gone and no driver felt
responsible for that).
If there is no other way then I guess I can only do what
someone on this List suggested a long time ago – create a filter
driver that implements its own mount points… …or discard the
fancy feature to mount a number of virtual partitions on empty
NTFS directories. (It sounded to be such a nice and simple
feature in the first place…)
Cheers,
Michael B. (still hoping for a miracle)
> At some point I’ve tried to use IoReportDetectedDevice() to report
my own device and get a real PDO from the system. This has lead to
some bizarre results though (the system remembered the devices after
a reboot and got confused that they were all gone and no driver felt
responsible for that).
Then write a bus driver to have real proper PDOs. Proper interacting with
MountMgr requires a PDO I think.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com