NDIS, ProtocolUnbindAdapterHandler

Hello all.

Reading source of NdisProt WDK example I found that they don’t call NdisUnbindAdapter function directly. Instead they assume that ProtocolUnbindAdapterHandler will be called by NDIS for every bound adapter. I make my own test protocol driver, ProtocolUnbindAdapterHandler looks like this:

VOID NdisTestUnbindAdapter(__out PNDIS_STATUS Status,
__in NDIS_HANDLE ProtocolBindingContext,
__in NDIS_HANDLE UnbindContext)
{
DBG_TRACE(“NdisTestUnbindAdapter”, “Called”);

*Status = NDIS_STATUS_SUCCESS;
}

and I don’t see “NdisTestUnbindAdapter Called” string in WinDbg’s output. Does it mean that there is something wrong with my driver? Should I expect that NDIS always calls ProtocolUnbindAdapterHandler for every bound adapter?


Thanking In Advance,
Mikae.

Under what conditions are you expecting to see ProtocolUnbindAdapter called?

Likely if the adapter us being uninstalled. On Windows XP not necessarily on
shutdown or standby. However, if a NDIS 5 protocol is run on Vista or later
bind/unbind may be seen more frequently.

Thomas F. Divine
http://www.pcausa.com


From:
Sent: Monday, March 28, 2011 4:55 PM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] NDIS, ProtocolUnbindAdapterHandler

> Hello all.
>
> Reading source of NdisProt WDK example I found that they don’t call
> NdisUnbindAdapter function directly. Instead they assume that
> ProtocolUnbindAdapterHandler will be called by NDIS for every bound
> adapter. I make my own test protocol driver, ProtocolUnbindAdapterHandler
> looks like this:
>
> VOID NdisTestUnbindAdapter( out PNDIS_STATUS Status,
>
in NDIS_HANDLE ProtocolBindingContext,
> __in NDIS_HANDLE UnbindContext)
> {
> DBG_TRACE(“NdisTestUnbindAdapter”, “Called”);
>
> *Status = NDIS_STATUS_SUCCESS;
> }
>
> and I don’t see “NdisTestUnbindAdapter Called” string in WinDbg’s output.
> Does it mean that there is something wrong with my driver? Should I expect
> that NDIS always calls ProtocolUnbindAdapterHandler for every bound
> adapter?
>
> –
> Thanking In Advance,
> Mikae.
>
> —
> 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

Well, I just think about unloading NDIS driver. As I read in MSDN I have to call NdisCloseAdapter from ProtocolUnbindAdapterHandler. Ok, it doesn’t say when ProtocolUnbindAdapterHandler will be called. But NdisProt example looks strange for me: they just call NdisDeregisterProtocol from driver’s Unload function. Assuming that NdisProt is correct example, NdisDeregisterProtocol must call (probably indirectly) to ProtocolUnbindAdapterHandler, else resources allocated by NDIS driver bindings will not be freed.

Hm, do I described the situation good enough?

As Thomas said, ProtocolUnbindAdapter only happens when the stack is torn down, or (on Vista/Win7 only) when an NDIS6 component is paused.

Your understanding is correct – NdisDeregisterProtocol will (indirectly) cause ProtocolUnbindAdapter to be invoked for all bindings. As will removing the miniport. You should see ProtocolUnbindAdapter called for every successful binding you had.

Note that shutting down the system does *not* cause all the drivers to be unloaded. The NIC gets a small notification, and then the system just powers off. Putting the system to sleep *may* unbind your protocol, depending on whether your protocol is “power-aware”.

A reliable way to test this path is to disable the physical NIC. You can do it manually in devmgmt.msc. If you want to get more serious about stressing it, you can use “devcon.exe” from the WDK to write a quick batch script that disables/enables the NIC in a loop.

And of course, buying a $USD 15 USB NIC and physically yanking it out is the most dramatic way to go. :slight_smile:

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Monday, March 28, 2011 3:39 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NDIS, ProtocolUnbindAdapterHandler

Well, I just think about unloading NDIS driver. As I read in MSDN I have to call NdisCloseAdapter from ProtocolUnbindAdapterHandler. Ok, it doesn’t say when ProtocolUnbindAdapterHandler will be called. But NdisProt example looks strange for me: they just call NdisDeregisterProtocol from driver’s Unload function. Assuming that NdisProt is correct example, NdisDeregisterProtocol must call (probably indirectly) to ProtocolUnbindAdapterHandler, else resources allocated by NDIS driver bindings will not be freed.

Hm, do I described the situation good enough?


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

Using BindView from the DDK (sample) and simply enabling/disable the
protocol binding will exercise your
ProtocolBindAdapter/ProtocolUnbindAdapter entry points.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Monday, March 28, 2011 4:55 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS, ProtocolUnbindAdapterHandler

Hello all.

Reading source of NdisProt WDK example I found that they don’t call
NdisUnbindAdapter function directly. Instead they assume that
ProtocolUnbindAdapterHandler will be called by NDIS for every bound adapter.
I make my own test protocol driver, ProtocolUnbindAdapterHandler looks like
this:

VOID NdisTestUnbindAdapter(__out PNDIS_STATUS Status,
__in NDIS_HANDLE ProtocolBindingContext,
__in NDIS_HANDLE UnbindContext)
{
DBG_TRACE(“NdisTestUnbindAdapter”, “Called”);

*Status = NDIS_STATUS_SUCCESS;
}

and I don’t see “NdisTestUnbindAdapter Called” string in WinDbg’s output.
Does it mean that there is something wrong with my driver? Should I expect
that NDIS always calls ProtocolUnbindAdapterHandler for every bound adapter?


Thanking In Advance,
Mikae.


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

Ok, now I understand what was the problem: I called NdisCloseAdapter directly from driver’s Unload function. After that I called NdisDeregisterProtocol. Since all adapters was already unbound, ProtocolUnbindAdapter was not called. Now I changed the code, NdisCloseAdapter is called from ProtocolUnbindAdapter and everything works fine. Thank you all.