Control Device Inhibits Unload

NTDEV
1

I have a KMDF filter driver based on the toaster/filter sample. It’s a
lower filter to usbaudio.sys for a couple of video cameras. I use the
control device object to communicate with the device through a control
panel applet. The applet opens an instance of the control device, and
keeps it open until the applet dialog closes.

While chasing down another problem today, I ran the following scenario:

  1. Plug in device. Driver loads, creates control device, all is happy.
  2. Start control panel, which opens handle to control device.
  3. Surprise-remove the device.

At this point, the filter device closes up shop properly. The driver
runs WdfObjectDelete on the control device, thereby releasing its
reference. Now:

  1. Stop control panel app, thereby closing the control device handle.
  2. Re-plug the device.

What happens here is functionally correct: a new filter device is
created, it creates a new control device, and that control device can be
used. However, during that entire unplug/replug, the filter driver
never got unloaded. I expected that closing the control panel app,
which closes the control device handle, would release the last driver
reference and allow the driver to unload. That does not happen. If I
had left the control panel app up during the replug, I would expect
this, but when the last open handle is closed, I expected it to unload.

If I do another surprise removal here, without involving control panel,
the driver does unload normally, so it’s not like there is some dangling
instance somewhere.

This is quite repeatable. I’d appreciate any thoughts, besides “don’t
do that”.

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

2

So it’s not just the fact that you had a control device, it’s either that you opened the control device or that you had it opened after the filter device object was removed?

Does the control panel do anything with the control device besides open a handle to it?

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, April 04, 2008 6:46 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Control Device Inhibits Unload

I have a KMDF filter driver based on the toaster/filter sample. It’s a
lower filter to usbaudio.sys for a couple of video cameras. I use the
control device object to communicate with the device through a control
panel applet. The applet opens an instance of the control device, and
keeps it open until the applet dialog closes.

While chasing down another problem today, I ran the following scenario:

  1. Plug in device. Driver loads, creates control device, all is happy.
  2. Start control panel, which opens handle to control device.
  3. Surprise-remove the device.

At this point, the filter device closes up shop properly. The driver
runs WdfObjectDelete on the control device, thereby releasing its
reference. Now:

  1. Stop control panel app, thereby closing the control device handle.
  2. Re-plug the device.

What happens here is functionally correct: a new filter device is
created, it creates a new control device, and that control device can be
used. However, during that entire unplug/replug, the filter driver
never got unloaded. I expected that closing the control panel app,
which closes the control device handle, would release the last driver
reference and allow the driver to unload. That does not happen. If I
had left the control panel app up during the replug, I would expect
this, but when the last open handle is closed, I expected it to unload.

If I do another surprise removal here, without involving control panel,
the driver does unload normally, so it’s not like there is some dangling
instance somewhere.

This is quite repeatable. I’d appreciate any thoughts, besides “don’t
do that”.

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Tim, can you register a EvtFileClose/Cleanup and verify that the handle is actually being closed after you s.r. with the UI open?

Thx!
d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Friday, April 04, 2008 6:54 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Control Device Inhibits Unload

So it’s not just the fact that you had a control device, it’s either that you opened the control device or that you had it opened after the filter device object was removed?

Does the control panel do anything with the control device besides open a handle to it?

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, April 04, 2008 6:46 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Control Device Inhibits Unload

I have a KMDF filter driver based on the toaster/filter sample. It’s a
lower filter to usbaudio.sys for a couple of video cameras. I use the
control device object to communicate with the device through a control
panel applet. The applet opens an instance of the control device, and
keeps it open until the applet dialog closes.

While chasing down another problem today, I ran the following scenario:

  1. Plug in device. Driver loads, creates control device, all is happy.
  2. Start control panel, which opens handle to control device.
  3. Surprise-remove the device.

At this point, the filter device closes up shop properly. The driver
runs WdfObjectDelete on the control device, thereby releasing its
reference. Now:

  1. Stop control panel app, thereby closing the control device handle.
  2. Re-plug the device.

What happens here is functionally correct: a new filter device is
created, it creates a new control device, and that control device can be
used. However, during that entire unplug/replug, the filter driver
never got unloaded. I expected that closing the control panel app,
which closes the control device handle, would release the last driver
reference and allow the driver to unload. That does not happen. If I
had left the control panel app up during the replug, I would expect
this, but when the last open handle is closed, I expected it to unload.

