- Closing a Control Device in KMDF
- Posted by Steve Case on March 21st, 2006
I'm working on porting an existing driver to KMDF. Our board has multiple DMA
channels which we have treated as independent devices in the past, with a
single device representing the PNP device and secondary devices representing
the other DMA channels. (This was done using the late lamented WinDK toolkit
from Bluewater).
My KMDF driver for the single channel is up and running just fine now. I am
trying to create the secondary devices using WdfControlDeviceInitAllocate and
WdfDeviceCreate. The creation appears to work to some extent, but I'm having
trouble with the debugging because when I try and reload the driver (which
works for a single channel) I get a bug check. There's no documentation on
how to remove the Control Device objects once they're created (or I haven't
found any yet), so the Control Device objects aren't being deleted by any of
my code. The bugcheck stack shows FxDevice:
estroy at the top of the stack.
So, my question is whether there is a defined way to remove the Control
Device objects when a PNP driver is unloaded?
- Posted by Maxim S. Shatskih on March 21st, 2006
Maybe it is a better idea to use 1 device object and reference strings like
"Channel0", "Channel1" etc to name the DMA channels?
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
- Posted by Doron Holan [MS] on March 21st, 2006
you can delete a control devobj with WdfObjectDelete. if you are a mix of
pnp and legacy device objects, your driver will not unload unless you
explicitly delete the control devobj when the last FDO goes away. this is a
WDM restriction, not a KMDF one.
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Steve Case" <SteveCase@discussions.microsoft.com> wrote in message
news:3FA3EEE2-35FE-4161-AA8E-5C301B42D869@microsoft.com...
- Posted by Steve Case on March 21st, 2006
Yes, I re-read the WdfObjectDelete description and saw the exception for
Control Devices (you're not supposed to call WdfObjectDelete on regular
device objects). It might be good to mention in the page describing how to
use Control Devices.
Thanks,
Steve Case
"Doron Holan [MS]" wrote:
- Posted by Steve Case on March 21st, 2006
This is a driver which shares most of its code with Linux, Solaris, VxWorks,
etc. Defining pseudo-independent device objects for the channels has proved
pretty flexible. I think the Control Devices should work once I get the kinks
out of it.
Steve
- Posted by Doron Holan [MS] on March 21st, 2006
you should provide this feedback through the link at the bottom of the help
page.
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Steve Case" <SteveCase@discussions.microsoft.com> wrote in message
news:F9384CE7-7722-4DD3-89A1-27F92B1E4F82@microsoft.com...
- Posted by Steve Case on March 21st, 2006
Doron,
I'm still having trouble with this. I call WdfObjectDelete on the control
device objects in the D0Exit callback for the PNP driver, but it's not clear
that the objects are being deleted correctly. The bugcheck is the same - it
happens when I reload the driver, not when I unload it, and it happens in the
call to WdfDeviceCreate for the Control Device objects (not when I call
WdfDeviceCreate for the PNP device) . Any ideas?
Also, do you need to delete the WDFDEVICE_INIT structure returned by
WdfControlDeviceInitAllocate?
Thanks,
Steve Case
"Doron Holan [MS]" wrote:
- Posted by Doron Holan [MS] on March 22nd, 2006
deleting on D0Exit is probably not what you want. D0Exit gets called every
time the device powers down, which could be because of standby, not device
removal. you should register a EvtObjectCleanup on the FDO WDFDEVICE and
delete the control device when the cleanup routine is called.
it with WdfDeviceInitFree
as for the bugcheck on the call to WdfDeviceCreate, please send a callstack
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Steve Case" <SteveCase@discussions.microsoft.com> wrote in message
news
007ADAB-E75A-40A0-BBE5-5C44F52F6B63@microsoft.com...
- Posted by Steve Case on March 23rd, 2006
I'm still getting a bugcheck. I guess I'm confused about the object
hierarchy. Are the control devices child objects of the driver object? If so,
shouldn't they be deleted automatically? I have an EvtObjectCleanup defined
for the FDO and for the subsidiary control devices, so it seems like they
should be deleted automatically when the driver unloads.
Thanks,
Steve
"Doron Holan [MS]" wrote:
- Posted by Eliyas Yakub [MSFT] on March 23rd, 2006
Yes, control-device objects are parented to driver object and they will be
deleted automatically if the driver unloads. The key point here is if the
driver unloads.
Let me explain what I mean by that in little more detail.
Drivers are classified into two major types - pnp and non-pnp
A non-pnp driver is loaded by the service control-manager based on the start
value of the service. A non-pnp driver creates a control-device in
DriverEntry and deletes it in DriverUnload. It unloads only when a client
(another driver or usermode app) of the driver calls the service manager to
unload it.
A pnp-driver is loaded by the pnp manager when it finds a device serviceable
by the driver (INF file creates the association between the driver and
device). It creates device object in the AddDevice and deletes in the remove
device handler. AddDevice can be called multiple times if there are more
than one instance of the same device is found. Everytime a device is
removed, the pnp manager makes an attempt to unload the driver. I say it
makes an attempt because it first checks DriverObject->DeviceObject filed to
see if there are still deviceobjects created by the driver around. If a
deviceobject exits, it doesn't unload the driver.
Now let us see what happens when you create a control-device in a KMDF pnp
driver and non-pnp driver.
In a non-pnp driver, since the deviceobjects are parented to driverobject it
will be deleted automatically as part of unload when the framework deletes
WDFDRIVER object.
In a pnp driver, if you create a control-device, you have to delete it
before the last instance of the device goes away. Otherwise, the pnp manager
will not make an attempt to unload your driver. Framework doesn't automate
this part. It's up to you to track the pnp instances and decide when to
create and delete control-deviceobject. So the way you do that is by keeping
a count of pnp-device instances handled by your driver. You increment the
count in EvtDeviceAdd when the FDO is created and decrement the count in
EvtObjectCleanup when the device is deleted. When the count drops to zero,
you delete the control-device.
KMDF toaster filter sample demonstrates how to create a control-device in a
pnp driver.
Nonpnp sample shows how to create a control-device in a non-pnp driver.
-Eliyas