starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Windows Terminal crash with wt.exe #16375

New Issue
Closed
opened 2026-01-31 05:05:37 +00:00 by claunia · 24 comments
claunia commented 2026-01-31 05:05:37 +00:00
Owner
Copy Link

Originally created by @SanokKule on GitHub (Jan 11, 2022).

Windows Terminal version

1.11.3471.0

Windows build number

10.0.22000.0

Other Software

No response

Steps to reproduce

Open wt.exe through Run dialogue

Expected Behavior

Windows Terminal opens

Actual Behavior

Terminal crashes with the following in event viewer:

Faulting application name: WindowsTerminal.exe, version: 1.11.2112.13011, time stamp: 0x61b80d0f
Faulting module name: ucrtbase.dll, version: 10.0.22000.1, time stamp: 0x00e78ce9
Exception code: 0xc0000409
Fault offset: 0x000000000007dd7e
Faulting process id: 0x1258
Faulting application start time: 0x01d8071ba1f2ffd9
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report Id: cec35c5c-ee1a-4023-a45a-735874feae98
Faulting package full name: 
Faulting package-relative application ID:
Originally created by @SanokKule on GitHub (Jan 11, 2022). ### Windows Terminal version 1.11.3471.0 ### Windows build number 10.0.22000.0 ### Other Software _No response_ ### Steps to reproduce Open wt.exe through Run dialogue ### Expected Behavior Windows Terminal opens ### Actual Behavior Terminal crashes with the following in event viewer: ``` Faulting application name: WindowsTerminal.exe, version: 1.11.2112.13011, time stamp: 0x61b80d0f Faulting module name: ucrtbase.dll, version: 10.0.22000.1, time stamp: 0x00e78ce9 Exception code: 0xc0000409 Fault offset: 0x000000000007dd7e Faulting process id: 0x1258 Faulting application start time: 0x01d8071ba1f2ffd9 Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Faulting module path: C:\WINDOWS\System32\ucrtbase.dll Report Id: cec35c5c-ee1a-4023-a45a-735874feae98 Faulting package full name: Faulting package-relative application ID: ```
claunia commented 2026-01-31 05:05:39 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 11, 2022):

/feedback

@zadjii-msft commented on GitHub (Jan 11, 2022): /feedback
claunia commented 2026-01-31 05:05:39 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jan 11, 2022):

Hi there!

Can you please send us feedback with the Feedback Hub with this issue? Make sure to click the "Start recording" button, then reproduce the issue before submitting the feedback. Once it's submitted, paste the link here so we can more easily find your crash information on the back end?

Thanks!

image

image

image

@ghost commented on GitHub (Jan 11, 2022): Hi there!<br><br>Can you please send us feedback with the [Feedback Hub](https://support.microsoft.com/en-us/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332) with this issue? Make sure to click the "Start recording" button, then reproduce the issue before submitting the feedback. Once it's submitted, paste the link here so we can more easily find your crash information on the back end?<br><br>Thanks!<br><br>![image](https://user-images.githubusercontent.com/18356694/140811502-a068f78b-89d2-4587-925a-73e19652b830.png)<br><br>![image](https://user-images.githubusercontent.com/18356694/140811557-cdc22a0f-fa6a-4f6a-953e-73b51f5548a3.png)<br><br>![image](https://user-images.githubusercontent.com/18221333/62478649-6de55400-b760-11e9-806e-5aab7e085a9f.png)
claunia commented 2026-01-31 05:05:39 +00:00
Author
Owner
Copy Link

@SanokKule commented on GitHub (Jan 12, 2022):

Sorry for late reply https://aka.ms/AAfgcd8

@SanokKule commented on GitHub (Jan 12, 2022): Sorry for late reply https://aka.ms/AAfgcd8
claunia commented 2026-01-31 05:05:40 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 12, 2022):

Huh. There's just nothing in there... it seems to think there was a crash in diagtrack.dll, which isn't a useful bucket 😕. Did the Terminal used to work for you (maybe on an earlier Terminal version)? Did you get an OS update? Is there any error message that pops up when you launch the Terminal, or does it only log the message to event viewer?

(to save myself time in the future: DeviceId=g:6755424567712494)

