guidox / Security
Read the manifest with **sigcheck -m**, check what the app touches with Procmon, and fix the path or the permission. A **RunAsInvoker** shim is a diagnosis, not a permanent answer.
A manifest with **requestedExecutionLevel level=asInvoker** needs no elevation; **requireAdministrator** asks for it by design. The difference decides everything that follows.
sigcheck64.exe -accepteula -m "C:\Program Files\Tool\tool.exe" | Select-String -Pattern 'requestedExecutionLevel'
Get-Item "C:\Program Files\Tool\tool.exe" | Select-Object VersionInfoStart Procmon with a filter on the process, then launch the app. An access denied on a file or a registry key in the first seconds is the actual reason it wants admin rights.
procmon64.exe /Accepteula /Quiet /Minimized /BackingFile C:\tool.pml
Start-Process "C:\Program Files\Tool\tool.exe"
Start-Sleep -Seconds 20
procmon64.exe /TerminateThe Procmon filter for Result is ACCESS DENIED narrows the trace to the blocked operations. Write access to Program Files is the most common finding.
# Procmon: Filter > Result is ACCESS DENIED > Apply
# read the Path column, note the folder or key
Test-Path 'C:\Program Files\Tool\settings.ini'
Get-Acl 'C:\Program Files\Tool' | Select-Object -ExpandProperty Access | Select-Object IdentityReference,FileSystemRightsA junction or a config change keeps the app out of Program Files. When the app hard-codes the path, grant write access to that one folder for the current user instead of the whole app.
New-Item -ItemType Directory "$env:APPDATA\Tool" -Force | Out-Null
icacls "C:\Program Files\Tool\config" /grant "$env:USERNAME:(OI)(CI)M" /T
icacls "C:\Program Files\Tool\config" | Select-Object -First 5**RunAsInvoker** makes the process start without a prompt, which shows whether the app works at all. Use it as an experiment, not as the final state.
reg add "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "C:\Program Files\Tool\tool.exe" /t REG_SZ /d "RunAsInvoker" /f
& "C:\Program Files\Tool\tool.exe"A vendor update is the clean answer. A per-folder permission is the pragmatic one. Running the tool from a separate admin account is the last resort when neither is available.
reg delete "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "C:\Program Files\Tool\tool.exe" /f
runas /user:PC01\AdminBackup "C:\Program Files\Tool\tool.exe"
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers' -ErrorAction SilentlyContinueThe shortcut is marked Run as administrator, or an installer set the RUNASADMIN flag. Check the shortcut's Advanced properties and the AppCompatFlags key.
That is the RunAsInvoker shim failing silently. Grant write access to the config folder and remove the shim.
The app elevates before it touches anything. Start Procmon with a filter on the elevated process name, not the parent.
The app also writes to HKLM. Check the registry paths in the trace and grant access to that key for the same user.
No. A disabled UAC applies to everything. A shim or a permission on one folder is scoped to the app.
The admin token can write to protected locations. That confirms the cause but does not make the daily use of admin acceptable.
For path and permission problems yes. If the app loads a kernel driver or writes to System32, only the vendor can change it.
Delete the AppCompatFlags Layers value for the executable, remove any icacls grant you added with icacls "path" /remove:g "user", and restart the app.
Free · no account needed · tracks your progress