Hi, I noticed in the mux sample in the DDK that the same driver binary
is referenced by multiple INFs - i.e. the one for the intermediate
device as well as the one for the miniport and it all seems to work
out. I was trying to perform something similar by creating an INF to
install one driver binary (a portion of which works as a WFP filter
and thus not associated with a virtual NDIS miniport device) and then
another INF for the same driver binary (for the rest of the driver
binary that acts as a driver for a virtual miniport). What I am
noticing is that after installing the first INF (for the filter), the
virtual miniport device does not get properly installed and Windows
complains that the driver for the binary is already loaded in memory.
Now Windows doesn’t have any issues in an
intermediate-NDIS-with-miniport scenario. I was wondering why this is
the case and if there is a special exception for NDIS intermediate
drivers? I made sure the service names, etc. are different for the two
INFs. Any hints or pointers to tricks that allows the intermediate
driver scenario to work with multiple INFs referencing same driver
binary?
In the NDIS IM driver case the driver is loaded by the root enumerated PnP devnode created to represent the upper edge of the IM driver binding(s). The contract agreement between the NetService (or NetTrans) and the Net class ‘halves’ of this driver are such that the driver service is always installed as ‘demand start’. The Net (PnP devnode) class device half being enumerated (as a root device) causes the driver to be started and the first such instance of this is when the NetService (protocol edge and other stuff) gets to initialize. What class of INF are you trying to use to install the ‘filter’. A WFP filter is not a PnP participant in the sense that it has any requirement to have an INF class of any particular type. In fact, why do you need an INF for such a thing at all? All you need is to get your driver loaded which will (and must) occur as the side-effect of enumerating an instance of your (virtual) NIC device. If you expect your filter code to be started as a ‘legacy’ device (like the samples) then you need two drivers. If you can live with your filter only being loaded when an active instance of your (virtual) NIC is enumerated, then you can just install as a class Net device and handle your WFP call-out registration, etc. appropriately. Oh, and by appropriately I suggest you look at how PASSTHRU created an auxilary device by syncronizing the MiniportInit/MiniportHalt behavior so that the driver can properly unload by ensuring that any references to the DRIVER_OBJECT are removed before the return of the last MiniportHalt() otherwise your driver will not unload properly. Good Luck,Dave Cattley
NDIS allows combining any of the following items in the same driver binary:
1 regular (non-IM) miniport
1 IM miniport
any number of protocols
any number of LWFs
any number of WFP callouts
So you could have a driver that hosts an IM miniport, a regular miniport, and two LWFs. Or you could have a driver that hosts six LWFs and four protocols. But you cannot have a driver that hosts two regular miniport drivers.
Do carefully consider, though, who will start your driver. If you have any device driver (e.g., any sort of miniport), then PNP governs the lifetime of your driver. Else, you should use SCM to govern the lifetime of your driver. (It’s also possible to have an export driver loaded to satisfy the runtime linker dependency of some other driver, but that doesn’t strike me as a good place for an NDIS protocol or etc.)
Got it. Thanks Jeffrey and David. I was basically trying to combine a
WFP filter with the miniport and get the DriverEntry to create a
management oriented Device object against which I could send some
initial IOCTLs to set up some dynamic driver-wide parameters (i.e.
stuff that typically ends up in the driver’s service key via the INF
as defaults except the default values need to be something like an IP
address which obviously need to be determined at the installation
time). I wanted to set up these parameters as early as possible before
any of the virtual miniport devices’ Init fns came into the picture.
Hence I was thinking if there could be a mechanism to first load up
the MiniFilter and then with the driver already loaded, simply invoke
virtual miniport installations via the SetupDi APIs pointing to a NDIS
miniport INF. Looks like I will have to figure out an alternative
mechanism to pass in those initial parameters which are not device
specific.
Thanks.
On Tue, Oct 23, 2012 at 3:03 PM, Jeffrey Tippet
wrote: > NDIS allows combining any of the following items in the same driver binary: > > 1 regular (non-IM) miniport > 1 IM miniport > any number of protocols > any number of LWFs > any number of WFP callouts > > So you could have a driver that hosts an IM miniport, a regular miniport, and two LWFs. Or you could have a driver that hosts six LWFs and four protocols. But you cannot have a driver that hosts two regular miniport drivers. > > Do carefully consider, though, who will start your driver. If you have any device driver (e.g., any sort of miniport), then PNP governs the lifetime of your driver. Else, you should use SCM to govern the lifetime of your driver. (It’s also possible to have an export driver loaded to satisfy the runtime linker dependency of some other driver, but that doesn’t strike me as a good place for an NDIS protocol or etc.) > > > > > > > — > 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
Mr. Tippet wrote:>So you could have a driver that hosts an IM miniport, a regular miniport, … I had no idea of that one. Very intersting. Which lead me to re-read MSDN and see quite clearly: [quote] Drivers can register as a combined miniport driver and intermediate driver. To register its physical miniport driver, a miniport-intermediate driver calls NdisMRegisterMiniportDriver with appropriate parameters just as for any miniport driver. To register its virtual miniport interface, the driver calls NdisMRegisterMiniportDriver again, but with the NDIS_INTERMEDIATE_DRIVER flag set in the MiniportDriverCharacteristics parameter. [/quote] I assume that by ‘physical miniport driver’ it is meant ‘any miniport driver that does not need NDIS_INTERMEDIATE_DRIVER set in the characteristics’ right? The device being serviced could still be a root (or other SW bus) enumerated virtual device correct? Or does it really mean it has to be NCF_PHYSICAL and/or have hardware associated with it? Behind the curtain, what is NDIS using as the clue in AddDevice to pick the dispatch behavior and route to the appropriate ‘miniport’ handlers? Thanks,Dave Cattley
> I assume that by ‘physical miniport driver’ it is meant ‘any miniport driver that does not need NDIS_INTERMEDIATE_DRIVER set in the characteristics’ right?
Exactly. NDIS doesn’t really know that your root (or other SW bus) enumerated miniport isn’t “real” hardware. We can infer clues, based on NCF_VIRTUAL, whether the miniport attempts to register for interrupts, and the presence of BUS_INTERFACE_STANDARD; but NDIS doesn’t hardcode "it’s hardware iff it’s on a bus named ‘PCI’ ".
Behind the curtain, what is NDIS using as the clue in AddDevice to pick the dispatch behavior and route to the appropriate ‘miniport’ handlers?
I suppose I shouldn’t spill the beans, lest somebody take a dependency on this implementation detail. I’ll just say that you might find the 2nd parameter to IoAllocateDriverObjectExtension to be interesting.
Thanks. > I suppose I shouldn’t spill the beans … Was just really looking for confirmation on the distinction used (that the DevNode is an adapter device with NDIS_INTERMEDIATE_DRIVER). I would not expect you to document (or even disclose) the actual mechanism in gory detail Regards,Dave Cattley
Regards,Dave Cattley