How to NDIS halt when USB device unplugged

I'm developing an NDIS driver that connects with an existing WDM/USB driver. The NDIS driver gets a handle to the USB driver. With that handle, the NDIS driver can cause the USB driver to send and receive packets.

The problem comes when the USB device is unplugged. I need to be able to cause the NDIS driver to halt and dereference the USB driver handle so the USB driver can unload

The NDIS driver is root enumerated and uses the CallBackEx mechanism to be informed about the loading of the USB driver. Via IOCTL, I can inform the NDIS driver that it is time to Halt, but calling MPHalt() will not work.

How do I inform the NDIS stack that this adapter is no longer valid? I want to be able to leave the NDIS driver loaded and ready to run when the USB device is plugged back in

I've also tried calling NdisMIndicateStatus() and NdisMIndicateStatusComplete() to say NDIS_STATUS_MEDIA_DISCONNECT. But that does nothing. The NDIS driver just sits there. Besides, I think MEDIA_DISCONNECT actually refers to the network media not the usb cable

Thanks
Eric

Alireza
Tue Mar 02 18:46:23 CST 2004

The first question I have is that why this device is installed as a root
enumerated device? (instead of your driver being -the- device driver for the
USB device in question.)

Assuming there is a valid reason to install this as a root enumerated
device, I suggest you consider writing your driver as an IM driver. This way
you will have control over when your device gets initialized or halted by
calling NdisIMInitializeDeviceInstance or NdisIMDeInitializeDeviceInstance.
from PnP's point of view, your device is always there running (and PnP does
not unload your driver unless somebody -disables- your device) but NDIS will
initialize or halt your device when you tell it to.

You can also call NdisMRemoveMiniport. But that is a one way street that
shows your device as "failed" and very likely PnP will unload your driver
afterward and even if your driver stays loaded, you can not re-enable the
device.

The ultimate "correct" solution would be to write a bus driver to handle
this "generic" or "multipurpose" USB device (assuming I got your scenario
right) ejecting or removing a net class dev node when necessary.

-ali

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

"Eric Hollas" <anonymous@discussions.microsoft.com> wrote in message
news:A93ECFBC-7B16-4829-9499-CD385C8E0CF1@microsoft.com...
> I'm developing an NDIS driver that connects with an existing WDM/USB
driver. The NDIS driver gets a handle to the USB driver. With that handle,
the NDIS driver can cause the USB driver to send and receive packets.
>
> The problem comes when the USB device is unplugged. I need to be able to
cause the NDIS driver to halt and dereference the USB driver handle so the
USB driver can unload.
>
> The NDIS driver is root enumerated and uses the CallBackEx mechanism to be
informed about the loading of the USB driver. Via IOCTL, I can inform the
NDIS driver that it is time to Halt, but calling MPHalt() will not work.
>
> How do I inform the NDIS stack that this adapter is no longer valid? I
want to be able to leave the NDIS driver loaded and ready to run when the
USB device is plugged back in.
>
> I've also tried calling NdisMIndicateStatus() and
NdisMIndicateStatusComplete() to say NDIS_STATUS_MEDIA_DISCONNECT. But that
does nothing. The NDIS driver just sits there. Besides, I think
MEDIA_DISCONNECT actually refers to the network media not the usb cable.
>
> Thanks,
> Eric

bburgin
Wed Mar 03 00:06:10 CST 2004

------=_NextPart_0001_10BAF8FA
Content-Type: text/plain
Content-Transfer-Encoding: 7bit


Adding to Alid's comments, You should just install this as a normal NDIS
miniport via an INF. The INF's class would be Class=NET and you would
specify the DeviceID as USB\Ven_xxxx. NDIS will then enumerate your driver
as it would any other adapter miniport. You would then get a pointer to
the USB stack and call it by creating your own IRP and calling
IoCallDriver. Some of the sample NETVMINI may help, as it's lower edge
communicates to the next lower driver via IRPs, albeit, not the USB stack.

Bryan S. Burgin
bburgin@microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights.
------=_NextPart_0001_10BAF8FA
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20
\par Adding to Alid's comments, You should just install this as a normal NDIS miniport via an INF. The INF's class would be Class=NET and you would specify the DeviceID as USB\\Ven_xxxx. NDIS will then enumerate your driver as it would any other adapter miniport. You would then get a pointer to the USB stack and call it by creating your own IRP and calling IoCallDriver. Some of the sample NETVMINI may help, as it's lower edge communicates to the next lower driver via IRPs, albeit, not the USB stack.
\par
\par Bryan S. Burgin
\par bburgin@microsoft.com
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par }
------=_NextPart_0001_10BAF8FA--

anonymous
Wed Mar 03 10:11:08 CST 2004

The reason for the Root enumerated NDIS driver was to leverage a well tested USB driver which I was reluctant to modify extensively. The NDIS driver I used was based on Eliyas' NDISWDM to NDISPROT code

Given the comments from Alireza and Bryan, I think the answer is to fold the USB code into the NDIS MP driver and alter the INF file to tie it to my hardware. This will not only eliminate IRP calls, but it will handle the PNP unload problem I have now with two seperate drivers. Converting the NDIS MP to an Intermediate Driver would allow me to maintain two seperate drivers, but at the expense of a lot of code changes. For this version of the software, I don't have time to fully test all of the changes a conversion would require

BTW, would it be a mistake to call IoAttachDeviceToDeviceStack() in the NDIS driver after I have a pointer to the USB driver on the USBD stack? That would allow PNP IRPs to flow from the USB driver to NDIS, but I thought I saw a list of prohibited calls from NDIS that includes IoAttachDeviceToDeviceStack()

