Npcap 0.9985: Driver goes to DEMAND_START after Windows 10 feature update, won't start at pcap_findalldevs()

[akontsevoy]

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.

[dmiller-nmap]

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 to OpenServiceA() 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]

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.

[dmiller-nmap]

This is fixed in Npcap 0.9988, released today.