How to NDIS halt when USB device unplugged

Discussion in 'Windows Vista Drivers' started by Eric Hollas, Mar 2, 2004.

  1. Eric Hollas

    Eric Hollas Guest

    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
     
    Eric Hollas, Mar 2, 2004
    #1
    1. Advertisements

  2. 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.

    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.
    cause the NDIS driver to halt and dereference the USB driver handle so the
    USB driver can unload.
    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.
    want to be able to leave the NDIS driver loaded and ready to run when the
    USB device is plugged back in.
    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.
     
    Alireza Dabagh [MS], Mar 3, 2004
    #2
    1. Advertisements

  3. 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


    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Bryan S. Burgin [MSFT], Mar 3, 2004
    #3
  4. Eric Hollas

    Eric Hollas Guest

    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
     
    Eric Hollas, Mar 3, 2004
    #4
  5. 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.


    tested USB driver which I was reluctant to modify extensively. The NDIS
    driver I used was based on Eliyas' NDISWDM to NDISPROT code.
    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.
    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().
     
    Alireza Dabagh [MS], Mar 3, 2004
    #5
  6. Eric Hollas

    Eric Hollas Guest

    ----- 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
     
    Eric Hollas, Mar 3, 2004
    #6
  7. 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.

    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.
    MP driver, then the NDIS driver would call MPHalt().
     
    Doron Holan [MS], Mar 4, 2004
    #7
  8. 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.




    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.
    MP driver, then the NDIS driver would call MPHalt().
     
    Eliyas Yakub [MSFT], Mar 4, 2004
    #8
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.