Incorrect install path displayed following successful installation

[ambercap]

I used choco to install freecad to a specific folder. The installation was successful and it was indeed installed to the correct location. Choco then reported that freecad was installed successfully, but incorrectly reported that it was installed to the folder for Adobe Acrobat! Choco did not make any changes whatsoever to the Adobe folder - this is just a bogus message. I assume this is a bug with choco and not with the package.

2020-11-06 01:32:10,457 11248 [INFO ] - Chocolatey v0.10.15
2020-11-06 01:32:10,463 11248 [DEBUG] - Chocolatey is running on Windows v 10.0.19041.0
2020-11-06 01:32:10,465 11248 [DEBUG] - Attempting to delete file "C:/ProgramData/chocolatey/choco.exe.old".
2020-11-06 01:32:10,465 11248 [DEBUG] - Attempting to delete file "C:\ProgramData\chocolatey\choco.exe.old".
2020-11-06 01:32:10,471 11248 [DEBUG] - Command line: "C:\ProgramData\chocolatey\choco.exe" install freecad --pre --params /InstallDir:'C:\FreeCAD'
2020-11-06 01:32:10,472 11248 [DEBUG] - Received arguments: install freecad --pre --params /InstallDir:'C:\FreeCAD'

2020-11-06 01:34:06,893 11248 [INFO ] -  The install of freecad was successful.
2020-11-06 01:34:06,895 11248 [INFO ] -   Software installed to 'C:\Program Files (x86)\Adobe\Acrobat Reader DC\'

Full log at: https://gist.github.com/ambercap/a6cc0b69cf6c41cd54b3e78cc66789c6

[NJT145]

I have similar issue with result "Software installed to 'C:\Program Files (x86)\Hotspot Shield\10.9.10\'" after command "choco install openjdk". My log from "C:\ProgramData\chocolatey\logs\chocolatey.log" is here: chocolatey.log Summary log file from "C:\ProgramData\chocolatey\logs\choco.summary.log" here: choco.summary.log Registry file from "C:\ProgramData\chocolatey.chocolatey\openjdk.15.0.1.registry" registry.txt

[brian6932]

I have this weird conflict with Hotspot Shield too, and most annoying of all, sometimes when managing packages, Chocolatey just decides to delete the the C:\Program Files (x86)\Hotspot Shield path. The occurrences in this thread are not the only ones either, there was one in #1291. I get that this issue may not be the most high priority, but this is very annoying. I keep having to reinstall Hotspot Shield because Chocolatey keeps deleting it's path.

[calebTree]

I found this bug also (in choco -v 0.12.1)

• From what I can tell so far it is only a log output bug and the packages are still installed to the appropriate paths: C:\ProgramData\chocolatey\lib\.
• My log indicates similarly to @brian6932 2022-01-28 11:16:32,912 3780 [INFO ] - Software installed to 'C:\Program Files (x86)\Hotspot Shield\10.22.5\'
• However, I have not yet seen the above path get deleted by choco.

[brian6932]

For example, choco uninstall mingw and choco uninstall qt-5-default causes Hotspot Shield to be uninstalled and even it's appdata folder to be uninstalled, so it seems like it's triggering the auto uninstaller Verbose Logs (from HSS-10.22.5-install-plain-773-plain.exe.log in AppData\Local\Temp\chocolatey): HSS-10.22.5-install-plain-773-plain.exe.log pastebin link for browser viewing

[gep13]

@brian6932 can you check to see if there is a .reigstry file in the following location:

C:\ProgramData\chocolatey\.chocolatey\mingw.<package-version-number>

If there is, can you copy it to this issue?

[brian6932]

@gep13 I have 4 different ones, this is the most recent one though: mingw.11.2.0.07112021.zip -this has both .registry, and .registry.backup pastebin link for browser viewing - this is only .registry

[gep13]

The way that Chocolatey works, in terms of integrating with application installed into Add/Remove Programs, is to capture the registry keys that are created during the installation. The captured registry keys are then stored in the .registry file, and then later used during running of Chocolatey auto uninstaller.

The problem here is that during the installation of the mingw package, a registry key for an unrelated application, in this case Hotspot Shield has been captured. This would suggest that this application was updating at the same time the Chocolatey was installing the mingw package.

Unfortunately, there isn't much that can be done here. The capturing of the entries in the .registry file is a best effort at capturing the information that has changed.

[brian6932]

This would suggest that this application was updating at the same time the Chocolatey was installing the mingw package.

@gep13 wdym by this? the program is not updating, nor is it actively running. I have it set to manually update, it is as far as possible from running, or actively updating itself.

[TheCakeIsNaOH]

I'm pretty sure that there is either something really weird going on with the hotspot shield vpn, and/or there is a bug in the choco registry differencing.

Setup:

• Install hotspot shield vpn, no need to have it open: https://www.hotspotshield.com/
• Build choco with visual studio, and set the launch args to upgrade mingw --yes --force
• Set a breakpoint at this line (at the installersDifferences check): https://github.com/chocolatey/choco/blob/develop/src/chocolatey/infrastructure.app/services/ChocolateyPackageService.cs#L363
• Install procmon64 (part of sysinternals) and launch
• Filter to include path begins with HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
• Filter to exclude process name is choco.exe
• Start debugging in visual studio, wait till it hits the breakpoint
• Note that nothing shows up in procmon (which indicates that hotspot did not write or read anything to the registry uninstall)
• Note that installersDifferences contains an entry for hotspot, even though nothing (except choco itself) touched the registry uninstall section while visual studio was debugging.

Also, I noticed that the location of the registry key that choco finds is Uninstall\HotspotShield, while when I check in regedit, it does not exist, and I only see Uninstall\HotspotShield TAP-Windows,

[calebTree]

This bug seems intermittent, or a cache/environment related. The last few things I installed with choco logged correctly. I recently installed awk and I did not see this log bug.

[TheCakeIsNaOH]

@calebTree The awk package is a "pure portable" package because it does not have a chocolateyInstall.ps1 script. For "pure portable" packages, the install location is always set to the location the package gets extracted to (e.g. $env:ChocolateyInstall\lib\awk), without regard to any registry changes.

So I would not expect that package to be affected.

Similarly, any packages that extract an archive with Install-ChocolateyZipPackage/Get-ChocolateyUnzip would not be affected, or well, the displayed install location would not be affected. This is because both of those helper functions set the install location explicitly, instead of trying to get the install location from the registry snapshot.

[Mooninaut]

I assumed this was merely a display bug, but I just experienced this issue when running choco upgrade all -y and I do have bad registry data. Choco updated Postman and then Temurin17, and the .registry file for Temurin contains uninstall keys for both Temurin17 and Postman.

It seems to me that an install script could contain a list of known registry prefixes such as HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{1D8E6291-B0D5-35EC-8441-6616F567A0F7} for vcredist2010.10.0.40219.32503 64-bit and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{F0C3E5D1-1ADE-321E-8167-68EF0DE699A5} for the 32-bit version, and chocolatey could use that to correctly associate keys with packages.

Obviously, that would be additional work for package maintainers, so I understand if that's not likely to happen, but it would prevent chocolatey from uninstalling unrelated packages.

[edit] It appears the chocolatey quality infrastructure performs an automated install/uninstall of each package, could that process be used to validate or even capture uninstall registry key prefixes?

[TheCakeIsNaOH]

@Mooninaut There is an issue open to allow filtering of the captured registry uninstall information: https://github.com/chocolatey/choco/issues/2513 Theoretically, there would not be any work required on the part of maintainers, as the pre-existing softwareName parameter would be utilized.