Hello everyone,
I am developing the SCSI Miniport driver and
storage class lower filter driver for SAN(Storage Area
Network)kind of work.I got a problem in this while adding
the filter driver

1. In this adding the filter driver for each volume
(PDO) which is created in the SCSI Miniport driver.
We are using SetupDI API's For inserting the
filter driver in this device stack.
2. For inserting the filter driver:
i)To add/remove filter drivers:
a) using SetupDiGetClassDevs to get a list
of devices of the given interface class.
b) using SetupDiEnumDeviceInfo to
enumerate the items in that list and obtain a
SP_DEVINFO_DATA
c) using SetupDiGetDeviceRegistryProperty
to get the list of filter drivers add/remove items in the
filter list
d) using SetupDiSetDeviceRegistryProperty
to put the list back in place

ii) While adding the filter we stop and start the
devices under the class.
a)using SetupDiCallClassInstaller with
DIF_PROPERTYCHANGE and DICS_STOP to stop the device.
b)using SetupDiCallClassInstaller
with DIF_PROPERTYCHANGE and DICS_START to restart the
device.

While restarting the device this will
internally call the configuration managers
CM_Query_And_Remove_Subtree ()
API to unload the filter driver which is
already applied. By calling CM_Reenumerate_DevNode on the
_parent_ (to reload the driver).While unloading the driver
this API will issue the IRP_MN_REMOVE_DEVICE,so the driver
will try to delete the filter device object which is
already applied to the created disks.This may be the
reason to ask for the system reboot.
So I didn't delete the device
object while removing the device and deleted the symbolic
link name & detached the deviceobject from the current
stack.After this also it is asking for reboot.

While testing this there are some
warrnings in the evenviewer that came from Removable
Storage Manager,the event ID's are 134 & 135 and the debug
viewer shows the message "***Device Object Query Vetoed
Type = 6 " from the debug machine.

Thanks in Advance,
Subburaj.R

Sorry, but updates in storage stack do require a reboot, and this is
by design in Windows.

So, it is better to not do some hackery like "not removing a device in
MN_REMOVE_DEVICE path".

Max

Hi Max,
Thanks for the valuable reply. But i have a doubt in
this.If it is a dynamic disk then how windows can handle
the updates in storage stack.

Thanks & Regards,
Subburaj.R

Any update in SystemRoot stack require a reboot.
Any update in the storage stack with a pagefile on it - again require
a reboot.
Is it not enough to forget the idea of reboot-less driver replacement?

Also IIRC this is a PnP way of behaviour. If you want to disable the
device - any device, or to update its driver (which is
disable-update-enable), and if MN_REMOVE_DEVICE or
MN_QUERY_REMOVE_DEVICE is vetoed by somebody - then PnP suggests you
to reboot.

Removal in the storage stack can be vetoed by lots of factors,
including the pagefile or just some currently open files on the
volume.

I personally think that trying to bypass this behaviour is next to
impossible, so, it is better to just live with reboot requirement on
some driver updates. At least you will have a stable product, while
hacks to bypass it can decrease the product stability.

Dynamic disk is not storage stack, it is a bit upper.

Max