@zadjii-msft commented on GitHub (Jan 12, 2022): Huh. There's just nothing in there... it seems to think there was a crash in `diagtrack.dll`, which isn't a useful bucket 😕. Did the Terminal used to work for you (maybe on an earlier Terminal version)? Did you get an OS update? Is there any error message that pops up when you launch the Terminal, or does it only log the message to event viewer? (to save myself time in the future: `DeviceId=g:6755424567712494`)
claunia commented 2026-01-31 05:05:40 +00:00
Author
Owner
Copy Link

@SanokKule commented on GitHub (Jan 12, 2022):

I think it worked somewhere around november but then stopped, i didn't bother trying to fix it back then.

Is there any error message that pops up when you launch the Terminal

Nope, just cursor changing to "working in background" for like two seconds.

@SanokKule commented on GitHub (Jan 12, 2022): I think it worked somewhere around november but then stopped, i didn't bother trying to fix it back then. > Is there any error message that pops up when you launch the Terminal Nope, just cursor changing to "working in background" for like two seconds.
claunia commented 2026-01-31 05:05:40 +00:00
Author
Owner
Copy Link

@SanokKule commented on GitHub (Jan 12, 2022):

I have tried Repairing, clearing settings and reinstalling, nothing worked.

@SanokKule commented on GitHub (Jan 12, 2022): I have tried Repairing, clearing settings and reinstalling, nothing worked.
claunia commented 2026-01-31 05:05:40 +00:00
Author
Owner
Copy Link

@SanokKule commented on GitHub (Jan 12, 2022):

To be clear launching it through app icon in start of by this two .exe works

  • C:\Users\SanokKule\AppData\Local\Microsoft\WindowsApps\wt.exe
  • C:\Users\SanokKule\AppData\Local\Microsoft\WindowsApps\Microsoft.WindowsTerminal_8wekyb3d8bbwe\wt.exe

It crashes only when trying to launch wt.exe through Run or with wt.exe or WindowsTerminal.exe from C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe

@SanokKule commented on GitHub (Jan 12, 2022): To be clear launching it through app icon in start of by this two .exe works - `C:\Users\SanokKule\AppData\Local\Microsoft\WindowsApps\wt.exe` - `C:\Users\SanokKule\AppData\Local\Microsoft\WindowsApps\Microsoft.WindowsTerminal_8wekyb3d8bbwe\wt.exe` It crashes only when trying to launch wt.exe through Run or with wt.exe or WindowsTerminal.exe from `C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe`
claunia commented 2026-01-31 05:05:41 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 12, 2022):

It crashes only when trying to launch wt.exe through Run

INTERESTING. What does your %path% look like? Because C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe should most certainly not be in there. It's totally expected that running C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe\wt.exe won't work, but it's unexpected that run should ever be finding that one 😄

@zadjii-msft commented on GitHub (Jan 12, 2022): > It crashes only when trying to launch wt.exe through Run INTERESTING. What does your %path% look like? Because `C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe` should most certainly not be in there. It's totally expected that running `C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe\wt.exe` won't work, but it's unexpected that run should ever be finding that one 😄
claunia commented 2026-01-31 05:05:41 +00:00
Author
Owner
Copy Link

@SanokKule commented on GitHub (Jan 12, 2022):

It crashes only when trying to launch wt.exe through Run

INTERESTING. What does your %path% look like? Because C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe should most certainly not be in there. It's totally expected that running C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe\wt.exe won't work, but it's unexpected that run should ever be finding that one 😄

It's not in path, only c:\users\sanokkule\appdata\local\microsoft\windowsapps is there in both user and system variables.

@SanokKule commented on GitHub (Jan 12, 2022): > > It crashes only when trying to launch wt.exe through Run > > INTERESTING. What does your %path% look like? Because `C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe` should most certainly not be in there. It's totally expected that running `C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.11.3471.0_x64__8wekyb3d8bbwe\wt.exe` won't work, but it's unexpected that run should ever be finding that one 😄 It's not in path, only `c:\users\sanokkule\appdata\local\microsoft\windowsapps` is there in both user and system variables.
claunia commented 2026-01-31 05:05:41 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 12, 2022):

Huh. What does powershell -NoExit -Command Write-Output ${env:path} from the Run dialog output? I'm worried that the run dialog is running with a different PATH for some reason...

@zadjii-msft commented on GitHub (Jan 12, 2022): Huh. What does `powershell -NoExit -Command Write-Output ${env:path}` from the Run dialog output? I'm worried that the run dialog is running with a different PATH for some reason...
claunia commented 2026-01-31 05:05:42 +00:00
Author
Owner
Copy Link

