Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results


More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.


owsows Member Posts: 8


If you've been using WFP callouts in the kernel, you'll have probably noticed that socket bind requests were shoe-horned into the same callout model. The relevant WFP layers are FWPM_LAYER_ALE_BIND_REDIRECT_V4 and FWPM_LAYER_ALE_BIND_REDIRECT_V6.

For code that needs to support Windows 7-10, it's suitable to use the specific callout version defined as FWPS_CALLOUT_CLASSIFY_FN1.

The MSDN page documenting FWPS_CALLOUT_CLASSIFY_FN1 states that the callback may be activated at IRQL <= DISPATCH_LEVEL.

However, for the bind redirect layers specifically, I'm fairly certain that I've seen documentation stating the callouts will always be activated at PASSIVE_LEVEL. The problem right now is I can't find that documentation. I can't even find forum post here or elsewhere that discuss this.

Nor can I find sample code or open source code that in a meaningful way contribute to resolving this mystery.

Empirically, callouts at the bind redirect layers are always activated at PASSIVE_LEVEL. But it would be nice to have some stronger indicator whether this can be relied upon.



  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,490

    Not a WFP guy, but... just from a Windows kernel-mode architectural point of view... it would be a mistake to use your experience so far to extrapolate to a mistake in the docs. The docs can have errors, sure. But the docs specify the contract. Just cuz you haven't SEEN it, doesn't mean it can't happen in some configuration.

    It doesn't help that the heard in which FWPS_CALLOUT_CLASSIFY_FN1is defined doesn't have a SAL annotation specifying any IRQL constraints.

    The one example that I could see on github of a driver that implements this function was npcap, which DOES have an IRQL constraint specified in its SAL for the implementation of this callback... and they said <= DISPATCH_LEVEL.

    So... yeah. IMHO, absent somebody from the NDIS team coming on here and telling you the docs are wrong (which could happen, right?) I think you're stuck with assuming DISPATCH_LEVEL as the highest-level IRQL constraint for this callback.


    Peter Viscarola

  • owsows Member Posts: 8


    I didn't mean to imply that the docs are wrong. Just that, if memory serves, there should be some other more specific documentation that states what the rules are for FWPS_CALLOUT_CLASSIFY_FN1 in the context of FWPM_LAYER_ALE_BIND_REDIRECT_V4.

    I do believe that for the general case, the MSDN page for FWPS_CALLOUT_CLASSIFY_FN1 does provides an accurate description.

    The example you linked seems to install its callouts at FWPM_LAYER_INBOUND_IPPACKET_V4 and related layers. At these layers, there's a peer and there's data in transit etc. You can sense the urgency. Hence it makes sense that the callout would be activated at DISPATCH_LEVEL.

    Contrast this with FWPM_LAYER_ALE_BIND_REDIRECT_V4 where some local process is asking to register a socket bind. There's no urgency what-so-ever.

    Perhaps this reasoning is invalid?

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,450

    The WFP team was present at Plugfest last week so I asked them about this...

    Turns out you ARE guaranteed to be called at IRQL < DISPATCH_LEVEL at this particular layer. They are going to update the documentation.

    I also asked if there are any other layers where this might be true but I have not yet heard back.


  • owsows Member Posts: 8

    That's awesome! Thanks a ton for forwarding my question, Scott.

    Hopefully this will be useful to others as well.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!