warning 1946 on install

[Hifilo]

Describe the bug

updating to new version gave Warning 1946. Property 'System.AppUserModel.ID' for shortcut 'Classic Explorer Settings.lnk' could not be set.

Area of issue

Installation/Other

To reproduce

go through update process. update downloaded to download folder. run installer.

Expected behavior

no errors or warnings

Open-Shell version

latest -1 -> latest

Windows version

10.0.19045 Build 19045

Additional context

No response

[ge0rdi]

Such warning is typically reported on Windows7 as it doesn't recognize System.AppUserModel.ID property name. https://learn.microsoft.com/en-us/troubleshoot/windows/win32/warning-1946-when-you-install-installer-package

Windows 10 should recognize it without a problem, so its weird.

If you are able to replicate it, please, provide log from installer obtained by running setup with this parameter: OpenShellSetup_4_4_190.exe /lvx* install.log

[Hifilo]

Thanks @ge0rdi.

So I ran the installer with the parameter, but used it to repair the current install.

It asked to close windows explorer, so I complied. it gave a bunch of errors similar to the original one.

The log is attached.

install.log

[ge0rdi]

So it seems that there is some issue with writing to:

• Classic Explorer Settings.lnk
• Open-Shell Menu Settings.lnk
• Classic IE Settings.lnk

The error code should be 1307 (ERROR_INVALID_OWNER), so maybe some issue with permissions? It is also weird that it succeeds for:

• IE Settings.lnk
• Start Menu Settings.lnk

But shortcuts with such names shouldn't even be created (maybe they were named like that in some very old version?).

Could you provide output of: dir /Q "%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Open-Shell" icacls "%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Open-Shell\*"

[Hifilo]

so maybe some issue with permissions?

Yeah that seems likely. It's a mix currently. Some are behind NT Authority/system, and some are under my profile

openshell.txt

[ge0rdi]

Ok, so its pretty weird and I'm even more confused now :)

Maybe you can just remove that Open-Shell folder completely and then run reinstall/repair.

[Hifilo]

okay fair enough. how should those outputs look if they were correct?

[ge0rdi]

Like this:

08/23/2023  06:08 PM    <DIR>          NT AUTHORITY\SYSTEM    .
08/23/2023  06:08 PM    <DIR>          NT AUTHORITY\SYSTEM    ..
08/23/2023  06:08 PM             1,284 NT AUTHORITY\SYSTEM    Classic Explorer Settings.lnk
08/23/2023  06:08 PM             1,075 NT AUTHORITY\SYSTEM    Open-Shell Help.lnk
08/23/2023  06:08 PM             1,220 NT AUTHORITY\SYSTEM    Open-Shell Menu Settings.lnk
08/23/2023  06:08 PM             1,109 NT AUTHORITY\SYSTEM    Open-Shell Readme.lnk
08/23/2023  06:08 PM             1,206 NT AUTHORITY\SYSTEM    Open-Shell Update.lnk

[Tki2000]

Same issue here.

OpenShell version : 4.4.191 Windows Version : Windows Server 2022 - 20348.1850 Ran as administrator.

Seems that W7 is not the only one missing that property. Or the error is bad reported.

Rebooted. Not tested deeply but seems to be working OK. Can't say what the error ment or its implications. (It is not an error but a warning)

[ge0rdi]

@Tki2000 You can try to delete %ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Open-Shell folder completely and then run installer again.

In case of OP it seems to be some weird issue with permissions of those LNK files inside.

[Hifilo]

Just to follow up on what @Tki2000 posted, it worked even after giving me errors post install. If this isn't really an issue feel free to close.

[ge0rdi]

@Hifilo Did you try to delete that folder and run installer again?

[zluts]

In case someone finds this threat in '24 with W11 and the latest version to date: killing the explorer.exe process during (repair) setup resulted in a successful installation. (killing kaspersky AV or resetting the rights of everyone to full control in %ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Open-Shell didn't resolve the issue)

[11v1]

I experienced this issue with other MSI-based installers. The msi does the following:

1. Write the *.lnk file to a file system
2. Open the *.lnk file in exclusive mode with share mode = none. If the file is opened by some other process it fails and shows dialog with error in the first message. So why the file could be opened? It might be an antivirus program (as in my case) or some backup application or anything. The question is does the msi really require exclusive file access or it's an error?