New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Npcap extremely slowing down connectivity at boot WIN10 #65
Comments
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?
|
Hi, Thanks |
Speaking for myself, I have no need for NPcap until such trivia is fixed. |
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 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. |
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... Thanks for the hint that you will remove this in the future. |
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. |
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. Group privileges to "access" npcap would be highly welcome here |
Closing this issue: the delay for optional NDIS LWF drivers is well-documented. |
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
The text was updated successfully, but these errors were encountered: