MiniportHalt on Win7

NTDEV
1

Hi all,

I nave a USB network device, with 2 drivers handling it : driver-1 which is a simple WDF driver, which enumerates a child PDO under it using WdfChildListAddOrUpdateChildDescriptionAsPresent API, and driver-2, which is NDIS5.1 miniport.

On Win7, when I unplug the device after the drivers are loaded, I see strange behavior: first release_hardware of driver-1 is called, only then MiniportHalt of driver-2 is called. I would expect it to be called in opposite order (like it is on WinXP).

Any input about that?

Thanks,
S.

2

release_hardware is called on SURPRISE_REMOVAL, MiniportHalt is called on REMOVE_DEVICE (or when all pending sent packets are returned by the driver-1 on SURPRISE_REMOVAL).

3

Hi Alex,

Thank you for the reply.

or when all pending sent packets are returned by the driver-1 on SURPRISE_REMOVAL

I do cancel all my requests from driver-2 to driver-1 and can see them cancelled upon completion (all IO is stopped). I do see NDIS sends me new OIDs with OID_802_3_MULTICAST_LIST and OID_GEN_CURRENT_PACKET_FILTER, which I complete with STATUS_NDIS_NOT_ACCEPTED, as MSDN requires.

What I don’t understand - if IRP_MN_SURPRISE_REMOVAL is complete and release_hardware is called before MiniportHalt, why don’t I see the same behavior on XP?

Thanks,
S.

4

I don’t think there are guarantees for any particular order in this case.

5

Right, NDIS is its own driver model, separate from WDM. Its contract is only that “MiniportHalt deallocates resources when the NIC is removed” – there’s nothing in there about how it relates to any particular PNP IRP. Really the fact that NDIS itself is implemented as a WDM driver is an implementation detail. (Er, except where it leaks through, as in the unfortunate MiniportFilterResourceRequirements).

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Monday, October 11, 2010 10:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MiniportHalt on Win7

I don’t think there are guarantees for any particular order in this case.

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

6

@Skaramush: So you use NDIS 5.1 miniport on Win7?
Maybe the emulation has quirks in complex cases, like one you’ve seen.
Otherwise, a child not removed before its bus release_hardware is a good candidate to winners of the bug bash.

Another question: why driver-2 cancels its requests to driver-1 and OIDs?
How does it know that driver-1 got surprise removal?

Regards,
– pa

7

Hi Pavel,

@Skaramush: So you use NDIS 5.1 miniport on Win7?
Yes.

Otherwise, a child not removed before its bus release_hardware is a good
candidate to winners of the bug bash.
How do I get a prise for that?

Another question: why driver-2 cancels its requests to driver-1 and OIDs?
My driver-2 process net_packets and oids and generates wdf i/o requests, which it forwards to driver-1. If I get surprise removal, I cancel all submitted requests.

How does it know that driver-1 got surprise removal?
The IRP_MN_SURPRISE_REMOVAL first reaches the driver-2 (in format of ndis pnp notification), and after handled, forwarded to lower driver in the stack (which is driver-1).

S.

8

Hi Jeffrey,

Thank you for the reply. So, if I understand you correctly, within MiniportHalt callback I can’t count on driver-1’s resources if I free them in release_hardware, right?

Thanks,
S.

9

wrote in message news:xxxxx@ntdev…
> Hi Pavel,
>
>> @Skaramush: So you use NDIS 5.1 miniport on Win7?
> Yes.
>
>> Otherwise, a child not removed before its bus release_hardware is a good
>> candidate to winners of the bug bash.
> How do I get a prise for that?
>
>> Another question: why driver-2 cancels its requests to driver-1 and OIDs?
> My driver-2 process net_packets and oids and generates wdf i/o requests,
> which it forwards to driver-1. If I get surprise removal, I cancel all
> submitted requests.
>
>> How does it know that driver-1 got surprise removal?
> The IRP_MN_SURPRISE_REMOVAL first reaches the driver-2 (in format of ndis
> pnp notification), and after handled, forwarded to lower driver in the
> stack (which is driver-1).
>

So driver-2 gets the NDIS surprise removal callback before driver_1;
it can gracefully wrap up before driver_1 handles release_hardware.
Everything is good.

–pa