Automatic launch of non-UWP application in kiosk mode with autologon

Question

Automatic launch of non-UWP application in kiosk mode with autologon

dev 0

I created an executable (app.exe) that needs to be started automatically on a kiosk-mode workstation with autologon enabled. Issues encountered:

app.exe does not run correctly under non-administrator accounts: the launch fails or the application freezes when executed under standard kiosk-restricted users. I need app.exe to launch automatically only for the kiosk user.

When using Windows Configuration Designer to configure Shell Launcher, the shell change is also applied to the administrator account, forcing me to manually restore explorer.exe every time I log in as admin. I am requesting support on two items: ensuring app.exe can run under a standard kiosk user account, and configuring automatic startup of the application exclusively for the kiosk user without affecting the administrator profile

Harry Vo (WICLOUD CORPORATION) 3,505 Reputation points Microsoft External Staff Moderator

2025-11-27T09:37:47.9266667+00:00

Hi @dev , do you have any update?

1 answer

Your answer

Harry Vo (WICLOUD CORPORATION) 3,505 Reputation points Microsoft External Staff Moderator

2025-11-27T09:37:47.9266667+00:00

Hi @dev , do you have any update?

Answer 1

Danny Nguyen (WICLOUD CORPORATION) 5,065 Microsoft External Staff Moderator

Hi,

Since your app runs for admin but fails or freezes for a standard kiosk user, it could have been caused by:

App requires elevated rights (manifest set to requireAdministrator or trying privileged operations).
Writes to or expects write access in protected locations (e.g. C:\Program Files, HKLM, or system folders) causing silent failures under limited user.
Access denied on files/registry during initialization (unhandled exceptions lead to apparent “freeze”).
Attempts to start/communicate with a service or driver that isn’t installed or accessible to a standard user.
Uses global hooks, low‑numbered ports, or other privileged APIs that fail without elevation.
Hardcoded paths instead of per-user %LOCALAPPDATA% or %PROGRAMDATA%, resulting in missing resources or locked files.

Confirm by running the app as the kiosk user and using Process Monitor filtered to app.exe to spot ACCESS DENIED events.

I suggest trying the steps below:

Make the app run under the kiosk (standard) user:
- Change manifest to use asInvoker (not requireAdministrator).
- Move or redirect all writable data to %LOCALAPPDATA%\YourApp or %PROGRAMDATA%\YourApp.
- Grant Modify permission to Users only where truly needed.
- Test and fix any ACCESS DENIED outcomes found via ProcMon.

Assign the custom shell only to the kiosk user (keep Explorer for everyone else):

Ensure default shell is explorer.exe.
Map your app as shell for just the kiosk user SID.


   $namespace = "root\standardcimv2\embedded"

   $user = "KioskUser"

   $sid = (New-Object System.Security.Principal.NTAccount($user)).Translate([System.Security.Principal.SecurityIdentifier]).Value

   # Default shell for all other users

   Set-CimInstance -Namespace $namespace -ClassName WESL_UserSetting -Property @{ UserSid="*"; Shell="explorer.exe" }

   # Custom shell for kiosk user only

   Set-CimInstance -Namespace $namespace -ClassName WESL_UserSetting -Property @{ UserSid=$sid; Shell="C:\Kiosk\App\app.exe" }

Let me know if you have any update. I would love to help.

Danny Nguyen (WICLOUD CORPORATION) 5,065 Reputation points Microsoft External Staff Moderator

2025-11-21T08:55:26.7266667+00:00

Just checking in, do you still have any question regarding this post?
Danny Nguyen (WICLOUD CORPORATION) 5,065 Reputation points Microsoft External Staff Moderator

2025-11-21T08:56:43.23+00:00

Hi, just checking in. Do you have any more question regarding this post?
dev 0 Reputation points

2025-11-27T13:11:41.5933333+00:00

I tried this but still have the problem.
But if I create the kiosk user as admin and not as local user it works.
dev 0 Reputation points

