Issues with driver upgrade

We have two models of our PCI-e based storage adapter, each with 2 PCI functions. Model A is supported by driver v1.0 (storport miniport) and is inbox. Model B (different PCI device id) has driver v2.0.
For installing the Windows Server 2012 on a disk seen through model B, v2.0 needs to be provided via the ?Driver Load? option as part of the Windows setup. However, in this case we see that after the upgrade to v2.0, only PCI function 1 is initialized. If the ?Driver Load? is performed the second time, both function 0 and function 1 are initialized by thev v2.0 driver.

Observations from debugging:
a. As part of device restart for function 0 after providing v2.0 driver, v1.0 was attempted to be unloaded, which did not succeed. Setupapi.dev.log indicates that the driver unload required a reboot. I suspect this is because there were no devices being managed by v1.0 driver and hence could not be unloaded.
c. Subsequently, FindAdapter interface of v1.0 driver was invoked for model B?s function 0. The v1.0 driver fails this as it does not identify the model B. This results in v1.0 being unloaded from memory completely.
d. When the setup tries to restart function 1, v2.0 is loaded and its FindAdapter is invoked, which initializes function 1.

Questions:
a. MSDN states that the DriverUnload routine is invoked when the driver is being replaced or when all the devices it manages are being removed. However, I see that the unload routine is only invoked when the last device managed by a driver is removed. Is this the expected behaviour? If yes, how do we unload drivers which are loaded into memory but do not currently manage any devices?
b. When v1.0 is upgraded to v2.0, why is the FindAdapter of v1.0 driver being invoked for model B?s function 0? If the unload of v1.0 was not successful, shouldn?t the upgrade fail?
c. Is there a way to get around this situation (other than changing the driver name)?

xxxxx@hotmail.com wrote:

Observations from debugging:
a. As part of device restart for function 0 after providing v2.0 driver, v1.0 was attempted to be unloaded, which did not succeed. Setupapi.dev.log indicates that the driver unload required a reboot. I suspect this is because there were no devices being managed by v1.0 driver and hence could not be unloaded.

If there were no devices, then why is v1.0 still in memory?

Questions:
a. MSDN states that the DriverUnload routine is invoked when the driver is being replaced or when all the devices it manages are being removed. However, I see that the unload routine is only invoked when the last device managed by a driver is removed. Is this the expected behaviour? If yes, how do we unload drivers which are loaded into memory but do not currently manage any devices?

I don’t see the difference between your two statements. A PnP driver is
unloaded when its last device is removed. Thus, for a PnP driver, you
cannot have a driver loaded in memory that does not manage any devices.
If any application has an open handle to the device, the device cannot
be removed, and hence the driver cannot be unloaded.

There is kind of a tricky situation you can get into with multiple
devices. Say I have two devices using driver D1. I now copy a new
driver D2 into place and use “devcon restart” to restart the devices.
In that case, both devices will still be using driver D1. The reason is
timing: when devcon restarts the first device, it can’t unload D1
because it has another active device. So, when the first device comes
back up, it uses the old driver. The solution to that is to use “devcon
disable” to disable both devices, and then “devcon enable” to re-enable
both devices.

b. When v1.0 is upgraded to v2.0, why is the FindAdapter of v1.0 driver being invoked for model B?s function 0? If the unload of v1.0 was not successful, shouldn?t the upgrade fail?

Not necessarily. You can successfully install v2.0 while v1.0 is still
being used.

c. Is there a way to get around this situation (other than changing the driver name)?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks Tim.

This is a boot start driver. As such, the DriverEntry of v1.0 is invoked as part of system boot.