If I do another surprise removal here, without involving control panel,
the driver does unload normally, so it’s not like there is some dangling
instance somewhere.

This is quite repeatable. I’d appreciate any thoughts, besides “don’t
do that”.

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

Tim,

I have seen this exact behavior in NDIS IM drivers with control devices.
The Control Device does indeed close and go away. However, there is nothing
at that point triggering PnP to check the count of devices in the driver
object and to request the driver shutdown. The next time you plug-in a
device and remove it, however, with the Control Device closed, you will see
the unload occur.

This knawed at me a long time until I finally figured out that the dynamic
load/unload of the driver is a policy implemented by PnP. The control
device is not part of a PnP stack and so if it is the last DO to go, its
departure is unknown to PnP. If (as is the normal case surely for your
driver) the control device departs before the PnP DO (FiDOs) depart, then,
PnP never sees the CDO’s ‘reference’ on the driver object as being an issue
for deciding to unload the driver.

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Saturday, April 05, 2008 12:37 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Control Device Inhibits Unload

Tim, can you register a EvtFileClose/Cleanup and verify that the handle is
actually being closed after you s.r. with the UI open?

Thx!
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Friday, April 04, 2008 6:54 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Control Device Inhibits Unload

So it’s not just the fact that you had a control device, it’s either that
you opened the control device or that you had it opened after the filter
device object was removed?

Does the control panel do anything with the control device besides open a
handle to it?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, April 04, 2008 6:46 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Control Device Inhibits Unload

I have a KMDF filter driver based on the toaster/filter sample. It’s a
lower filter to usbaudio.sys for a couple of video cameras. I use the
control device object to communicate with the device through a control
panel applet. The applet opens an instance of the control device, and
keeps it open until the applet dialog closes.

While chasing down another problem today, I ran the following scenario:

  1. Plug in device. Driver loads, creates control device, all is happy.
  2. Start control panel, which opens handle to control device.
  3. Surprise-remove the device.

At this point, the filter device closes up shop properly. The driver
runs WdfObjectDelete on the control device, thereby releasing its
reference. Now:

  1. Stop control panel app, thereby closing the control device handle.
  2. Re-plug the device.

What happens here is functionally correct: a new filter device is
created, it creates a new control device, and that control device can be
used. However, during that entire unplug/replug, the filter driver
never got unloaded. I expected that closing the control panel app,
which closes the control device handle, would release the last driver
reference and allow the driver to unload. That does not happen. If I
had left the control panel app up during the replug, I would expect
this, but when the last open handle is closed, I expected it to unload.

If I do another surprise removal here, without involving control panel,
the driver does unload normally, so it’s not like there is some dangling
instance somewhere.

This is quite repeatable. I’d appreciate any thoughts, besides “don’t
do that”.

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

Tim Roberts wrote:

David is probably right since I since I haven’t a clue as usual.

  1. Stop control panel app, thereby closing the control device handle.
  2. Re-plug the device.

What happens here is functionally correct: a new filter device is
created, it creates a new control device, and that control device can
be used. However, during that entire unplug/replug, the filter driver
never got unloaded. I expected that closing the control panel app,
which closes the control device handle, would release the last driver
reference and allow the driver to unload. That does not happen. If I
had left the control panel app up during the replug, I would expect
this, but when the last open handle is closed, I expected it to unload.
One thing to think about here is a .cpl is just a dll. Explorer does
hold dlls in memory unless specified via the reg key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AlwaysUnloadDLL.
I
don’t know if there is any relevance to this, but your above statement,
“If I had left the control panel app up during the replug, I would
expect this”,
seems it could possibly indicate this … ?

If I do another surprise removal here, without involving control
panel, the driver does unload normally, so it’s not like there is some
dangling instance somewhere.
Without the control panel, which IS Explorer (and all its interesting
behavior, including this dll caching feature). Perhaps this caching
feature is what your
currently ‘appreciating’.

Just guessing and good luck (not that you need it),

Matt

This is quite repeatable. I’d appreciate any thoughts, besides “don’t
do that”.

6

I too have had this problem in the past, and I never found any easy way to
get Windows to actually unload a driver if the control object is the last
object to be closed. As David said, it is due to the control device not
being a PnP device. Only removal of a PnP device triggers the PnP device
manager to check a driver it owns for unload. Its a catch-22: you can’t
call DriverUnload manually the way a non-PnP device would normally unload
because the PnP manager owns the driver, but the PnP manager won’t trigger
an unload itself because it only performs the unload check for PnP devices.

