Re: Loading Unloading NDIS Intermediate Dirver
- From: BehrTiger <nospam@xxxxxxx>
- Date: Mon, 07 Nov 2005 10:56:02 -0800
Jeff Kelley [MS] wrote:
1. Each miniport adapter must have a unique name. When an intermediate driver inserts itself between an underlying adapter and a protocol driver, the underlying adapter continues to exist so its name is still in use.Thus the intermediate driver must create a new adapter name. The Passthru intermediate does this by prefixing "PASS\" to the underlying adapter name. The only idea that comes to mind for presenting the same name to the user would be to use a "FriendlyName" registry value in the adapter parameters which the UI could use, and that could be set the same for both. That would require that the UI applications consistently use that value.Thanks this is what I suspected. Just thought I would check and see if there was some undocumented way around this.
2. An NDIS layered intermediate driver consists of a protocol driver part and a miniport driver part. NDIS doesn't define a mechanism for loading and unloading protocol drivers. So, the unloading of an intermediate driver must be done through a custom method (e.g. a custom stream driver interface). Prior to unloading, all the adapter instances that it created must be deleted, and the driver must deregister from NDIS.
My driver has a streams interface that issues the UNBIND IOCTL to Ndis. This driver could also use NdisUnbindProtocolsFromAdapter(). The unloading is being commanded externally through an application. There is only 1 adapter the IM is bound to so the IOCTL is issued and cleanup proceeds successfully on the bound adapter. The virtual miniports it creates disappear from the system and the original miniport is restored. The intermediate driver registers an unload handler but it never gets called. As mentioned earlier NdisDeregisterProtocol() does not help to unload the DLL. What causes the unload handler from a protocol driver to get called and subsequently the DLL released from memory?
The ce-streams driver is deregistered using DeactivateDevice() which succeeds fine. However the DLL is still loaded in memory due to something else in the NDIS stack having a reference to it. This instance has no miniports and the miniport-side has been deregistered using NdisIMDeregisterLayeredMiniport(). So that leaves the protocol still registered. NdisDeregisterProtocol() was called in the Ce-streams driver _Deinit() method and the status did not return an error.
What is the proper method to "deregister" the IM driver from NDIS. There are methods to deregister a miniport adapter instance (ie NdisDeregisterAdapter()). I've used this in previous drivers to unload a virtual NIC and it works well (and allows the DLL to be unloaded). There doesn't appear to be a corresponding API when a IM driver registers a protocol and creates it's own miniport instances.
.
- References:
- Loading Unloading NDIS Intermediate Dirver
- From: BehrTiger
- Re: Loading Unloading NDIS Intermediate Dirver
- From: Jeff Kelley [MS]
- Loading Unloading NDIS Intermediate Dirver
- Prev by Date: Re: nk.nb0 startup prolems
- Next by Date: Re: TouchCalibrate()
- Previous by thread: Re: Loading Unloading NDIS Intermediate Dirver
- Next by thread: multithreaded prints with DEBUGMSG and RETAILMSG
- Index(es):
Relevant Pages
|
