Is it possible to take a Windows driver such as a Ports class driver, then have it also set itself up as an NDIS filter (NetService class) driver by calling NdisFRegisterFilterDriver() in it’s DriverEntry()? This would be essentially having the driver work double duty as a Ports and NetService class driver, but within a single code base and binary.
I’m attempting to do this and I’m seeing the call to register the NDIS driver fail, specifically with the following trace message:
[0][mp]<==ndisCreateFilterDriverRegistry, FilterServiceName 807EFA18 Status c0000001
[0][mp]==>NdisFRegisterFilterDriver: DriverObject 84C6C428
[0][mp]==>ndisCreateFilterDriverRegistry, FilterServiceName 807EFA18
[0][mp]<==ndisCreateFilterDriverRegistry, FilterServiceName 807EFA18 Status c0000001
I’ve looked around and it seems that the NDIS driver is heavily dependent on the values placed in the registry from the INF and the INF itself. I’ve tried to spoof the registry keys by adding the NetCfgInstanceId by hand and calling that value out in my code before trying to register the NDIS filter, but have hit a point where it just seems like the wrong way to go about it.
What is the recommended way to go about this? At this point I’d imagine that this would require a Ports class driver and NetService class driver separately, with some kind of composite driver to tie them together to be able to communicate, or have a way for one or the other to communicate through interprocess communication.
> Is it possible to take a Windows driver such as a Ports class driver, then have it also set itself up as an NDIS filter (NetService class) driver by calling NdisFRegisterFilterDriver() in it’s DriverEntry()? This would be essentially having the driver work double duty as a Ports and NetService class driver, but within a single code base and binary.
I’m attempting to do this and I’m seeing the call to register the NDIS driver fail, specifically with the following trace message:
[0][mp]<==ndisCreateFilterDriverRegistry, FilterServiceName 807EFA18 Status c0000001
[0][mp]==>NdisFRegisterFilterDriver: DriverObject 84C6C428
[0][mp]==>ndisCreateFilterDriverRegistry, FilterServiceName 807EFA18
[0][mp]<==ndisCreateFilterDriverRegistry, FilterServiceName 807EFA18 Status c0000001
I’ve looked around and it seems that the NDIS driver is heavily dependent on the values placed in the registry from the INF and the INF itself. I’ve tried to spoof the registry keys by adding the NetCfgInstanceId by hand and calling that value out in my code before trying to register the NDIS filter, but have hit a point where it just seems like the wrong way to go about it.
What is the recommended way to go about this? At this point I’d imagine that this would require a Ports class driver and NetService class driver separately, with some kind of composite driver to tie them together to be able to communicate, or have a way for one or the other to communicate through interprocess communication.
You still need to do a INetCfg based install of a NetService INF. You would probably want to omit any instructions to start/stop the device service since in your case it starts/stops under the control of PnP.
LWF and Protocol drivers are not associated with a PnP device. NDIS does not need to take over dispatch for these driver types. It does, however, need to have its way with calculating bindings in the network stack so you need to have an install of the appropriate network component type (NetService, NetTrans, etc.).
Good Luck,
Dave Cattley
>LWF and Protocol drivers are not associated with a PnP device. NDIS does not need to take over dispatch for these driver types.
I may have overreached here. This is definitely true of Protocol drivers. It may be that LWF drivers do grant their dispatch to NDIS. I have never tried putting an LWF in anything other than a stand-alone driver and combined into an NDIS Miniport.
The uncertainty I have comes from the observation that NdisFRegisterFilterDriver() returns a handle that is useable with NdisRegisterDevice().
I must say I have not looked at how NDIS wires this all up in regards to creating the device object and what driver dispatch table is used.
The experiment I am going to run when I get to a devbox is to watch what NDIS does to a filter driver’s dispatch table. If it does not touch it, then I would assume you can put a LWF into any driver. I am also going to look a LWF that uses NdisFRegisterDevice() and see what DriverObject the resulting DeviceObject is associated (and thus what dispatch table it uses for primary dispatch).
Maybe you have already proven to yourself that the driver dispatch mechanic of having an LWF in an arbitrary PnP driver is OK and this worry of mine is moot.
Good Luck,
Dave Cattley
I answered a similar question here: http://stackoverflow.com/questions/30748755/loading-a-windows-driver-class-other-than-netservice-to-act-as-an-ndis-filter
Dave, to answer your question. Yes, NDIS takes a LWF’s DRIVER_OBJECT. But NDIS won’t touch it until you call NdisRegisterDeviceEx. So my recommendation is to never call NdisRegisterDeviceEx from a LWF - that leaves you free to give away your dispatch table to WDF.
Thank you Mr. Tippet for the definitive answer. So much for me having a few minutes of fun exploring the possibilities 
Cheers,
Dave Cattley
David/Jeffrey -
Thanks so much for your time looking in to this. David, I was just about to follow up here and link to the SO response that Jeffrey posted. This is really awesome, I couldn’t find anything about this, but the detailed description provided there got me on the right path. I didn’t realize you could skip the CopyFiles and AddService in the INF file, so having a single INF for the service is exactly the option I needed.
Kind Regards -
Preston