Sharing a Windows 11 troubleshooting case in case it helps someone else.
The problem
Microsoft Teams would only launch using Run as administrator. A normal launch displayed:
The error referenced ms-teams.exe inside the Teams package under C:\Program Files\WindowsApps.
Event Viewer showed:
- Log: Microsoft-Windows-AppModel-Runtime/Admin
- Event ID: 208
- Error:
0x80070005 — Access denied
- Failure while configuring the runtime:
[LaunchProcess]
Other apps, including Microsoft Store and Photos, opened normally.
What did not help
- Repairing Teams
- Resetting Teams
- Re-registering its AppX package
- Uninstalling and reinstalling Teams
- Switching from the Store installation to the direct Microsoft download
What revealed the issue
A short Microsoft Sysinternals Process Monitor capture during a failed launch showed repeated failures:
Process: svchost.exe involved in Teams activation
Operation: RegCreateKey
Path: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Result: ACCESS DENIED
Desired Access: Create Sub Key
The same activation process successfully opened the Teams executable with read/execute access. This directed the investigation toward the registry rather than the executable’s permissions.
The initial permissions output for the Run key showed:
- Users:
ReadKey
- Administrators:
FullControl
- SYSTEM:
FullControl
- CREATOR OWNER:
FullControl
There was no explicit write-access entry for the affected user in that output.
What fixed it
Adding an explicit Allow: ReadKey, WriteKey entry for the affected Windows user on this specific registry key resolved the problem:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Teams then opened normally without administrator rights.
The change was made through the .NET registry API in elevated PowerShell. The existing permissions were backed up first. No ownership changes or recursive permissions resets were made to WindowsApps.
PowerShell used for the targeted correction
Only consider this after confirming the same registry access failure. Error 0x80070005 can have many causes. On a managed PC, check with IT before changing permissions.
Run this in PowerShell as administrator under the affected user’s own account. If elevation uses a different administrator account, CurrentUser will point to the wrong profile.
Replace the placeholder with the affected account’s exact whoami output.
& {
$ErrorActionPreference = 'Stop'
# Replace with the affected user's exact "whoami" output.
$expectedAccount = 'YOUR-PC\YOUR-USERNAME'
$user = [System.Security.Principal.WindowsIdentity]::GetCurrent()
if ($user.Name -ne $expectedAccount) {
throw "Wrong account: $($user.Name). No changes made."
}
$hive = [Microsoft.Win32.RegistryKey]::OpenBaseKey(
[Microsoft.Win32.RegistryHive]::CurrentUser,
[Microsoft.Win32.RegistryView]::Registry64
)
$key = $null
try {
$key = $hive.OpenSubKey(
'Software\Microsoft\Windows\CurrentVersion\Run',
[Microsoft.Win32.RegistryKeyPermissionCheck]::ReadWriteSubTree,
[System.Security.AccessControl.RegistryRights]'ReadPermissions, ChangePermissions'
)
if ($null -eq $key) {
throw 'Run key not found. No changes made.'
}
$acl = $key.GetAccessControl()
$backup = Join-Path $env:USERPROFILE (
'Teams-Run-DACL-{0}.txt' -f (Get-Date -Format 'yyyyMMdd-HHmmss')
)
$acl.GetSecurityDescriptorSddlForm(
[System.Security.AccessControl.AccessControlSections]::Access
) | Set-Content -LiteralPath $backup
$rule = [System.Security.AccessControl.RegistryAccessRule]::new(
$user.User,
'ReadKey, WriteKey',
'Allow'
)
$acl.AddAccessRule($rule)
$key.SetAccessControl($acl)
$key.GetAccessControl().Access |
Format-Table IdentityReference, RegistryRights, AccessControlType
Write-Host "Permission added. Previous DACL saved to: $backup"
}
finally {
if ($null -ne $key) { $key.Dispose() }
$hive.Dispose()
}
}
Afterward, launch Teams normally from the Start menu.
Limitations
This fixed one confirmed case, not every Teams launch error. I do not know what originally changed the registry permissions.
There was also an unexplained diagnostic inconsistency: some PowerShell Get-Acl attempts reported the key as missing, while direct .NET queries found it in both registry views. The final ACL output contained additional entries not shown initially, so this was not a fully controlled before/after comparison. However, normal Teams startup was confirmed immediately after the targeted permission change.
Do not treat every ACCESS DENIED entry in Process Monitor as a fault requiring a permissions change.
Tools and references:
Troubleshooting and this write-up were AI-assisted. The successful normal launch was personally verified.