problems with additional DeviceObject

Eliyas Yakub [MSFT]

unread,

Jan 17, 2004, 3:39:20 PM1/17/04

to

If you open the device directly using symbolic link and keep it open during
remove, it will prevent the driver from unloading. To avoid that you should
open a PNP interface and register for PNP notification so that you can close
the handle when the device is removed. I don't know whether any interface is
registered for an audio device. Somebody who knows more about audio drivers
can chime in.

Let me tell how we solve a similar problem in NDIS miniports. NDIS registers
pnp interface for every miniport and lets you open it in usermode, but it
doesn't allow you to send ioctls on that interface. So to send ioctls, you
have to create a separate device object and symbolik link using
NdisMRegisterDevice. If you have the handle to this link open during remove,
it will prevent the driver from unloading. To workaround this problem: first
you open the PNP interface registered by NDIS and register for PNP
notification. Then you open the symbolik link created by NdisMRegisterDevice
and use that handle for sending ioctls. When the device is removed, you will
get notified on the PNP interface handle. Just then you close both the
handles and voila, the driver will unload smoothly.

The NETVMINI sample exe in the Server 2003 DDK demonstrates this aspect. May
be you can follow that.

--
--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.

Maxim S. Shatskih

unread,

Jan 17, 2004, 5:30:47 PM1/17/04

to

> NdisMRegisterDevice. If you have the handle to this link open during remove,

So, NdisMRegisterDevice creates a PnP stack? Is it using IoReportDetectedDevice
internally?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com

Alexander Grigoriev

unread,

Jan 17, 2004, 11:42:27 PM1/17/04

to

You open two handles: one to your secondary devobj, to send IOCTLs, another
to the PNP interface symlink, to get a device removal notification.

BTW, can a miniport know the name of its PNP interface, to derive the
secondary object's name from it?

"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message
news:u720ulU...@tk2msftngp13.phx.gbl...

Eliyas Yakub [MSFT]

unread,

Jan 18, 2004, 11:19:34 AM1/18/04

to

Correct. There is no function to get the name. I think NDIS uses GUID.

--
--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.

"Alexander Grigoriev" <al...@earthlink.net> wrote in message
news:emHP71X3...@TK2MSFTNGP11.phx.gbl...

Markus Bollinger

unread,

Jan 19, 2004, 9:45:56 AM1/19/04

to

Hello Eliyas !

Thank you for your clarifications.
I think will try another method, I found in the DDK's wdm audio sample
for SB16 which seems more clean to me.
This is to only overwrite the portclass Dispatch routine, and to
capture my private Ioctl's.
There is even the function PcDispatchIrp() in the DDK to forward the
IRP's that are for portclass !
So I do not need the additional DeviceObject.

The only problem will be, that I cannot share a REMOVE_LOCK with the
PortCls dispatch and remove, or do you have an idea for a solution ?

Markus.

"Eliyas Yakub [MSFT]" <eli...@online.microsoft.com> wrote in message news:<Y3hOb.76880$nt4.110937@attbi_s51>...