@SanokKule commented on GitHub (Jan 12, 2022):

c:\program files\eclipse foundation\jdk-8.0.302.8-hotspot\bin;
c:\windows;
c:\windows\system32;
c:\windows\system32\windowspowershell\v1.0\;
c:\windows\system32\wbem;
c:\windows\system32\openssh;
c:\program files\7-zip;
c:\program files\dotnet\;
c:\program files\ffmpeg\;
c:\program files\mkvtoolnix\;
c:\program files\mpv\;
c:\program files\process lasso\;
c:\program files (x86)\streamlink\bin;
c:\program files (x86)\fahclient\;
c:\program files (x86)\adb platform tools\;
c:\programdata\chocolatey\bin;
c:\temp\tools\bcurran3;
c:\other\apps\;
c:\other\apps\tshell\;
C:\WINDOWS\system32;
C:\WINDOWS;
C:\WINDOWS\system32\wbem;
C:\WINDOWS\system32\windowspowershell\v1.0\;
C:\WINDOWS\system32\openssh\;
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;
C:\Program Files (x86)\ZeroTier\One\;
c:\users\sanokkule\appdata\local\microsoft\windowsapps;
C:\Users\SanokKule\AppData\Local\Microsoft\WindowsApps;
C:\Users\SanokKule\AppData\Local\Programs\Python\Python39\Scripts\;
C:\Users\SanokKule\AppData\Local\Programs\Python\Python39\;
C:\Users\SanokKule\AppData\Local\Programs\Python\Launcher\;
C:\Program Files (x86)\FAHClient;
E:\Steam\steamapps\common\GarrysMod\bin;
@SanokKule commented on GitHub (Jan 12, 2022): > ``` c:\program files\eclipse foundation\jdk-8.0.302.8-hotspot\bin; c:\windows; c:\windows\system32; c:\windows\system32\windowspowershell\v1.0\; c:\windows\system32\wbem; c:\windows\system32\openssh; c:\program files\7-zip; c:\program files\dotnet\; c:\program files\ffmpeg\; c:\program files\mkvtoolnix\; c:\program files\mpv\; c:\program files\process lasso\; c:\program files (x86)\streamlink\bin; c:\program files (x86)\fahclient\; c:\program files (x86)\adb platform tools\; c:\programdata\chocolatey\bin; c:\temp\tools\bcurran3; c:\other\apps\; c:\other\apps\tshell\; C:\WINDOWS\system32; C:\WINDOWS; C:\WINDOWS\system32\wbem; C:\WINDOWS\system32\windowspowershell\v1.0\; C:\WINDOWS\system32\openssh\; C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common; C:\Program Files (x86)\ZeroTier\One\; c:\users\sanokkule\appdata\local\microsoft\windowsapps; C:\Users\SanokKule\AppData\Local\Microsoft\WindowsApps; C:\Users\SanokKule\AppData\Local\Programs\Python\Python39\Scripts\; C:\Users\SanokKule\AppData\Local\Programs\Python\Python39\; C:\Users\SanokKule\AppData\Local\Programs\Python\Launcher\; C:\Program Files (x86)\FAHClient; E:\Steam\steamapps\common\GarrysMod\bin; ```
claunia commented 2026-01-31 05:05:42 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 12, 2022):

Welp, I'm officially at a loss. I don't know why the Run dialog would be picking that one. By all accounts, it doesn't make any sense. Maybe @DHowett has a better idea, he's often got a better head for these weird platform quirks.

@zadjii-msft commented on GitHub (Jan 12, 2022): Welp, I'm officially at a loss. I don't know why the Run dialog would be picking that one. By all accounts, it doesn't make any sense. Maybe @DHowett has a better idea, he's often got a better head for these weird platform quirks.
claunia commented 2026-01-31 05:05:43 +00:00
Author
Owner
Copy Link

@237dmitry commented on GitHub (Jan 12, 2022):

I don't know why the Run dialog would be picking that one.

Need to look in some unusual place for wt.exe in $env:Path. where.exe does not view symbolic links:

$Env:Path -split ';' | ForEach-Object {
    if (Test-Path "$($_)\wt.exe") { Get-Item "$($_)\wt.exe" }
}
@237dmitry commented on GitHub (Jan 12, 2022): > I don't know why the Run dialog would be picking that one. Need to look in some unusual place for wt.exe in $env:Path. `where.exe` does not view symbolic links: ``` $Env:Path -split ';' | ForEach-Object { if (Test-Path "$($_)\wt.exe") { Get-Item "$($_)\wt.exe" } } ```
claunia commented 2026-01-31 05:05:43 +00:00
Author
Owner
Copy Link

