Driver unload and wmi

NTDEV
1

After I added a wmi interface to my driver
it fails to unload. I do have the following
line in my PNP_REMOVE routine:

IoWMIRegistrationControl(pDevExt->pSelf,
WMIREG_ACTION_DEREGISTER);

What else do I need to look for?

thanks,

m navab

.

2

xxxxx@yahoo.com wrote:

After I added a wmi interface to my driver
it fails to unload. I do have the following
line in my PNP_REMOVE routine:

IoWMIRegistrationControl(pDevExt->pSelf,
WMIREG_ACTION_DEREGISTER);

What else do I need to look for?

Are you possibly *also* using an IO_REMOVE_LOCK and forgetting to call
IoReleaseRemoveLock in a dispatch routine?

Note that you do not need to use the remove lock at all for WMI IRPs.
The WMI subsystem takes a reference to your device object when you make
the WMIREG_ACTION_REGISTER call. When you later deregister, it waits
until all outstanding WMI requests drain through, and then it releases
that extra reference. There is therefore no possibility that you’ll pass
a WMI IRP down the stack to a non-existent driver, which is what the
remove lock aims to avoid.

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com

3

Walter,

Thanks for the tip, but remove lock does not seem to be
an issue. This is a intermittent problem that seems to depend
on what my clients do.

So, I think a broader and more interesting question is
“how can drivers find out about the clients that keep
them from unloading?”

regards,

m navab

4

xxxxx@yahoo.com wrote:

So, I think a broader and more interesting question is
“how can drivers find out about the clients that keep
them from unloading?”

They can’t, and don’t generally need to. Nothing awful happens just
because someone keeps a handle open that keeps you from unloading. When
you said you were unregistering in your RemoveDevice handler, I assumed
you were *getting* there, and that would not happen if a handle was
still open. So perhaps you can explain your problem again with a bit
more detail?

–
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com

5

From what I’ve seen, getting to PNP_REMOVE is not the end
of the story. You can even get called at the UNLOAD routine,
do everything successfully, and still not get unloaded, because
some thread still has a reference to the driver (device object).

!drvobj xxxxxxxx no longer shows the driver object.
!devobj xxxxxxxx no longer shows the device objects.
However,
lm still shows the module loaded.