On updating Gpg4Win to 4.4.0 on a Windows 10 machine by right-click run-as-admin on the installer, then rebooting to the non-admin account, the first time I tried to verify a download (Openoffice) by double clicking its .asc file, I got two error popups, both saying:
The procedure entry point npth_get_version could not be located in the dynamic link library C:\Program Files(x86)\GnuPG\binadirmnger.exe
I found that this had started Kleopatra in the background and it could be seen in the ‘hidden icons’ on my toolbar. On opening this (by double clicking the Kleopatra icon in the hidden icons), it showed that the tool had successfully run without any errors.
With Kleopatra still running, each time I tried that double click on that .asc file, the tool worked correctly without errors. However, the pop-ups appeared every time I tried that double-click without Kleopatra running in the background.
As a second test, I tried the same with the .sig file for the GPG update itself. Again, when Kleopatra was not already running, I got two popups but it started Kleopatra and ran successfully. But when Kleopatra was already started, the signature check ran normally without popups.
We have a similar problem here on Windows 10 and Windows 11 machines:
Upgraded to Gpg4Win 4.4.0. The installer was executed with a local admin account and not the standard user account. But after a restart of the machine, which was suggested by the installer, a standard user gets error messages, e.g. in Outlook when opening the GpgOL Dialog or in Kleopatra when checking for updates.
Hint for developers: It seems that the dirmngr.exe does not contain the export information (e.g. via providing it in a .def file) so that other modules can access the npth_get_version function, which has been introduced there recently. Or the access of this function is not performed in the intended way, ig it was never meant to call this function across module / process boundaries.
Hi @dwidz, the best way to install Gpg4win is as administrator because otherwise you might get different problems. Can you try that and see if that already solves the problem?
thank you for the answer.
As already noted in my post above, we upgraded the Gpg4Win version with a local Administrator account, so installer rights should not be the problem.
From the error message, I made the conclusion that some process tries to access the npth_get_version function. But I verified that this function is not exported by dirmngr.exe, hence the message is right. Since the function is new in this release, it seems to be not so unrealistic that something went wrong with the implementation of it - especially the missing export. But this is only my observation from the outside.
We did not try a complete deinstall and reinstall, because we fear that the data (keys and configuration) might get lost during this process. In addition, because of my investigation that I described above, I see only very low propability that a reinstall will help.
I have tried to reproduce this but I have not seen any error messages in my test installations of Gpg4win 4.4.0.
Neither when checking for updates nor when opening the GpgOL configuration dialog.
Was this really the exact error message? Because the path here is C:\Program Files (x86)\GnuPG\bin\dirmnger.exe I believe this is a typo on your side.
Though you should always make a backup (just in case), deinstallation does not affect the data in a users GNUPGHOME (usually at %APPDATA%\gnupg). Also the configuration made in config files in that folder is not affected.
But any global configuration is affected, it will get removed.
Same error here after upgrading from 4.2.0 to 4.4.0 (using Windows 11)
At every Kleopatra-Start it says: The procedure entry point npth_get_version could not be located in the dynamic link library dirmngr.exe
The error-message also pops up when directly starting dirmngr.exe (version 2.4.7.31706).
Yes, I rebooted. I tried now an uninstallation, rebooted, but the folders Gpg4win and GnuPG were still there and contained all files. After manual removing the two directories and a new installation it worked without errors.
It looks like the uninstaller does not cleanup (at Windows 11).
Alex, that is a good point. I also installed as Admin (a separate Windows user account).
When I now try to install 4.4.1 under a standard user, the installer tells me that it tries to update Version 4.2.0!!!
So looks like 4.2.0 was never uninstalled correctly.
Next I tried to install with Admin user and voila, it shows that it tries to update to 4.4.1 from Version 4.4.0 - which is correct.
Since we switched to AD between the installation of 4.2.0 and 4.4.0, I guess there is an issue with the different users and/or rights.
Sad that there is no error from the uninstall process…
How should that be handled? Would be good if the installer could identify such a situation and respond with a warning or error. @eebb: Do you think this is feasible?
I originally installed 4.2.0 as normal user with Admin rights but UAC. I do not remember if it was required to confirm adminstrator rights during installation.
I updated as Admin user. Maybe this is the difference?
At least, 4.2.0 was installed in AppData, 4.4.0 was installed under “Program Files (x86)”.
Hi everybody,
first thanks for reporting your issues with Gpg4win - this is important to improve this package.
I’ve just read the discussion again and try to suggest how we can go forward:
I think you all will have upgraded to 4.4.1 by now. If you haven’t, please try.
So what is the situation now:
Who is seeing the error message and when during operations?
If they are still be seen, maybe you can try and install it a fresh windows machine (e.g. a VM) and then we need to compare the installed files and permissions between that fresh install and the upgraded installations.
I think if you still have issues you should check carefully if you have an additional Gpg4win version installed locally. Having two versions installed in parallel will always run into issues at some point.
This is usually caused by an additional local installation (where you are not asked for the admin password) in a user directory instead of below C:\Program Files (x86). You should see this in your %PATH%.
I think eebb’s suggestion is the way to go. The two parallel installations are the root problem. Since it is very difficult to avoid this in the first place, it should at least - as now done by eebb - advised as a manual solution for the problem here in the forum to deinstall the private installed version (the one in AppData).
Hi Michael,
unfortunately the issues arising from two parallel installations are not the same every time and people having the issues do not usually report that they might have more then one installation… Therefore its difficult to spot for support people, especially if the do not do support for gnupg full time.
@cklassen or @bernhard could you put something on the troubleshooting page, so that people having issues might become aware that they should check for a second installation?
Having said that: we are working on enabling multiple parallel installations so sometime in the future this cause for problems might go away.
Edit: We are working on multiple parallel installations but only for e.g. Gpg4win parallel to GnuPG VS-Desktop. So this will not solve issues with installing the same program multiple times, using the same %GNUPGHOME%.
I meant it more general (not only for the npth error), but as I can’t really tell you which other issues such a duplicate installation may have, that’s fair enough Thank you!
Thank you!