@SanokKule commented on GitHub (Jan 12, 2022):

I don't know why the Run dialog would be picking that one.

Need to look in some unusual place for wt.exe in $env:Path. where.exe does not view symbolic links:

$Env:Path -split ';' | ForEach-Object {
    if (Test-Path "$($_)\wt.exe") { Get-Item "$($_)\wt.exe" }
}

    Directory: C:\users\sanokkule\appdata\local\microsoft\windowsapps

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
la---          11.01.2022    22:52              0 wt.exe ->
la---          11.01.2022    22:52              0 wt.exe ->
@SanokKule commented on GitHub (Jan 12, 2022): > > I don't know why the Run dialog would be picking that one. > > Need to look in some unusual place for wt.exe in $env:Path. `where.exe` does not view symbolic links: > > ``` > $Env:Path -split ';' | ForEach-Object { > if (Test-Path "$($_)\wt.exe") { Get-Item "$($_)\wt.exe" } > } > ``` ``` Directory: C:\users\sanokkule\appdata\local\microsoft\windowsapps Mode LastWriteTime Length Name ---- ------------- ------ ---- la--- 11.01.2022 22:52 0 wt.exe -> la--- 11.01.2022 22:52 0 wt.exe -> ```
claunia commented 2026-01-31 05:05:43 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 12, 2022):

So, this is really interesting!

FYI - the "links" there are not actually links, they're special app execution alias reparse points. You can read their contents with fsutil reparsepoint query C:\PATH\TO\FILE.

What's happening to you is more complicated than that, though.

The installation of Terminal automatically adds an entry to AppPaths. This is a registry key that Explorer uses for the Run dialog. That registry entry points at C:\Program Files\WindowsApps\...terminal...\wt.exe. This is normal and expected (well OK, a little weird.)

On a normally configured system, the ACLs on WindowsApps prevent you from accessing that file, and it generates an ACCESS_DENIED error. That error is caught and handled: CreateProcess explicitly checks to see if the file is in an app package, and if so, re-executes it "inside" that package. It turns out that that access denied error is very important in launching a packaged application. ☹️

If you have modified the ACLs on C:\Program Files\WindowsApps, you will not get the access denied error and Terminal will be launched "outside" of its package. This can cause all sorts of issues, like one where you seem to have two different copies of terminal installed with different settings!

Can you check the ACLs on that directory?

REM As admin:
icacls "C:\Program Files\WindowsApps"

There's more information and a potential remediation at #9452.

@DHowett commented on GitHub (Jan 12, 2022): So, this is really interesting! FYI - the "links" there are not actually links, they're special app execution alias reparse points. You can read their contents with `fsutil reparsepoint query C:\PATH\TO\FILE`. What's happening to you is more complicated than that, though. The installation of Terminal automatically adds an entry to `AppPaths`. This is a registry key that Explorer uses _**for the Run dialog**_. That registry entry points at `C:\Program Files\WindowsApps\...terminal...\wt.exe`. This is normal and expected (well OK, a little weird.) On a normally configured system, the ACLs on `WindowsApps` prevent you from accessing that file, and it generates an `ACCESS_DENIED` error. That error is caught and handled: `CreateProcess` explicitly checks to see if the file is in an app package, and if so, re-executes it "inside" that package. It turns out that that access denied error is *very important* in launching a packaged application. ☹️ If you have modified the ACLs on `C:\Program Files\WindowsApps`, you will not get the access denied error and Terminal will be launched "outside" of its package. This can cause all sorts of issues, like one where you seem to have two different copies of terminal installed with different settings! Can you check the ACLs on that directory? ```batch REM As admin: icacls "C:\Program Files\WindowsApps" ``` There's more information and a potential remediation at #9452.
claunia commented 2026-01-31 05:05:44 +00:00
Author
Owner
Copy Link

@237dmitry commented on GitHub (Jan 12, 2022):

I don't know what to advise, try to remove from PATH one of two C:\users\sanokkule\appdata\local\microsoft\windowsapps

