Could also confirm that it happened to me because of the moved Installer folder. Faced it on the 0.29 version of the PowerToys for the first time (not sure, but I think I created an Installer junction earlier)

The temporary fix by @eugenesvk helped, thanks!

I can confirm that this is indeed what @gee-ell said — if you move the C:\Windows\Installer to save space and put a symlink instead, then some of .msi installers stop working. As a workaround that doesn’t involve moving this useless multigig folder back and forth here is what I do:

• rename my C:\Windows\Installer symlink to C:\Windows\InstallerBackup,
• create a new C:\Windows\Installer folder
• install PowerToys
• move all the newly created folders/files from C:\Windows\Installer to my main Installer folder at drive D:\
• rename the symlink back to C:\Windows\Installer (from C:\Windows\InstallerBackup)

It’s a pity that the .msi is so broken if it’s not smart enough to allow installation to a symlink. Is there a chance you could use another installation packaging method that doesn’t rely on this broken system? Thank you!

I never has this problem again, and I updated at least 2 times after that incident. I thought it was already fixed? Im still using my ram drive and have no problems at all.

Delete all Config.Msi folders on the root of disk partition can fix this if you use junctions Windows\Installer.

@crutkas

detect ram disk in bootstrap installer

Unless there is an API, I don’t see how this can be done reliably. There are several RAM disk utilities, are we going to hard-code their process executable name and guess if we are installed from a temp folder on the RAM disk?

@enricogior I see these are possible options:

• detect ram disk in bootstrap installer
• have MSI see 2755 and we say “turn off your RAM disk”
• mark it as known issue

As far as I know this is an MSI issue, not a PT installer issue, we don’t treat the RAM disk any different and the error is from MSI not from the PT installer.

we’ll look into this issue. Good to also know it was on upgrade.

Did you download the EXE for 0.23.2 off the Github? or do the upgrade some other method?

I use my RAM drive for so long now (and it’s so convenient, having all temp files and browser caches going there) that I did not even think of it as a problem. It’s a drive like any other and booted up with windows so the temp folder is already there before it tries to access the folders.

Also, strange that a clean install is no problem, but an upgrade is.

Thank you for looking into it 😃

@gabefair, thanks for the insight, i would have never thought about someone using a RAM disk.

Yes, i usw a ram drive for my temp files, but certainly have never seen this before. After I cleaned all folders, rebooted again and installed the latest windows 10 optional update, followed by another reboot, I was able to install directly from the downloaded file.

Gabriel Fair notifications@github.com schrieb am Mo., 12. Okt. 2020, 02:55:

I found that this error can be caused with all .MSI installers if it is being run from a RAMDisk. It does not matter which type of ram disk dRAM mounted on the GPU or pRAM using physical ram (AMD Ramdisk for example)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/microsoft/PowerToys/issues/3115#issuecomment-706799975, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACZ3NZLBIRUDOUGOS7VTRZTSKJHW5ANCNFSM4NEK2N6Q .

I found that this error can be caused with all .MSI installers if the installer is being run from a RAMDisk. It does not matter which type of ram disk dRAM mounted on the GPU (GpuRamDrive for example) or pRAM using physical ram (AMD Ramdisk for example)

I was able to install Release v0.23.0 with no problems. It then told me there is an update and I encountered the above problem. Since then I can’t install Release v0.23.2, also after a clean reboot. No AV( Defender is running).

This is apparently caused when a user offloads the Windows/Installer folder to another location via a junction (or poss. other symlink). Just happened to me (because I did). It breaks many (but not all) installers.

The clue in the MSI log is “Found junction folder: C:\WINDOWS\Installer”.
More details: https://www.windowsdigitals.com/windows-installer-folder-cleanup-windows-10-safe-to-delete/

Don’t know if there’s a workaround (other than moving the folder back into place).