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 upgrade fails when DLL files are in use #2015
Comments
Thanks for another very detailed bug report. We'll look into getting these fixed for the next release. |
For the first issue, I will investigate that crash, and also impose some limits on how many retries are allowed before considering the installation a failure (probably just 1). |
The driver is currently undergoing some major changes, but I will ensure that the driver can be unloaded in a timely manner. |
Catch errors from _itot_s(). See nmap/nmap#2015
Thanks; I think the most important thing is to rename/move the old DLLs before killing, so they cannot be used until upgraded, and to make the killing actually work in unattended mode. I think that should allow the upgrade to succeed in the overwhelming majority of cases. |
We can't really shut down open device handles when the driver service is STOP_PENDING because of how Windows drivers and devices work. The driver is requested to stop, and the I/O manager flags all its devices with DOE_UNLOAD_PENDING. In this state, new handles cannot be opened. Once all existing handles have been closed, it calls the DriverUnload function for the driver. That is our first indication that something is happening. Using kernel debugging, I found that we can inspect the DEVICE_OBJECT's |
Npcap 0.9991, released yesterday, should solve this issue. |
When trying to upgrade an existing Npcap installation that's currently being used in silent mode (
npcap-0.9990-oem.exe /loopback_support=no /admin_only=yes /dot11_support=no /winpcap_mode=no /S
), the installer fails and/or hangs indefinitely for several reasons:NPFInstall.exe
is called with-kill_proc_polite
instead of-kill_proc
, even in silent mode.-kill_proc_polite
is supposed to ask the user, which in unattended mode (e.g. when run in a system session) does nothing and never returns -- the process remains running.Contents of NPFInstall.log:
... etc, ad infinitum. (al-tmhost.exe.current is the application using Npcap in this case -- it never got terminated.)
Expected behavior: For silent (un)installs,
-kill_proc
should be used instead of-kill_proc_polite
(again, silent installation should never ever ask anything of the user).Expected behavior: Npcap driver should always honor the STOP command, irregardless of any open handles. Open handles should then return an error result from their calls and any attempts to open new handles should fail.
NPFInstall.exe -kill_proc
is run manually (which does kill the offending process), the process (in our case) is immediately restarted by its supervisor, and just starts using Npcap again (holding the DLLs open). The uninstaller still cannot remove or replace them and fails.Expected behavior: The uninstaller should move or rename the Npcap DLLs before trying to kill any processes using them. Any newly started processes would then not be able to find the DLLs and the uninstall/upgrade can proceed in peace.
This issue is preventing reliable automated upgrades on Npcap distributed with our product.
The text was updated successfully, but these errors were encountered: