Problem installation only with "user account" privileges

[Pairi Daiza]

Hello, Happy New Year to all Support team.

I'm having trouble installing Notepad3 ONLY when I install it from a "user account" without administrator privileges.

The problem is that a portion of the [Code] is not executed! 🤔

When I try to new Install of Notepad3 from a user without Admin privilege:
- As usual, it ask for the Admin PW, and the installation is correctly executed without error.
- All files are copied to the chosen directory. 👍
- All registry-related [Code] operations are also performed correctly. 👍

But NOTHING happens when related with the user "%Appdata%" directories 👎
- The "%Appdata%" directories are NOT created (Rizonesoft, Notepad3, Themes, Favorites) !!!
- And the User *.ini files of NP3 and the Themes files are also NOT copied (Notepad3.ini + Minipath.ini, Dark.ini, Obsidian.ini, Sombra.ini) !!!
If I add manually the directories and the *.ini files, everything works correctly.

I'm wondering why part of the [code] is NOT being executed (the part related to "%Appdata%" directories) !!!  🤔

Could you please help me?

hpwamr

[Martijn Laan]

Hi,

When the installer is running elevated (with admin privileges), it cannot reliably access or write to the invoking user’s profile directories (such as %AppData%). This is expected Windows behavior and not an Inno Setup limitation. In an elevated context, %AppData% may resolve to a different profile/context than the user who started the installer, so “per-user” files/directories may be created somewhere else (and therefore appear to be missing for the user).

Also note that Microsoft is introducing an “Administrator Protection” feature. With this change, elevated processes run in a more isolated context, which further prevents elevated installers from writing per-user data in a way that will be visible to the launching user. In practice it can look as if those %AppData% writes “disappear”.

If the Notepad3 installer expects to create/copy files into the invoking user’s %AppData% during an elevated install, you should contact the Notepad3 installer authors about adjusting their installation logic.

Best regards,
Martijn

Op 5-1-2026 om 17:13 schreef Pairi Daiza:

--
You received this message because you are subscribed to the Google Groups "innosetup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to innosetup+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/innosetup/33d2c56d-c8be-4439-9157-116bb8440d74n%40googlegroups.com.

[Pairi Daiza]

Thank you Martijn for this detailed answer. 

Have a nice day,

hpwamr

[Derick Payne (Derick)]

Hi all,

For those looking for a solution to this exact problem, I've published an open-source DLL that uses the WTS Session API to reliably detect the original desktop user during elevated installations—without triggering antivirus false positives.

GitHub: https://github.com/rizonesoft/GetOriginalUser
Discussion thread: https://groups.google.com/g/innosetup/c/0OimKiKkXoM

It also handles enterprise/Session 0 scenarios (SCCM, Intune) where no interactive user exists.

[Gavin Lambert]

On Sunday, January 25, 2026 at 6:49:47 AM UTC+13 Derick Payne (Derick) wrote:

For those looking for a solution to this exact problem, I've published an open-source DLL that uses the WTS Session API to reliably detect the original desktop user during elevated installations—without triggering antivirus false positives.

While this might be useful for other problems, this is still the wrong solution for this sort of issue.

When an app is installed for all users (admin install) it must do exactly that: install for all users.  This means that it should install all files to per-machine locations only, and leave installation of per-user files to the application startup instead.  Otherwise if a different user from either the admin or the desktop user tries to run the app, something may be missing; the app needs to be able to gracefully recover from this anyway.