Thanks
Eric

Alireza
Wed Mar 03 13:28:11 CST 2004

> BTW, would it be a mistake to call IoAttachDeviceToDeviceStack() in the
NDIS driver after I have a pointer to the USB driver on the USBD stack?
That would allow PNP IRPs to flow from the USB driver to NDIS, but I thought
I saw a list of prohibited calls from NDIS that includes
IoAttachDeviceToDeviceStack().

Yes, that would be a mistake (assuming we are talking about -unified- driver
scheme and you want to do it on the PhysicalDeviceObject or NextDeviceObject
you got by calling NdisMGetDeviceProperty. NDIS has already attached its FDO
(the DeviceObject you get from the same call) to the stack and will send all
the PNP IRPs down as necessary. All you have to do is to use
NextDeviceObject to send your IRPs to.

It is also possible that I did not understand your question! then I
appreciate you tell me what PnP IRPs are you concern about not making it to
the USB device.

-ali


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


"Eric Hollas" <anonymous@discussions.microsoft.com> wrote in message
news:31370043-917C-47AB-AE96-28F7ACB4A1CA@microsoft.com...
> The reason for the Root enumerated NDIS driver was to leverage a well
tested USB driver which I was reluctant to modify extensively. The NDIS
driver I used was based on Eliyas' NDISWDM to NDISPROT code.
>
> Given the comments from Alireza and Bryan, I think the answer is to fold
the USB code into the NDIS MP driver and alter the INF file to tie it to my
hardware. This will not only eliminate IRP calls, but it will handle the
PNP unload problem I have now with two seperate drivers. Converting the
NDIS MP to an Intermediate Driver would allow me to maintain two seperate
drivers, but at the expense of a lot of code changes. For this version of
the software, I don't have time to fully test all of the changes a
conversion would require.
>
> BTW, would it be a mistake to call IoAttachDeviceToDeviceStack() in the
NDIS driver after I have a pointer to the USB driver on the USBD stack?
That would allow PNP IRPs to flow from the USB driver to NDIS, but I thought
I saw a list of prohibited calls from NDIS that includes
IoAttachDeviceToDeviceStack().
>
> Thanks,
> Eric

anonymous
Wed Mar 03 13:51:05 CST 2004


----- Alireza Dabagh [MS] wrote: ----
It is also possible that I did not understand your question! then
appreciate you tell me what PnP IRPs are you concern about not making it t
the USB device

I was talking about the non-unified driver using the IoAttachDeviceToDeviceStack(), not the unified driver. In the non-unified case, the IRPs I want seen by the NDIS MP driver are IRP_MN_SURPRISE_REMOVAL and IRP_MN_REMOVE_DEVICE. The USB driver will get these IRPs when the hardware is unplugged

If it was possible to forward those IRPs from the USB driver to the NDIS MP driver, then the NDIS driver would call MPHalt()

Does that clarify the scenario

Eric

Doron
Wed Mar 03 23:36:17 CST 2004

This can't be done. Your device object in the NDIS stack is already
attached to a device object, you can't attach one device object to 2 stacks.
Even worse if you could do this, it would be impossible to tell which stack
the PNP irps are really meant for.

d

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to newsgroups only.

"Eric Hollas" <anonymous@discussions.microsoft.com> wrote in message
news:439329D8-9F0B-46F8-B690-F6A882D433A8@microsoft.com...
>
> ----- Alireza Dabagh [MS] wrote: -----
> It is also possible that I did not understand your question! then I
> appreciate you tell me what PnP IRPs are you concern about not making
it to
> the USB device.
>
> I was talking about the non-unified driver using the
IoAttachDeviceToDeviceStack(), not the unified driver. In the non-unified
case, the IRPs I want seen by the NDIS MP driver are IRP_MN_SURPRISE_REMOVAL
and IRP_MN_REMOVE_DEVICE. The USB driver will get these IRPs when the
hardware is unplugged.
>
> If it was possible to forward those IRPs from the USB driver to the NDIS
MP driver, then the NDIS driver would call MPHalt().
>
> Does that clarify the scenario?
>
> Eric

Eliyas
Thu Mar 04 00:01:27 CST 2004

No you cannot forward PNP irps from one stack to another. The best approach
for non unified case would be to enumerate the NDIS MP as a child device of
USB client driver. Lift code from toaster bus driver sample and incorporate
that in USB client driver to enumerate a child device. With this approach
whenever your USB device gets removed, the PNP manager will automatically
remove the child. This will also solve load order dependency between two
drivers.

This is a much better solution than root-enumerating the NDIS miniport.

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




"Eric Hollas" <anonymous@discussions.microsoft.com> wrote in message
news:439329D8-9F0B-46F8-B690-F6A882D433A8@microsoft.com...
>
> ----- Alireza Dabagh [MS] wrote: -----
> It is also possible that I did not understand your question! then I
> appreciate you tell me what PnP IRPs are you concern about not making
it to
> the USB device.
>
> I was talking about the non-unified driver using the
IoAttachDeviceToDeviceStack(), not the unified driver. In the non-unified
case, the IRPs I want seen by the NDIS MP driver are IRP_MN_SURPRISE_REMOVAL
and IRP_MN_REMOVE_DEVICE. The USB driver will get these IRPs when the
hardware is unplugged.
>
> If it was possible to forward those IRPs from the USB driver to the NDIS
MP driver, then the NDIS driver would call MPHalt().
>
> Does that clarify the scenario?
>
> Eric