2025-11-27T13:14:46.7133333+00:00

and also it looks like I can't use classname

Danny Nguyen (WICLOUD CORPORATION) 5,065 Microsoft External Staff Moderator

Thanks for the extra details.

Before kiosk/Shell Launcher, test this:

Create a normal local non‑admin user.
Log in as that user and run app.exe manually.
If it freezes or fails:
- Run ProcMon as admin, filter on Process Name = app.exe and Result contains ACCESS DENIED.
- Change the app so it uses %LOCALAPPDATA% / %PROGRAMDATA% and doesn’t write to C:\Program Files, HKLM, etc..

I found this document on configuring Shell Launcher with the WMI provider https://learn.microsoft.com/en-us/windows/configuration/shell-launcher/configure-wmi

Instead of Set-CimInstance -ClassName ..., use the WESL_UserSetting WMI class like this :


$namespace  = "root\standardcimv2\embedded"

$shellClass = [wmiclass]"\\localhost\$namespace:WESL_UserSetting"

function Get-UserSID($AccountName) {

    $nt = New-Object System.Security.Principal.NTAccount($AccountName)

    $sid = $nt.Translate([System.Security.Principal.SecurityIdentifier])

    $sid.Value

}

$kioskUser = "KioskUser"                 # your kiosk account

$kioskSid  = Get-UserSID $kioskUser

$kioskApp  = "C:\Kiosk\App\app.exe"      # your app path

# Default shell for everyone else (admin included)

$shellClass.SetCustomShell("*", "explorer.exe", $null, $null, 0) | Out-Null

# Custom shell only for kiosk user

$shellClass.SetCustomShell($kioskSid, $kioskApp, $null, $null, 0) | Out-Null

# Enable Shell Launcher

$shellClass.SetEnabled($true) | Out-Null

If this still creates errors, check:


Get-WindowsOptionalFeature -Online -FeatureName Client-EmbeddedShellLauncher

And enable it if needed:


Enable-WindowsOptionalFeature -Online -FeatureName Client-EmbeddedShellLauncher -All

Let me know if any errors come up

dev 0 Reputation points

2025-12-01T19:05:56.6366667+00:00

I already did this and still doesn't work. I am afraid is cert problem because my app is auto signed.
Danny Nguyen (WICLOUD CORPORATION) 5,065 Reputation points Microsoft External Staff Moderator

2025-12-02T04:56:39.0933333+00:00
If you suspect a certificate/signing issue (auto-signed EXE), that can definitely cause a non-admin kiosk user to fail launching the app. Try checking these steps

Manifest (uiAccess)

If uiAccess="true" your EXE must be code‑signed with a cert that chains to a trusted root AND installed in Program Files or Windows directories. Otherwise it simply won’t launch for a standard user.

Easiest fix: set uiAccess="false" unless you truly need it. Application manifests / UIPI: https://learn.microsoft.com/windows/win32/sbscs/application-manifests

Code signing & trust

Self/auto-signed cert must be trusted: import root cert to Local Machine → Trusted Root Certification Authorities; publisher cert to Trusted Publishers.

Use a timestamp when signing so it remains valid after cert expiry. Authenticode & cert stores: https://learn.microsoft.com/windows/win32/seccrypto/time-stamping-authenticode-signatures https://learn.microsoft.com/windows/win32/seccrypto/system-store-locations

SmartScreen / Mark of the Web (MOTW)

Files with MOTW or unknown publisher reputation may be blocked or prompt silently in kiosk. Deliver via trusted channel or sign properly.

Quick validation steps

Check signature:
Get-AuthenticodeSignature "C:\Kiosk\App\app.exe"
Status should be Valid.

Baseline test: log in as a normal non-admin user (outside kiosk) and run the EXE directly. It must start cleanly before Shell Launcher will appear reliable.

Share via

Automatic launch of non-UWP application in kiosk mode with autologon

1 answer

Your answer