@237dmitry commented on GitHub (Jan 12, 2022): I don't know what to advise, try to remove from `PATH` one of two `C:\users\sanokkule\appdata\local\microsoft\windowsapps`
claunia commented 2026-01-31 05:05:45 +00:00
Author
Owner
Copy Link

@SanokKule commented on GitHub (Jan 12, 2022):

icacls "C:\Program Files\WindowsApps" ```

PS C:\Users\SanokKule> icacls "C:\Program Files\WindowsApps"
C:\Program Files\WindowsApps NT SERVICE\TrustedInstaller:(F)
                             NT SERVICE\TrustedInstaller:(OI)(CI)(IO)(F)
                             S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204:(RX)
                             S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204:(OI)(CI)(IO)(RX)
                             NT AUTHORITY\SYSTEM:(F)
                             NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
                             BUILTIN\Администраторы:(CI)(RX)
                             NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(RX)
                             NT AUTHORITY\NETWORK SERVICE:(OI)(CI)(RX)
                             NT AUTHORITY\RESTRICTED:(OI)(CI)(RX)
                             BUILTIN\Пользователи:(Rc,S,RD,REA,X,RA)
                             SK106B-PC1\SanokKule:(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files

On a normally configured system, the ACLs on WindowsApps prevent you from accessing that file, and it generates an ACCESS_DENIED error. That error is caught and handled: CreateProcess explicitly checks to see if the file is in an app package, and if so, re-executes it "inside" that package. It turns out that that access denied error is very important in launching a packaged application. ☹️

If you have modified the ACLs on C:\Program Files\WindowsApps, you will not get the access denied error and Terminal will be launched "outside" of its package. This can cause all sorts of issues, like one where you seem to have two different copies of terminal installed with different settings!

Oh i see, so i need to restore permissions on that folder to defaults and it may be fixed?

@SanokKule commented on GitHub (Jan 12, 2022): > icacls "C:\Program Files\WindowsApps" ``` ``` PS C:\Users\SanokKule> icacls "C:\Program Files\WindowsApps" C:\Program Files\WindowsApps NT SERVICE\TrustedInstaller:(F) NT SERVICE\TrustedInstaller:(OI)(CI)(IO)(F) S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204:(RX) S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204:(OI)(CI)(IO)(RX) NT AUTHORITY\SYSTEM:(F) NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F) BUILTIN\Администраторы:(CI)(RX) NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(RX) NT AUTHORITY\NETWORK SERVICE:(OI)(CI)(RX) NT AUTHORITY\RESTRICTED:(OI)(CI)(RX) BUILTIN\Пользователи:(Rc,S,RD,REA,X,RA) SK106B-PC1\SanokKule:(OI)(CI)(F) Successfully processed 1 files; Failed processing 0 files ``` > On a normally configured system, the ACLs on `WindowsApps` prevent you from accessing that file, and it generates an `ACCESS_DENIED` error. That error is caught and handled: `CreateProcess` explicitly checks to see if the file is in an app package, and if so, re-executes it "inside" that package. It turns out that that access denied error is _very important_ in launching a packaged application. ☹️ > > If you have modified the ACLs on `C:\Program Files\WindowsApps`, you will not get the access denied error and Terminal will be launched "outside" of its package. This can cause all sorts of issues, like one where you seem to have two different copies of terminal installed with different settings! Oh i see, so i need to restore permissions on that folder to defaults and it may be fixed?
claunia commented 2026-01-31 05:05:45 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 12, 2022):

Oh i see, so i need to restore permissions on that folder to defaults and it may be fixed?

Yep! As a general note, never EVER touch the permissions on that directory. The OS really REALLY doesn't play nicely if you do that.

Sounds like this was a /dup #9452 after all. Thanks all!

@zadjii-msft commented on GitHub (Jan 12, 2022): > Oh i see, so i need to restore permissions on that folder to defaults and it may be fixed? Yep! As a general note, never EVER touch the permissions on that directory. The OS really REALLY doesn't play nicely if you do that. Sounds like this was a /dup #9452 after all. Thanks all!
claunia commented 2026-01-31 05:05:45 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jan 12, 2022):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Jan 12, 2022): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
claunia commented 2026-01-31 05:05:45 +00:00
Author
Owner
Copy Link

@SanokKule commented on GitHub (Jan 12, 2022):

Ok the problem was indeed ACLs now it works and thank you @DHowett for explaining why modifying permissions to that folder is bad, for over 7 years i had no idea why.
Had some problems with some files in windowsapps folder, and needed to take ownership.
Thanks @DHowett and @zadjii-msft for your time!

