Configuring an INF File for a Modifying Filter Driver
The following NDIS filter driver installation issues are associated with modifying filter drivers. To create your own modifying filter driver INF file, you can also adapt the sample NDIS 6.0 filter driver.
Set the Class INF file entry to NetService in the INF file. The following example shows a sample Class entry for the INF file.
Class = NetService
The DDInstall section in a filter driver INF file must have a Characteristics entry. The following example shows how you should define the Characteristics entry in your filter INF file.
The 0x40000 value indicates that NCF_LW_FILTER (0x40000) is set. Filter drivers must not set the NCF_FILTER (0x400) flag. The values of the NCF_ Xxx flags are defined in Netcfgx.h. For more information about NCF_ Xxx flags, see DDInstall Section in a Network INF File.
Set the NetCfgInstanceId INF file entry in the INF file, as the following example shows.
You can use the Uuidgen.exe tool to create the GUID for the NetCfgInstanceId entry.
The DDInstall section of the INF file for a filter driver must include an Addreg directive for an Ndi key. The INF file must specify the Service entry under the Ndi key. The ServiceBinary entry in the service-install section of the INF file specifies the path to the binary for the filter driver. For more information, see Adding Service Related Values to the Ndi Key and DDInstall.Services Section in a Network INF File.
The DDInstall section in a filter driver INF file must have FilterType and FilterRunType entries. To specify a modifying filter, define the FilterType entry in your INF file, as the following example shows.
HKR, Ndi,FilterType,0x00010001 ,0x00000002
The FilterType value 0x00000002 indicates that the filter is a modifying filter.
Define the FilterRunType entry in your INF file, as the following example shows.
HKR, Ndi,FilterRunType,0x00010001 ,0x00000001
The 0x00000001 value in the preceding example indicates that the filter module is mandatory. To install an optional filter module, set the FilterRunType entry to 0x00000002. For more information, see Mandatory Filter Drivers.
The following example shows how a modifying filter driver INF file specifies the name of the service.
In this example, NdisLwf is the name of the driver's service as it is reported to NDIS. Note that the name of a filter driver's service can be different from the name of the binary for the driver—but typically they are the same.
The following example shows how the filter INF file references the name of the filter driver's service when it adds that service.
[Install.Services] AddService=NdisLwf,,NdisLwf_Service_Inst;, common.EventLog [NdisLwf_Service_Inst] DisplayName = %NdisLwf_Desc% ServiceType = 1 ;SERVICE_KERNEL_DRIVER StartType = 1 ;SERVICE_SYSTEM_START ErrorControl = 1 ;SERVICE_ERROR_NORMAL ServiceBinary = %13%\ndislwf.sys LoadOrderGroup = NDIS Description = %NdisLwf_Desc% AddReg = Common.Params.reg
A filter INF file must specify at least the primary service name of the filter for the CoServices attribute, as the following example shows.
For more information about the CoServices attribute, see Adding Service Related Values to the Ndi Key.
The FilterClass value in the INF file for a filter driver determines its order in a stack of filters. Filter drivers must define the FilterClass key. The class of the driver can be one of the values in the following table.
Packet scheduling filter service. This class of filter driver is the highest-level driver that can exist above encryption class filters in a driver stack. A packet scheduler detects the 802.1p priority classification that is given to packets by quality of service (QoS) signaling components and the scheduler sends those packets levels to underlying drivers according to their priority.
Encryption class filter drivers exist between scheduler and compression class filters.
Compression class filter drivers exist between encryption and vpn class filters.
VPN class filter drivers exist between compression and load balance filter drivers.
Load balancing filter service. This class of filter driver exists between packet scheduling and failover drivers. A load balancing filter service balances its workload of packet transfers by distributing the workload over its set of underlying miniport adapters.
Failover filter service. This class of filter driver exists between load balance and diagnostics drivers.
Diagnostic filter drivers exist below failover drivers in the stack.
Filter drivers in custom class exist below diagnostic drivers.
Provider address filter drivers exist below the in-box Hyper-V Network Virtualization ms_wnv filter and operate on provider address (PA) packets.
Note If multiple filter drivers have the same FilterClass, they will all be added to the layered stack of filter drivers. The system assigns a layering order to each modifying filter driver with the same FilterClass. In some cases, the system administrator can rearrange the relative order of filter drivers that have the same FilterClass.
The following example shows a sample FilterClass .
HKR, Ndi,FilterClass,, compression
Only Hyper-V switch extension filter drivers are valid in the Hyper-V Extensible Switch. Hyper-V extensible switch filter drivers must define the FilterClass key with one of the values in the following table.
Starting with NDIS 6.30, capture drivers monitor packet traffic in the Hyper-V extensible switch driver stack. This class of filter driver exists below custom drivers in the stack.
For more information about this class of driver, see Capturing Extensions.
Starting with NDIS 6.30, filtering drivers filter packet traffic and enforce port or switch policy for packet delivery through the extensible switch driver stack. This class of filter driver exists below ms_switch_capture drivers in the stack.
For more information about this class of driver, see Filtering Extensions.
Starting with NDIS 6.30, forwarding drivers filter perform the same functions as a filtering driver. Forwarding drivers also forward packets to and from extensible switch ports. This class of filter driver exists below ms_switch_filter drivers in the stack.
For more information about this class of driver, see Forwarding Extensions.
You must define the following entries in the modifying filter driver INF file to control the driver bindings.
HKR, Ndi\Interfaces,UpperRange,,"noupper" HKR, Ndi\Interfaces,LowerRange,,"nolower" HKR, Ndi\Interfaces, FilterMediaTypes,,"ethernet"
For more information about controlling the driver bindings, see Specifying Filter Driver Binding Relationships.
A modifying filter INF file can specify common parameter definitions for the driver and parameters that are associated with a specific adapter. The following example shows some common parameter definitions.
Using HKR AddReg to put keys directly under the service state is a compliance violation. These keys need to be added under the Parameters key of the service to be compliant.
[Common.Params.reg] HKR, FilterDriverParams\DriverParam, ParamDesc, , "Driverparam for lwf" HKR, FilterDriverParams\DriverParam, default, , "5" HKR, FilterDriverParams\DriverParam, type, , "int" HKR, FilterAdapterParams\AdapterParam, ParamDesc, , "Adapterparam for lwf" HKR, FilterAdapterParams\AdapterParam, default, , "10" HKR, FilterAdapterParams\AdapterParam, type, , "int"