I'm working on a PowerShell utility for repairing broken AppX execution aliases, including the endless "Open With…" loop that occurs when Windows cannot resolve an alias in `%USERPROFILE%AppDataLocalMicrosoftWindowsApps`. Two issues have been especially difficult. First, `Remove-Item -Force` can fail with `ItemNotFound` or `AccessDenied` when the alias is a damaged NTFS reparse point, so I added a fallback using .NET file deletion and, if necessary, `cmd.exe`. Second, running the script from an elevated terminal can make `$env:USERPROFILE` and `HKCU` refer to the administrator rather than the affected interactive user. The utility therefore tries to identify the correct user SID through the ownership and session information of `explorer.exe`, then works against that user's hive under `HKEY_USERS`. It also creates timestamped registry backups and uses timeout-aware verification loops. I'm looking for feedback on safer reparse-point cleanup, reliable user/session detection in environments with fast user switching or multiple sessions, and whether native tools should be preferred over registry and deletion fallbacks.
4 Answers
Selecting the first `explorer.exe` process is not reliable. A machine can have multiple interactive sessions because of fast user switching, Remote Desktop, or Terminal Services. The script should inspect every Explorer process, collect its owner and session ID, and select the session that matches the intended logged-in user rather than assuming the first result is correct.
Before deleting links or editing another user’s registry hive, try the native NTFS repair tools. `fsutil reparsepoint` can inspect or remove a reparse point, while `takeown` and `icacls` may resolve ownership and permission problems. Depending on the failure, checking the short filename with `dir /x` or releasing an orphaned handle may also avoid a destructive fallback. These options should probably be attempted before changing registry state or forcing deletion.
A staged approach makes sense: inspect and back up first, try the least intrusive native operation, and only then use a more forceful cleanup method when the error clearly indicates a damaged alias.
The .NET deletion plus `cmd.exe` fallback may work, but it should be tightly guarded. Confirm that the path is the expected WindowsApps alias, inspect its attributes and reparse metadata, and avoid treating every access error as proof that forced deletion is appropriate. Also record the exact failure and exit code so the repair can distinguish a missing target, ACL problem, open handle, and genuinely corrupt reparse point.
The approach appears to have helped with a separate case where an obsolete `winget` executable earlier in `PATH` shadowed the official AppExecutionAlias. Scanning for conflicting binaries and reporting their locations can be useful, but changing protected files should still require explicit confirmation and a clear backup or rollback path.
That same distinction matters when the elevated shell belongs to a different account. Resolving the target SID from an explicit session or user selection would be safer than silently choosing one Explorer process.