I personally regard this as a fault in the Windows driver architecture and
feel there should be some way to signal the PnP manager manually to check
for a driver unload in the event that your control device realizes that it
is the last device being shut down. Whether the lack of ability to do this
is related to security concerns, performance issues, or simple oversight I
don’t know. It is an issue mostly related to only filter drivers, since
they are the ones that have both PnP and non-PnP devices. Most other
drivers are configured with one or the other. Overall, the support for
filter drivers seems tacked-on and not fully adequate. There can also be
difficulties in satisfactorily installing or uninstalling filter drivers
with INF files in certain configurations, like for third-party filters for
devices where the underlying device is not installed at the same time as the
filter.

– Matthew Carter

“David R. Cattley” wrote in message news:xxxxx@ntdev…
> Tim,

> This knawed at me a long time until I finally figured out that the dynamic
> load/unload of the driver is a policy implemented by PnP. The control
> device is not part of a PnP stack and so if it is the last DO to go, its
> departure is unknown to PnP. If (as is the normal case surely for your
> driver) the control device departs before the PnP DO (FiDOs) depart, then,
> PnP never sees the CDO’s ‘reference’ on the driver object as being an
> issue
> for deciding to unload the driver.

7

Are you deleting the control device when the last FDO is removed even when there are open handles against the CDO? Or are you delaying the delete until the handle has been closed?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Saturday, April 05, 2008 5:47 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Control Device Inhibits Unload

Tim,

I have seen this exact behavior in NDIS IM drivers with control devices.
The Control Device does indeed close and go away. However, there is nothing
at that point triggering PnP to check the count of devices in the driver
object and to request the driver shutdown. The next time you plug-in a
device and remove it, however, with the Control Device closed, you will see
the unload occur.

This knawed at me a long time until I finally figured out that the dynamic
load/unload of the driver is a policy implemented by PnP. The control
device is not part of a PnP stack and so if it is the last DO to go, its
departure is unknown to PnP. If (as is the normal case surely for your
driver) the control device departs before the PnP DO (FiDOs) depart, then,
PnP never sees the CDO’s ‘reference’ on the driver object as being an issue
for deciding to unload the driver.

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Saturday, April 05, 2008 12:37 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Control Device Inhibits Unload

Tim, can you register a EvtFileClose/Cleanup and verify that the handle is
actually being closed after you s.r. with the UI open?

Thx!
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Friday, April 04, 2008 6:54 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Control Device Inhibits Unload

So it’s not just the fact that you had a control device, it’s either that
you opened the control device or that you had it opened after the filter
device object was removed?

Does the control panel do anything with the control device besides open a
handle to it?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, April 04, 2008 6:46 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Control Device Inhibits Unload

I have a KMDF filter driver based on the toaster/filter sample. It’s a
lower filter to usbaudio.sys for a couple of video cameras. I use the
control device object to communicate with the device through a control
panel applet. The applet opens an instance of the control device, and
keeps it open until the applet dialog closes.

While chasing down another problem today, I ran the following scenario:

  1. Plug in device. Driver loads, creates control device, all is happy.
  2. Start control panel, which opens handle to control device.
  3. Surprise-remove the device.

At this point, the filter device closes up shop properly. The driver
runs WdfObjectDelete on the control device, thereby releasing its
reference. Now:

  1. Stop control panel app, thereby closing the control device handle.
  2. Re-plug the device.

What happens here is functionally correct: a new filter device is
created, it creates a new control device, and that control device can be
used. However, during that entire unplug/replug, the filter driver
never got unloaded. I expected that closing the control panel app,
which closes the control device handle, would release the last driver
reference and allow the driver to unload. That does not happen. If I
had left the control panel app up during the replug, I would expect
this, but when the last open handle is closed, I expected it to unload.

If I do another surprise removal here, without involving control panel,
the driver does unload normally, so it’s not like there is some dangling
instance somewhere.

This is quite repeatable. I’d appreciate any thoughts, besides “don’t
do that”.

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

> I personally regard this as a fault in the Windows driver architecture and feel there should be some way to > signal the PnP manager manually to check for a driver unload in the event that your

control device realizes that it is the last device being shut down.

