More details on "Npcap Loopback Adapter uninstalled" portion of this issue:

• A "Microsoft Loopback Adapter" installed by following directions on TechNet will also be removed by the feature upgrade. In this regard, Npcap isn't doing anything "wrong."
• When the Npcap Loopback Adapter is removed in this way, it becomes impossible to name any other adapter "Npcap Loopback Adapter" because Windows is somehow still aware that that connection exists.
• netsh interface set interface newname= does not work to rename a new interface, nor does PowerShell rename-netadapter.
• The old, removed interface does not appear in Device Manager, even with devmgr_show_nonpresent_devices=1 set and hidden devices shown. I cannot find any way to show that it exists, though the name can be found in various places in the Registry (and the associated GUID is also used throughout the Registry).

So when we attempt to fix a broken installation, either with FixInstall.bat or by reinstalling Npcap, the new loopback adapter will get an automatic name such as "Ethernet 3". This does not affect Npcap's operation, since it keeps track of the device by GUID and by Device ID, but it is not ideal.

We initially thought that the service start type change was happening because the version of Npcap installed was not signed specifically for that release of Windows (since we have to choose which versions to request signatures for in the Hardware Dashboard). However, later testing showed that even drivers signed specifically for Windows 10 1809 were being demoted to SERVICE_DEMAND_START when the 1809 feature update was applied.

Have you reported the issue to Microsoft with the Centrum Feedback application? I tried it year ago for the VirtualBox Host-Only driver, which disappeared with every Insider Build update, and it got fixed few builds later.

In English it is Feedback Hub application, sorry for confusion.

I wanted to add to this that we are using a product that relies on npcap, which we installed on a brand new Windows Server 2019 system. Almost immediately after the npcap component was installed, the system started dropping network packets like crazy. A reboot resolved the issue, but would be a concern to deploy this application with the npcap component to all of our WS 2019 systems with an application deployment platform such as SCCM.

There's no resolution to this yet?

Hi @poortom1004. We probably should have added a comment earlier noting that we believe the "October Update" problem is fixed with recent versions of Npcap, including the very latest version 0.992. We didn't find a way to stop Microsoft from messing with Npcap (and other filter drivers) during these updates, so we did the next best thing aand made Npcap detect the problem and fix itself when it happens. Regarding your Feb 20 comment about Windows Server 2019, that may be a different issue. If you can reproduct the issue with Npcap 0.992, please do file an issue here. Thanks!

Lost the network adapter after Windows update (I am using insider builds), so I created an official feedback at https://aka.ms/AA6frk9 (I hope it will appear soon).

Hi @oldium . This issue was created for the October 2018 Windows update. I just updated the title to make that more clear. But it sounds like there is a new update in the pipeline that you received as a Windows insider and it caused you problems? If so, would you please create a new issue for that and include all relevant details? In particular, what version of Npcap you had, what the problems/symptoms were, and anything you might know about what MS update caused it. Please also explain more about what you mean by "lost the network adapter". Thanks!

I know, I was here 9 months ago. I do not want to go more into detail, this is not issue of NPCAP, so nothing to do here. Correct solution is on Windows side - in the update logic to whitelist the driver.