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 not working after Windows Update #998

Open
io8titan opened this Issue Sep 2, 2017 · 7 comments

Comments

Projects
None yet
2 participants
@io8titan

io8titan commented Sep 2, 2017

I am using npcap 0.93 together with Windows 10 x64 Insider builds.
Whenever I Windows updates to a new build, npcap is not working anymore
(Wireshark doesn't display any interfaces). Reinstalling npcap though fixes the issue.

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Sep 6, 2017

I thought we had addressed an issue like this (#906) in Npcap 0.93, which was the result of Windows version upgrades deleting our non-standard service registry keys. Can you run DiagReport when Npcap is not working and provide the output here? This should help us identify what is going wrong.

dmiller-nmap commented Sep 6, 2017

I thought we had addressed an issue like this (#906) in Npcap 0.93, which was the result of Windows version upgrades deleting our non-standard service registry keys. Can you run DiagReport when Npcap is not working and provide the output here? This should help us identify what is going wrong.

@io8titan

This comment has been minimized.

Show comment
Hide comment
@io8titan

io8titan Sep 13, 2017

Only needed to update Windows today, and again Npcap is not working without a reinstall.
This is the output while Npcap was not working:
DiagReport-20170913-233505.txt

io8titan commented Sep 13, 2017

Only needed to update Windows today, and again Npcap is not working without a reinstall.
This is the output while Npcap was not working:
DiagReport-20170913-233505.txt

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Sep 14, 2017

The DiagReport output looks good except that it appears the Npcap driver service has been changed to Manual start. It is possible to install Npcap this way, though it is not the default. Can you start the service by running (as administrator): net start npcap

If this succeeds, try running Wireshark again. Please let us know whether the service starts and whether Wireshark is able to see interfaces. If it works, you can set it to start automatically instead: sc.exe config npcap start= auto

dmiller-nmap commented Sep 14, 2017

The DiagReport output looks good except that it appears the Npcap driver service has been changed to Manual start. It is possible to install Npcap this way, though it is not the default. Can you start the service by running (as administrator): net start npcap

If this succeeds, try running Wireshark again. Please let us know whether the service starts and whether Wireshark is able to see interfaces. If it works, you can set it to start automatically instead: sc.exe config npcap start= auto

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Sep 14, 2017

I found that we were setting the Start registry value under the Parameters subkey instead of directly under the npcap service registry key, which is incorrect. However, I do not believe this prevented other procedures from setting it properly later in the install process, so fixing this should not have any impact on this issue.

Also, I have a correction: the start value we intend to set is not auto, but system. It is possible that it should be auto, but I am still researching this.

dmiller-nmap commented Sep 14, 2017

I found that we were setting the Start registry value under the Parameters subkey instead of directly under the npcap service registry key, which is incorrect. However, I do not believe this prevented other procedures from setting it properly later in the install process, so fixing this should not have any impact on this issue.

Also, I have a correction: the start value we intend to set is not auto, but system. It is possible that it should be auto, but I am still researching this.

@io8titan

This comment has been minimized.

Show comment
Hide comment
@io8titan

io8titan Sep 14, 2017

A net start npcap and sc.exe config npcap start= auto will solve the issue, but I guess only until the next Windows update when it will be resetted to manual again...
Hope you can find a lasting fix.

io8titan commented Sep 14, 2017

A net start npcap and sc.exe config npcap start= auto will solve the issue, but I guess only until the next Windows update when it will be resetted to manual again...
Hope you can find a lasting fix.

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Sep 16, 2017

I'm glad to hear that this is the only thing that is changing; that makes it easier to track down a fix.

I did more research on the start value: it appears that "SYSTEM" is what we want because Windows Vista and 7 prevent the whole network stack from loading for 90 seconds if an optional filter (like Npcap) is not present (i.e. started) when it tries to start. So setting SYSTEM start makes sure that Npcap is ready before the network starts.

Hope to learn soon why Windows is changing this value on us.

dmiller-nmap commented Sep 16, 2017

I'm glad to hear that this is the only thing that is changing; that makes it easier to track down a fix.

I did more research on the start value: it appears that "SYSTEM" is what we want because Windows Vista and 7 prevent the whole network stack from loading for 90 seconds if an optional filter (like Npcap) is not present (i.e. started) when it tries to start. So setting SYSTEM start makes sure that Npcap is ready before the network starts.

Hope to learn soon why Windows is changing this value on us.

@dmiller-nmap

This comment has been minimized.

Show comment
Hide comment
@dmiller-nmap

dmiller-nmap Oct 26, 2017

I found this thread related to NDIS drivers failing after upgrading Windows versions: http://www.osronline.com/ShowThread.cfm?link=249473

Jeffrey Tippet of Microsoft says:

An NDIS protocol driver gets registered with two databases: the SCM driver
service database and the NetCfg network driver database. SCM is responsible for
starting the driver, and NetCfg is responsible for creating bindings to NICs.
(These separate databases are also why installation requires two steps:
SetupCopyOEMInf and INetCfgClassSetup::Install -- one step for each database.)

Windows migrates the SCM driver database during an OS upgrade, but does not
migrate the NetCfg network driver database during an OS upgrade. Therefore,
after an OS upgrade, you will see that the driver is still registered with SCM,
and still gets its DriverEntry called, but NDIS won't attempt to bind your
protocol to any NICs.

This is not specific to your driver; it's true of all NDIS protocol drivers.
The best workaround is to have your usermode app detect that the driver got
uninstalled, and to call INetCfgClassSetup::Install again.

Documenting this here in case we decide to implement this.

dmiller-nmap commented Oct 26, 2017

I found this thread related to NDIS drivers failing after upgrading Windows versions: http://www.osronline.com/ShowThread.cfm?link=249473

Jeffrey Tippet of Microsoft says:

An NDIS protocol driver gets registered with two databases: the SCM driver
service database and the NetCfg network driver database. SCM is responsible for
starting the driver, and NetCfg is responsible for creating bindings to NICs.
(These separate databases are also why installation requires two steps:
SetupCopyOEMInf and INetCfgClassSetup::Install -- one step for each database.)

Windows migrates the SCM driver database during an OS upgrade, but does not
migrate the NetCfg network driver database during an OS upgrade. Therefore,
after an OS upgrade, you will see that the driver is still registered with SCM,
and still gets its DriverEntry called, but NDIS won't attempt to bind your
protocol to any NICs.

This is not specific to your driver; it's true of all NDIS protocol drivers.
The best workaround is to have your usermode app detect that the driver got
uninstalled, and to call INetCfgClassSetup::Install again.

Documenting this here in case we decide to implement this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment