Npcap extremely slowing down connectivity at boot WIN10

[crankedguy]

Hi,

at least in latest Windows 10 version with all patches applied npcap extremely, really extremely slows down connectivity at startup. I would not bother if we were talking about 5 seconds here, but I have to wait like 40-50 seconds on boot to get network connectivity as soon as npcap is installed.
It is not system specific, it is the same on my laptop with wireless as on my desktop with just Ethernet.
Installed :
driver not started at boot time...I don't want that
and for the rest it makes absolutely no difference if
loopback yes/no,
compatibility mode yes/no,
admin restriction yes/no
it is just always the same, tried on 2 computers as said.
Waiting a minute is too much.

Any ideas here on what that could be or how to investigate? As said I don't think it makes sense to investigate too deeply for a specific system computer problem

Thanks

[dmiller-nmap]

We have had lots of problems getting the "driver not started at boot time" feature to work. The general issue is that Windows expects network drivers to be available at boot. If you mark your driver as "optional," then it hangs around for a while trying to see if it will start anyway. If it's "mandatory," then it's started at boot or you don't boot. I will still look into this, but be aware that it's a known source of problems.

Can you help us diagnose by providing a bit more information?

• What version of Npcap are you using?
• Output from DiagReport.
• Why is it important to you to not start Npcap at boot? If it is for performance reasons, can you provide performance measurements showing that it causes slowness?

[crankedguy]

Hi,
I am using npcap-0.99-r9
Well are we just talking now about just a driver load with this setting or the running service in terms of packet capturing possibility? Because I don't care if a driver is loaded at boot but I do care if a capturing service is started/running at boot. That is why I disabled this. Don't want that on my machine(s) and with Winpcap it was always done manually without issues and without delays on boot. When I want to capture packets it is no issue to do a simple net start command, and that is how it should be from my pov.
I will be away for some time now so I might not answer shortly but will stay on this topic.

Thanks

[gvanem]

... and with Winpcap it was always done manually without issues and without delays on boot.

Speaking for myself, I have no need for NPcap until such trivia is fixed.
But what features of NPcap do you really need in favour of WinPcap now?

[dmiller-nmap]

I found the reference for this issue from Microsoft: "Optional NDIS Lightweight Filters (LWF) could cause 90-second delay in network availability"

To summarize, there is good news and bad news. The good news is that Npcap is implemented as a NDIS 6 Lightweight Filter (LWF) driver, which means that it has substantially less overhead and
faster performance than WinPcap. The bad news is that filter drivers are not intended to be started and stopped frequently, so Windows expects all installed filter drivers will be started as part of startup. "Optional" filters (like Npcap) won't prevent the network from starting altogether, but Windows will wait to see if anything starts them before it makes the network available.

At this point, our plan for the next release is to simply remove the "Automatically start the Npcap driver at boot time" option and have the driver always start at boot. This avoids the issue reports like this one complaining of network interruption at boot, streamlines the installation process, and better fits Microsoft's design for NDIS driver architecture.

[crankedguy]

Well, but this doesn't explain the apparent difference to WinPcap startup. While it is nice for sure that npcap has better performance this is not exactly the topic here...
WinPcap simply does not have a delay if installed, but not started at boot. Maybe it has but it is not noticeable at all while with Npcap the delay is somewhere around 30 seconds on all my systems which is highly annoying.
A driver like npcap should only be started with admin rights and not running in the background at a normal system boot.
But maybe this is just my point of view.

Thanks for the hint that you will remove this in the future.

[dmiller-nmap]

As I mentioned before, WinPcap is a different type of driver entirely. It is a NDIS 5 protocol driver, and is therefore subject to different rules within Windows. This 90-second delay when NDIS 6 LWF drivers are unavailable is the "cost of doing business" in the modern NDIS architecture. It is not a choice that we made, and there is nothing we can do to avoid it. But this is not the bad thing that it might seem, because Npcap comes with better options for access control than not starting at boot.

Npcap can be installed with the "admin-only" option, which requires a process to be running with administrator privileges in order to perform any packet capture or injection operations. WinPcap never had this level of access control: even if you require admin privilege to start the driver service, once it is started, any process can access capture and injection capabilities.

For convenience and least privilege, Npcap's Packet.DLL launches a helper process to elevate to administrator (UAC prompt) and mediate requests from the original application, which still runs with standard privileges. We have some tentative plans to expand this feature to allow admins to configure access control to allow only certain groups to access Npcap functions. If you have concerns or suggestions for improving this feature, we'd be very happy to hear them.

[crankedguy]

Now looking a bit deeper into going this way you describe with the admin-only option, this sounds like a better approach indeed than it was done the old fashioned way. It will allow more granular control for sure.
Thanks for explaining it in more detail.

Group privileges to "access" npcap would be highly welcome here

[dmiller-nmap]

Closing this issue: the delay for optional NDIS LWF drivers is well-documented.