Calls FilterAttach in filter driver - ndis

Question

I create NDIS network filter driver but when I install it I see "FilterAttach" call 4 times.
Why "FilterAttach" call 4 times In my Filter Driver?

Answer 1

There are 3 reasons that you'll see many FilterAttach calls in your driver:
multiple NICs,
monitoring filters, and
NDIS binding recalculations
Let's look at each in detail.
Multiple NICs
Filter drivers will bind a filter module to each NIC that is compatible with the filter driver. So if you have 3 compatible NICs, you'll get at least three calls to FilterAttach.
[TCPIP] [TCPIP] [TCPIP]
| | |
[filter1] [filter2] [filter3]
| | |
[NIC1] [NIC2] [NIC3]
You can tell you're in this situation because the NDIS_FILTER_ATTACH_PARAMETERS::BaseMiniportIfIndex value is different across the different FilterAttach instances. This means your filter is getting bound over different NICs.
Monitoring filters
An NDIS LWF is either monitoring or modifying. Look in the INF file to see which type of filter you have:
; For a Monitoring filter, use this:
; HKR, Ndi,FilterType,0x00010001, 1 ; Monitoring filter
; For a Modifying filter, use this:
; HKR, Ndi,FilterType,0x00010001, 2 ; Modifying filter
The difference between monitoring and modifying is in how these filters bind to a network card. A modifying filter is the simplest: it will just bind once per network card. In contrast, monitoring filters will bind once for each other modifying filter, and one more time for the NIC itself. Here's a diagram of what happens when you have a monitoring filter and 2 modifying filters:
[TCPIP]
|
[monitoring1] // 3
|
[modifying2]
|
[monitoring1] // 2
|
[modifying1]
|
[monitoring1] // 1
|
[NIC]
The key thing to notice in this diagram is that the same monitoring filter is attached 3 times to the stack: once over the NIC, and once over each of the 2 modifying filters (modifying1 and modifying2).
If you don't want your monitoring filter to bind at each altitude like that, you can return NDIS_STATUS_NOT_SUPPORTED from your FilterAttach handler any time NDIS_FILTER_ATTACH_PARAMETERS::LowerIfIndex is different from NDIS_FILTER_ATTACH_PARAMETERS::BaseMiniportIfIndex. If you have a mandatory filter, you should also set the NDIS_FILTER_ATTACH_FLAGS_IGNORE_MANDATORY flag in the NDIS_FILTER_ATTACH_PARAMETERS::Flags, but note that we do not recommend marking a monitoring filter as mandatory.
You can tell that you're in this situation if the NDIS_FILTER_ATTACH_PARAMETERS::BaseMiniportIfIndex is the same in both calls to FilterAttach, but the NDIS_FILTER_ATTACH_PARAMETERS::FilterModuleGuidNameis different. TheBaseMiniportIfIndextells you which miniport your filter is over, and theFilterModuleGuidName` tells you exactly which filter instance is attaching.
NDIS binding recalculations
The final reason that a filter may see multiple calls to its FilterAttach routine is because NDIS sometimes recalculates bindings. Maybe a new filter is getting installed below your filter — NDIS will unbind your filter (FilterDetach) bind the new filter, then bind your filter again (FilterAttach).
You can tell that NDIS is re-trying your filter due to a binding recalculation because the NDIS_FILTER_ATTACH_PARAMETERS::FilterModuleGuidName is the same as a previous call to FilterAttach. This means that NDIS is attaching your filter in the same spot as before.
Debugging tips
If you have a kernel debugger attached, you can always use !ndiskd.filterdriver to see where your filter is attached. You can also use !ndiskd.netreport to see a graphical visualization of the network stack.