Skip to content
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 OEM 0.9990: Silent install failure leaves npcap files behind #2013

Closed
akontsevoy opened this issue Apr 18, 2020 · 4 comments
Closed

Npcap OEM 0.9990: Silent install failure leaves npcap files behind #2013

akontsevoy opened this issue Apr 18, 2020 · 4 comments

Comments

@akontsevoy
Copy link

@akontsevoy akontsevoy commented Apr 18, 2020

As of 0.9990, #1910 is still not completely fixed. A failed install (such as failure to install the driver) now exits with a proper exit code, but still leaves files behind, most importantly %SystemRoot%\System32\Npcap\wpcap.dll and the HKLM\Software\Npcap registry branch. This is causing our application to misdetect that Npcap is already installed, and we had to introduce yet another clumsy workaround (namely to check if the npcap service is installed).
The expected behavior is that an installation should be transactional -- all or nothing. A failed installation should clean up any files or registry values (better yet, roll them back to a previous version if one was installed), leaving behind only installation logs.

@dmiller-nmap
Copy link

@dmiller-nmap dmiller-nmap commented Apr 18, 2020

NSIS is not a transactional installer system, so we're hampered a bit by that. For installation, you can try the /disable_restore_point=no installer option to use System Restore Points to roll back a failed installation. We had previously disabled this because of users complaining it took too much time.

For uninstallation, we don't really have a good way to "undo" a file removal, so I will make some changes to avoid bailing out early on uninstallation and instead perform as many of the uninstall steps as possible, using the delete-on-reboot capability where possible.

@akontsevoy
Copy link
Author

@akontsevoy akontsevoy commented Apr 20, 2020

Yes, NSIS may be dumb, but even so, it should not be too hard to "stage" the install in some way, to a reasonable degree. For example, when installing Npcap, if this is an upgrade (prior version exists), you can back up the existing files and registry branches to a subdirectory in %ProgramFiles%\Npcap. Then run the uninstaller as usual; then run installation. If the installer fails for any reason, you can clean up the incomplete install, leaving only logs. Then, if this was an upgrade (previous version existed), restore the backed-up files and registry branches, and probably top it off by running NPFInstall.exe -i from the restored directory to restore services. Not really transactional, but at least "eventually consistent" in most cases.

Or maybe just dump NSIS and migrate to WiX Toolset (MSI)? It would have several advantages:

  1. That's more transactional, or at least semi-transactional, and upgrades are normally handled without breaking existing installs even if they fail (provided you are careful with custom actions). Uninstallation of the old version runs after (not before) installing the new one and only removes outdated resources. Installed packages are cached by the system so that installs can be easily repaired/restored.
  2. There are built-in facilities to handle service installation (not sure how drivers are handled in particular though), including prompting for reboot where necessary (such as if the service is deleted while there are service handles open).
  3. You can still use NPFInstall.exe (or a DLL) to handle custom actions which are not offered out of the box.
  4. The core of the installer runs with system privileges (as LocalSystem account), and can run custom actions from your EXE/DLL as such (provided you disable impersonation). LocalSystem account, if I recall, can impersonate anybody, probably up to and including TrustedInstaller. So in theory, maybe this can be used to work around the driver signature enforcement quirks such as observed in #2012.

@fyodor
Copy link
Member

@fyodor fyodor commented May 4, 2020

Hi @akontsevoy . Yes, MSI would be better and we are hoping to move Npcap OEM to that instead of NSIS. It is issue #1175 . But we have some higher priority work to finish first. I will add your list of MSI advantages to that issue discussion.

@dmiller-nmap
Copy link

@dmiller-nmap dmiller-nmap commented May 5, 2020

Npcap 0.9991, released yesterday, should address most of the installer failures you encountered, and its uninstaller will do a more thorough job of cleaning up after itself. Note that an upgrade runs the uninstaller for the previous version, so some of these improvements will not be seen until upgrades to upcoming versions. Nevertheless, I'm closing this issue. Please open a new issue if you have problems with Npcap 0.9991 or later installer/uninstaller.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants