locked
Autonomous Driver-Registered WFP Callouts Interfere with MPSDRVLoading RRS feed

  • Question

  • I have a NDIS 6 LWF that also includes WFP functionality.

    The driver uses FwpmBfeStateSubscribeChanges0 to determine when the BFE is running. It then creates it's own sub-layer and registers callouts and filters at FWPM_LAYER_ALE_AUTH_CONNECT_V4. Pretty standard stuff.

    The driver's functionality actually works correctly.

    HOWEVER, the presence of this driver apparently prevents loading of the Windows Firewall - MPSDRV specifically.

    The firewall is not loaded when the StartType is SERVICE_SYSTEM_START. If the StartType is changed to SERVICE_DEMAND_START then the firewall is loaded properly and when the filter is loaded afterwards all components are happy.

    In a similar KMDF driver I worked around this by adding DependOnService = MPSDRV which delayed the driver load.

    However, this technique can't be used with NDIS pseudo-PnP drivers.

    Is there any practical event that I can use in my NDIS 6 LWF to delay registration of WFP callouts sufficiently long so they don't interfere with loading Windows Firewall?

    Are there other factors that could cause this bad behavior?

    Thanks for your time.

    Thomas F. Divine


    Thomas F. Divine

    Wednesday, April 24, 2013 1:08 AM

Answers

  • Yes. That works for this driver as well. However, the requirement for this driver is to be independent of user-mode components.

    After more debugging the problem appears to be related to FwpmBfeStateSubscribeChanges0 and FwpmBfeStateUnsubscribeChanges0. This callback was used to determine when it was appropriate to register WFP callouts.

    The problem occurs when these two calls are used - but no other WFP calls are made at all (No callouts registered, etc.).

    In my original implementation I called FwpmBfeStateUnsubscribeChanges0 from within the FwpmBfeStateSubscribeChanges0 callback. This was the killer.

    If FwpmBfeStateUnsubscribeChanges0 is called outside of the FwpmBfeStateSubscribeChanges0 callback (for example, in the driver's Unload routine) there is no adverse affect on Windows firewall.

    FWIW.


    Thomas F. Divine

    • Marked as answer by PCAUSA Saturday, April 27, 2013 1:29 AM
    Friday, April 26, 2013 12:39 PM

All replies

  • Apparently changing the NDIS 6 LWF INF LoadOrderGroup from NDIS to TDI is sufficient to allow my driver to be loaded after MPSDRV. My driver and Windows Firewall are both happy.

    I think that load order dependencies for registering WFP callouts isn't mentioned anywhere. At least I couldn't find it mentioned. But - there's a lot of documentation.


    Thomas F. Divine

    • Marked as answer by PCAUSA Wednesday, April 24, 2013 1:30 AM
    • Unmarked as answer by PCAUSA Wednesday, April 24, 2013 8:56 PM
    Wednesday, April 24, 2013 1:30 AM
  • Spoke too soon. Changing LoadOrderGroup to TDI is not sufficient.

    Installation of WFP callouts too early still seem to block Windows Firewall (MPSDRV can't run).

    If anyone has insight on this behavior please help.


    Thomas F. Divine

    Wednesday, April 24, 2013 8:58 PM
  • Hi,

    I have NDIS 6 LWF with WFP functionality and haven't had these kind of issues. Difference to your setup is at least, that I add callouts, sublayer and filters in user-mode.

    BR, Antti

    Friday, April 26, 2013 9:45 AM
  • Yes. That works for this driver as well. However, the requirement for this driver is to be independent of user-mode components.

    After more debugging the problem appears to be related to FwpmBfeStateSubscribeChanges0 and FwpmBfeStateUnsubscribeChanges0. This callback was used to determine when it was appropriate to register WFP callouts.

    The problem occurs when these two calls are used - but no other WFP calls are made at all (No callouts registered, etc.).

    In my original implementation I called FwpmBfeStateUnsubscribeChanges0 from within the FwpmBfeStateSubscribeChanges0 callback. This was the killer.

    If FwpmBfeStateUnsubscribeChanges0 is called outside of the FwpmBfeStateSubscribeChanges0 callback (for example, in the driver's Unload routine) there is no adverse affect on Windows firewall.

    FWIW.


    Thomas F. Divine

    • Marked as answer by PCAUSA Saturday, April 27, 2013 1:29 AM
    Friday, April 26, 2013 12:39 PM
  • In my original implementation I called FwpmBfeStateUnsubscribeChanges0 from within the FwpmBfeStateSubscribeChanges0 callback. This was the killer.

     

    Did FwpmBfeStateUnsubscribeChanges0() deadlocked? Like in this thread http://social.msdn.microsoft.com/Forums/en-US/wfp/thread/c91460f5-c49e-4412-810a-b89129cc8f78

    -- Antti

    Friday, April 26, 2013 4:35 PM
  • Yep. Same problem.

    I think a doc tweak to warn others of this problem would be a good idea.


    Thomas F. Divine

    Saturday, April 27, 2013 1:29 AM
  • http://msdn.microsoft.com/en-us/library/windows/hardware/ff550064(v=vs.85).aspx

    3rd remark.

    Thanks,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Saturday, April 27, 2013 4:19 AM
    Moderator
  • Thanks, Dusty!!!


    Thomas F. Divine

    Saturday, April 27, 2013 1:37 PM