Affects Npcap 0.99-r1 and 0.99-r2, but not earlier releases.

This is because we started using the Service registry key ("HKLM:\System\CurrentControlSet\Services\npcap\Parameters" usually, but also "npf\Parameters" under WinPcap API-compatible mode) to determine installation settings and features. Specifically, the LoopbackAdapter value needs to be read by the driver in order to do injection on the loopback adapter. NPFInstall.exe -il is writing it only to the "npf\Parameters" key, so the standard driver doesn't see it.

Remaining questions that need to be answered before we can fix it:

1. Why is NPFInstall.exe using the "npf" service name? That should only be possible with NPFInstall2.exe, the WinPcap API-compatible version.
2. How can or should NPFInstall.exe record the loopback adapter name for both versions of the driver? One possibility would be only allowing Npcap features like loopback capture and injection when using the native (i.e. not WinPcap API-compatible) driver and API.

It seems I was mistaken about NPFInstall.exe vs. NPFInstall2.exe. In WinPcap API-compatible mode, the former uses the "npf" name and the latter uses the "npcap" name. I don't see that this is documented anywhere, so I might change it. This would fix the problem for anything using the npcap service, but would then introduce it for things using the "npf" service name. As I mentioned, though, this could be a satisfactory solution, limiting newer features to programs using the Npcap API, not the WinPcap API.

Most likely fix for the next release will be installing the native "npcap service" version of NPFInstall.exe as NPFInstall.exe, and making NPFInstall2.exe be the WinPcap API-compatible "npf service" version. This will effectively shift the bug from the native mode to the compatible mode, which should only be used to allow legacy programs to run until they are rewritten for the Npcap API.