Yes, but why do you think PnP should be bothered about non-PnP devices??? In our particular case, there is one-to-one relationship between PnP device and control one, but this relationship is defined strictly
by the logic of a driver, so it could be totally different, which is completely out of PnP’s scope. Once the only one who knows the logical relationship between devices that a driver creates is a driver itself, it makes a perfect sense to d make it responsible for tracking these devices…

It is an issue mostly related to only filter drivers, since they are the ones that have both PnP and
non-PnP devices.

Not necessarily - any driver, regardless of its PnP role (if any) is able to create any number of devices that it wishes. It is defined solely by the logic of a given driver, as well as of drivers that interact with it. For example, DISK.SYS creates FDO for every disk plus standalone device that does not end up on any stack for every partition of every disk. …

Anton Bassov

9

Exactly. And the problem that Tim (and others) have noted has existed since Windows 2000. I’ve certainly seen it as well.

One of the major architectural features of Windows has been that the DRIVER is responsible for determining exactly what device objects are created and what they represent. This is a very powerful feature, and one that’s very different from other operating systems.

Peter
OSR

10

xxxxx@osr.com wrote:

This thread is rather interesting to me. I just don’t have the knowledge
to understand where everyone is
coming from apparently, but how does all of this relate precisely to
Tim’s problem?

From my reading of his post, everything is just fine until his user
mode control panel app is run. How is a
user mode application screwing the pnp manager? If the problem is with
his control panel application opening
the driver’s cdo, isn’t that the object manager that isn’t handling
handles/objects correctly? He stated that
if he never ran the .cpl, then the driver would unload successfully. So
therefor, why should his driver or anything
else at the kernel level be blamed for the creation/destruction of the
cdo when this problem only arises when
user mode code is involved?

To quote Tim, "If I do another surprise removal here, without involving
control panel, the driver does unload
normally, so it’s not like there is some dangling instance somewhere. ".

I suppose I didn’t understand the scenario correctly, where and what
should I read to understand what
is going on here?

Matt

Exactly. And the problem that Tim (and others) have noted has existed since Windows 2000. I’ve certainly seen it as well.

One of the major architectural features of Windows has been that the DRIVER is responsible for determining exactly what device objects are created and what they represent. This is a very powerful feature, and one that’s very different from other operating systems.

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

11

Peter Wieland wrote:

So it’s not just the fact that you had a control device, it’s either that you opened the control device or that you had it opened after the filter device object was removed?

Yes, the trigger is that there was an open handle to the control device
upon surprise removal. I was trying to guess how the framework was
handling this. All I do is WdfObjectDelete, but the framework can’t
really do IoDeleteDevice until that last handle closes. Is the
framework keeping a reference count on the control device?

Does the control panel do anything with the control device besides open a handle to it?\

It sends a couple of rather trivial ioctls that are completed
immediately. No pending requests.

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

12

Matt wrote:

Tim Roberts wrote:

> What happens here is functionally correct: a new filter device is
> created, it creates a new control device, and that control device can
> be used. However, during that entire unplug/replug, the filter
> driver never got unloaded. I expected that closing the control panel
> app, which closes the control device handle, would release the last
> driver reference and allow the driver to unload. That does not
> happen. If I had left the control panel app up during the replug, I
> would expect this, but when the last open handle is closed, I
> expected it to unload.
One thing to think about here is a .cpl is just a dll. Explorer does
hold dlls in memory unless specified via the reg key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AlwaysUnloadDLL.
I
don’t know if there is any relevance to this, but your above
statement, “If I had left the control panel app up during the replug,
I would expect this”, seems it could possibly indicate this … ?

No, the driver handle is closed during the dialog window shutdown, not
during the DLL unload. I know this is happening as expected.

And actually, it isn’t Explorer that loads control panel applets.
Instead, Explorer launches a separate rundll32 process, and rundll32.exe
loads the DLL, so when the window closes, the process terminates.

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

13

Doron Holan wrote:

Are you deleting the control device when the last FDO is removed even when there are open handles against the CDO? Or are you delaying the delete until the handle has been closed?

My code, like approximately 75% of the KMDF filter drivers in existence,
was based on the kmdf/toaster/filter sample in the WDK, That sample
deletes the control device during EvtDeviceContextCleanup.

If Dave’s PnP theory is really correct, it wouldn’t make any difference
if I enabled file object processing on the control device and deferred
the deletion to the EvtFileCleanup or EvtFileClose handler.

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