@SanokKule commented on GitHub (Jan 12, 2022): Ok the problem was indeed ACLs now it works and thank you @DHowett for explaining why modifying permissions to that folder is bad, for over 7 years i had no idea why. Had some problems with some files in windowsapps folder, and needed to take ownership. Thanks @DHowett and @zadjii-msft for your time!
claunia commented 2026-01-31 05:05:46 +00:00
Author
Owner
Copy Link

@LqkUWp commented on GitHub (May 24, 2022):

is there any neat way to restore permissions on 'c:\program files\windowsapps' to defaults?

@LqkUWp commented on GitHub (May 24, 2022): is there any neat way to restore permissions on 'c:\program files\windowsapps' to defaults?
claunia commented 2026-01-31 05:05:46 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 24, 2022):

I'm certainly not confident enough in my knowledge of ACLs to recommend one. My best recommendation is to never touch them in the first place.

@zadjii-msft commented on GitHub (May 24, 2022): I'm certainly not confident enough in my knowledge of ACLs to recommend one. My best recommendation is to **never touch them in the first place**.
claunia commented 2026-01-31 05:05:47 +00:00
Author
Owner
Copy Link

@JustJinxed commented on GitHub (Jan 18, 2024):

I can't believe I've had this issue for awhile now and it never crossed my mind that the source of my problem might be because the system couldn't fail to run an executable. My Irony is I created a particular account on my machine with full control to the windowsapps directory, just to troubleshoot strange Windows and services behaviors. And in giving this account those permissions I caused my very own, strange Windows behavior 😂

For anyone who finds this in the future, it's fairly unlikely you edited the ACL directly or need to use icacls. What usually happens in cases like this is you either took ownership of the directory, added yourself to the permissions, or a combination of the two. Easy fix is to google how to remove yourself from the "effective permissions" and "change owner to NT SERVICES\TrustedInstaller".

Arguably maybe the terminal shouldn't be relying on a failure state in order to run it? Maybe someone can look into it and "fix" that part? Or maybe this is one of those weird "as designed" callback features for security sake? (I have no clue, I won't pretend I do)

If you SOMEHOW did manage the ungodly feat of editing the ACL for the windowsapps folder, here's some helpful material. Be sure to read it in its entirety before picking a method: https://superuser.com/questions/1288014/reset-default-acls-for-c-program-files-windowsapps , and may the odds be ever in your favor.

@JustJinxed commented on GitHub (Jan 18, 2024): I can't believe I've had this issue for awhile now and it never crossed my mind that the source of my problem might be because the system couldn't fail to run an executable. My Irony is I created a particular account on my machine with full control to the windowsapps directory, just to troubleshoot strange Windows and services behaviors. And in giving this account those permissions I caused my very own, strange Windows behavior 😂 For anyone who finds this in the future, it's fairly unlikely you edited the ACL directly or need to use icacls. What usually happens in cases like this is you either took ownership of the directory, added yourself to the permissions, or a combination of the two. Easy fix is to google how to remove yourself from the "effective permissions" and "change owner to NT SERVICES\TrustedInstaller". Arguably maybe the terminal shouldn't be relying on a failure state in order to run it? Maybe someone can look into it and "fix" that part? Or maybe this is one of those weird "as designed" callback features for security sake? (I have no clue, I won't pretend I do) If you SOMEHOW did manage the ungodly feat of editing the ACL for the windowsapps folder, here's some helpful material. Be sure to read it in its entirety before picking a method: https://superuser.com/questions/1288014/reset-default-acls-for-c-program-files-windowsapps , and may the odds be ever in your favor.
claunia commented 2026-01-31 05:05:47 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 18, 2024):

Arguably maybe the terminal shouldn't be relying on a failure state in order to run it

Boy do I agree with that, but alas, that's how Windows decided to deal with app execution aliases 🤷 It's really not something we (the Terminal) can fix on our side.

@zadjii-msft commented on GitHub (Jan 18, 2024): > Arguably maybe the terminal shouldn't be relying on a failure state in order to run it Boy do I agree with that, but alas, that's how Windows decided to deal with app execution aliases 🤷 It's really not something _we_ (the Terminal) can fix on our side.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Question Product-Terminal Resolution-Duplicate Severity-Crash
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#16375
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?