>
> The driver in question is an NDIS driver
This changes everything - NDIS miniport driver is not supposed to be
un-
unloadable, which automatically implies that the answer to your
original
question is supposed to be negative by definition. Furthermore, it is
not supposed to communicate with the OS by any means other than NDIS
library -
IIRC, your NIC’s corresponding DEVICE_OBJECT that is known to the IO
Manager
is created by NDIS library using NDIS.SYS’s, rather than your
driver’s,
DRIVER_OBJECT. If you want to access your module from some component
other
than NDIS you have to create a standalone DO with
NdisMRegisterDevice()…
Hmmmm… well in that case maybe I have misunderstood what is going on
then.
The ndis driver gets some information from my bus driver. In particular,
there is no hardware interrupt, so it provides a callback routine to the
bus driver so the bus driver can tell it when there is work for it to do
(much as I expect a USB based ndis driver would, as each USB device also
doesn’t get its own interrupt).
I recently changed the api of the bus<->fdo interface, and it’s not
backwards compatible. The new fdo version will detect that it is
connected to an old bus driver version and fail to load, but it still
leaves you with no network when you upgrade until you reboot.
So before upgrade I have the following:
xenpci (v1) assigned to a virtual pci device
xenvbd (v1) scsiport driver whos fdo is enumerated by xenpci
xennet (v1) ndis miniport driver whos fdo is enumerated by xenpci
(possibly more xennet and xenvbd instances)
When I try and upgrade, xenpci cannot be upgraded on-the-fly because it
is in the paging path, ditto for xenvbd. Windows tries to upgrade xennet
but can’t load the new version and so just leaves the system with no
network driver. Upgrades where the api hasn’t changed are fine, windows
stops the v1 instance, loads the v2 driver, and starts a v2 instance.
Now I had assumed that what happened was that all the xennet devices
were being stopped, and then the xennet(v1) driver itself was unloaded
from the system, and then the xennet(v2) driver was loaded in its place.
But based on what you are saying, both xennet(v1) and xennet(v2) drivers
are in memory at the same time with the (v1) driver not responsible for
any devices anymore.
What I was hoping was that windows would stop my network interfaces, try
to unload the driver but fail (because I had prevented unload somehow
which apparently isn’t possible) and then just re-start the interfaces
with the old driver.
Another way to solve this would be for my driver to be able to tell the
difference between an ndis miniport device being stopped because it was
about to be upgraded (in which case I’d not allow it to stop if I could)
or the device being stopped because it was being ‘unplugged’ from the
system or simply disabled (in which case I’d allow it). There is no such
way to tell the difference though, and given that my requirement is a
bit of a corner case I didn’t really expect that there would be.
Thanks
James