14

Matt wrote:

xxxxx@osr.com wrote:

This thread is rather interesting to me. I just don’t have the
knowledge to understand where everyone is
coming from apparently, but how does all of this relate precisely to
Tim’s problem?

I now believe that Dave’s analysis precisely describes my issue. The
closure of the last control device handle is not a PnP event, so PnP
cannot initiate an unload of the driver.

What we have here is a weird hybrid of a PnP and a non-PnP driver. If
this was strictly a non-PnP driver, I would not expect it to be
automatically unloaded. I have to request that via the service
manager. In this case, when PnP wants to unload it, it can’t because
there is still an open handle. When I close the handle, it’s a close on
a non-PnP device object, so the unload check is never triggered. I’m
not aware of any way for a non-PnP driver to ask for itself to be unloaded.

At this point, I think this is now just an item of historical interest,
and not a problem worth chasing.

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

15

The correct pattern is to delete in the last fdo’s cleanup, so what you have is correct. This is what KMDF does if you delete a control device

// keep the image around until the handle is closed
ObReferenceObject(pdevobj)

// by deleting now, we prevent new creates from occurring, although existing handles still function
IoDeleteDevice(pdevobj)

If (there are open handles) { return; }

on (last handle closed on deleted control device or no open handles in the WdfObjectDelete path) {
call cleanup() on the WDFDEVICE
ObDereferenceObject(pdevobj)
}

The ref is necessary to keep the image from being unloaded so we can still process incoming io on the control device, but IIRC should not prevent the Driver’s DriverUnload routine from running.

One fix is for you to enumerate raw hidden PDO’s for each device and use that as a conduit to communiciate with your device if KMDF is not running in miniport mode. If it is in miniport mode, a lower filter below your miniport could do the enumeration.

D

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, April 07, 2008 9:50 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Control Device Inhibits Unload

Doron Holan wrote:

Are you deleting the control device when the last FDO is removed even when there are open handles against the CDO? Or are you delaying the delete until the handle has been closed?

My code, like approximately 75% of the KMDF filter drivers in existence,
was based on the kmdf/toaster/filter sample in the WDK, That sample
deletes the control device during EvtDeviceContextCleanup.

If Dave’s PnP theory is really correct, it wouldn’t make any difference
if I enabled file object processing on the control device and deferred
the deletion to the EvtFileCleanup or EvtFileClose handler.

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

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

16

Doron Holan wrote:

One fix is for you to enumerate raw hidden PDO’s for each device

I was waiting for you to say that :slight_smile:

17

“Tim Roberts” wrote in message news:xxxxx@ntdev…
…
> And actually, it isn’t Explorer that loads control panel applets.
> Instead, Explorer launches a separate rundll32 process, and rundll32.exe
> loads the DLL, so when the window closes, the process terminates.

Correct, but here is one subtlety: in order to display the applet icons,
the explorer loads and calls each cpl once.
In theory, this gives a cpl chance to run before it’s launched thru
rundll32,
and maybe even prevent explorer from unloading it.

–PA

18

“Tim Roberts” wrote in message news:xxxxx@ntdev…
…
>> I’m
> not aware of any way for a non-PnP driver to ask for itself to be
> unloaded.

Call ZwUnloadDriver on itself?

–PA

19

Pavel A. wrote:

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> …
>>> I’m
>> not aware of any way for a non-PnP driver to ask for itself to be
>> unloaded.
>
> Call ZwUnloadDriver on itself?

When ZwUnloadDriver returned, wouldn’t it be returning into empty space?

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

20

> I’m not aware of any way for a non-PnP driver to ask for itself to be unloaded.

ZwUnloadDriver()…

This function can be called by anyone, but DrvUnload() gets invoked in context of a system thread. This leads me to a conclusion that if driver calls ZwUnloadDriver() on itself in context of a driver-created thread, its DrvUnload() will get invoked in context of another thread.

Therefore, the solution seems to be pretty easy. Create a thread in DriverEntry() that works like:

KeWait( &event,…);
ZwUnloadDriver(RegPath);
PsTerminateSystemThread(0);

When your driver wants to unload itself, it can signal the event, so that the above lines get executed. In DrvUnload() wait until the “unloader” thread gets signaled before you return - by doing so you will ensure
that driver image cannot get unloaded from RAM until “unloader” thread terminates. What is so complex here???

Anton Bassov