Repository navigation
Npcap 0.9985: Driver goes to DEMAND_START after Windows 10 feature update, won't start at pcap_findalldevs() #1911
Description
Npcap 0.9985 was installed on a Windows 10 Enterprise version 1803 with the default start service start mode for npcap.sys (npcap-0.9985-oem.exe /loopback_support=no /admin_only=yes /dot11_support=no /winpcap_mode=no /S). It worked as expected until Windows received a feature update to version 1909. The driver start type has changed to DEMAND_START and no longer starts on OS boot:
>sc qc npcap [SC] QueryServiceConfig SUCCESS
SERVICE_NAME: npcap
TYPE : 1 KERNEL_DRIVER
START_TYPE : 3 DEMAND_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : \SystemRoot\system32\DRIVERS\npcap.sys
LOAD_ORDER_GROUP : NDIS
TAG : 17
DISPLAY_NAME : Npcap Packet Driver (NPCAP)
DEPENDENCIES :
SERVICE_START_NAME :
I think this behavior of Windows updates has been discussed before and it was concluded that nothing can be done about it.
However, the problem is that Npcap versions prior to 0.998x (or at least 0.99-r7) used to start the driver themselves when the library was opened and pcap_findalldevs() executed. But this no longer happens with 0.9985; the driver remains stopped and only the loopback interface is returned. If the driver is manually started, it works as expected.
Furthermore, the workaround we had in place to detect and remediate such condition (check if pcap_findalldevs() returns no adapters, execute NPFInstall.exe -r -n and manually restart the driver) is no longer effective, because at least since 0.998x a loopback adapter is always returned regardless of the state of the driver (though we can adjust the work-around on our end).
I believe the original behavior (i.e. to start the npcap service if stopped) was correct.
Activity
dmiller-nmap commentedon Feb 24, 2020
Thanks for this report. The fact that Windows changes the start type of the service is a known issue (#998) which we do not have a solution to at the moment. The change to avoid starting the driver service was made in Npcap 0.9983 based on the fact that in the majority of cases the user running it doesn't have appropriate privileges to start or install the driver service. We were looking for ways to speed up the
pcap_findalldevs()process, and a failed call toOpenServiceA()for every installed adapter seemed like a good thing to eliminate. I'll look into how we might re-enable this functionality in a different place that wouldn't have such an impact, like DllMain.akontsevoy commentedon Feb 24, 2020
Sounds good to me, though it might be risky to do in
DllMain()under a library lock (because who knows what additional libraries those OpenSCManager/OpenService/ControlService calls might be trying to load under the hood). Maybe it's better to check & start the driver lazily on any pcap API call once if this was not already tried, but if that fails, set the state variable accordingly and avoid trying that again.Restore ability to start driver if it is stopped; only once per proce…
dmiller-nmap commentedon Mar 5, 2020
This is fixed in Npcap 0.9988, released today.