none
Installing NDIS 6 LWF filter driver interrupts networking in Windows Server 2019 when QoS enabled RRS feed

  • Frage

  • On Windows Server 2019 Datacenter, installing any NDIS 6.0 LWF filter driver results in a network interruption. This is noticeable on Azure instances because the RDP connection drops. We have seen this with our own filter driver, but we have also reproduced it with the demo LWF driver from the Windows DDK. Not registering the optional callbacks does not have an impact: the network still drops for a moment.

    This doesn't happen with Windows Server 2016, and may be related to the QoS feature. A customer of ours had this observation: "Additional observation is that there is some relation to presence of QoS binding on the network interface. When the QoS binding is disabled, the installer finishes without breaking the RDP connection. This scenario however cannot be used as a workaround, since the RDP connection gets broken anyway when QoS binding is restored (re-enabled) after the filter driver is installed."

    Is this intentional, or is there a way to work around this?

    Montag, 14. Oktober 2019 05:14

Alle Antworten

  • HI,

    Thanks for your question.

    Can it work normally on Win2016 along with installing NDIS LWF filter driver? 

    Here's the docs discussed Windows NDIS Filters, hope this helps.

    https://docs.microsoft.com/en-us/windows-hardware/drivers/network/ndis-filter-drivers

    Highly appreciate your effort and time. If you have any question or concern, please feel free to let me know.

    Best regards,

    Michael 


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Dienstag, 15. Oktober 2019 03:22
  • Hi,

     

    Just checking in to see if the information provided was helpful. Please let us know if you would like further assistance.

     

    Best Regards,

     

    Michael


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Montag, 21. Oktober 2019 08:54
  • Hi,

    How are things going on? Was your issue resolved?

    Please feel free to let me know if you need further assistance.

    Best regards,

    Michael


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com


    Donnerstag, 24. Oktober 2019 02:25
  • The issue still exists. There is nothing in the documentation you linked about network stack reset during driver installation. I need a statement from someone at Microsoft or a link to specific documentation that states that this is intentional, or I need an acknowledgement that this is a bug. We are losing customers over this.
    Montag, 28. Oktober 2019 16:07
  • Hello bonsaiviking,

    This may seem a bit "out of left field", but is there any correlation between whether "Multicast Forwarding" is enabled when the network interruptions occur?

    I may have had a similar problem. When network rebinding happens after adding/removing a LWF, the rebinding process waits for various queues to drain. It seemed that "multicast forwarding" was causing packets to be queued to (pseudo-) adapters that were not active (so the packets remained queued). The wait before a timeout disposed of the packets could be over a minute, causing connections to be dropped...

    Gary


    Montag, 28. Oktober 2019 17:15
  • Hello bonsaiviking,

    I just found my notes on the problem that I had. Here is one tell-tale sign of the problem (it assumes that you are in a position to examine kernel stacks during the network interruption). One or more threads in the svchost process hosting NetSetupSvc should have a kernel stack looking like this:

    Child-SP          RetAddr           : Call Site
    ffffc508`9f24b120 fffff801`d1751d5e : nt!KiSwapThread+0x501
    ffffc508`9f24b1e0 fffff801`d1751539 : nt!KiCommitThreadWait+0x10e
    ffffc508`9f24b280 fffff804`32134145 : nt!KeWaitForSingleObject+0x1c9
    ffffc508`9f24b360 fffff801`cffd3594 : ndis!NdisMSleep+0x55
    ffffc508`9f24b3e0 fffff804`3212f8fe : nwifi!FilterPause+0x124
    ffffc508`9f24b420 fffff804`32173d77 : ndis!ndisFInvokePause+0x4a
    ffffc508`9f24b460 fffff804`3212f84e : ndis!ndisPauseFilterInner+0x10f
    ffffc508`9f24b510 fffff804`3212b306 : ndis!ndisPauseFilter+0x6e
    ffffc508`9f24b550 fffff804`3212b01b : ndis!Ndis::BindEngine::Iterate+0x236
    ffffc508`9f24b6c0 fffff804`3212adba : ndis!Ndis::BindEngine::UpdateBindings+0x57
    ffffc508`9f24b6f0 fffff804`3212fdc5 : ndis!Ndis::BindEngine::ApplyBindChanges+0x86
    ffffc508`9f24b740 fffff804`321531c3 : ndis!Ndis::BindRegistry::Reload+0xb9
    ffffc508`9f24b7e0 fffff804`32176987 : ndis!ndisPnpRefresh+0x37
    ffffc508`9f24b810 fffff804`321262f3 : ndis!ndisHandlePnPRequest+0x4e8b
    ffffc508`9f24b8d0 fffff801`d16cc669 : ndis!ndisDispatchRequest+0x73
    ffffc508`9f24b900 fffff801`d1b7021e : nt!IofCallDriver+0x59
    ffffc508`9f24b940 fffff801`d1b6fa5c : nt!IopSynchronousServiceTail+0x19e
    ffffc508`9f24b9f0 fffff801`d1b6f3d6 : nt!IopXxxControlFile+0x66c
    ffffc508`9f24bb20 fffff801`d1820003 : nt!NtDeviceIoControlFile+0x56
    ffffc508`9f24bb90 00007ff9`8956ff64 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffc508`9f24bc00)

    Gary

    Montag, 28. Oktober 2019 21:56