1.7.1033.0_x64 - running from command prompt crashes

[geek2point0]

When attempting to run version 1.7.1033.0_x64 from either Command Prompt or PowerShell the application briefly opens a white window then immediately closes. In the Application event log I see the below entry. This does not occur when launching from the Start menu.

Faulting application name: WindowsTerminal.exe, version: 1.7.2104.13003, time stamp: 0x60761d23
Faulting module name: TerminalApp.dll, version: 1.7.2104.13003, time stamp: 0x60761c93
Exception code: 0xc0000005
Fault offset: 0x000000000000ee80
Faulting process id: 0x2530
Faulting application start time: 0x01d73ac0b411c259
Faulting application path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.7.1033.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.7.1033.0_x64__8wekyb3d8bbwe\TerminalApp.dll
Report Id: 80f4b689-8e8d-4d2e-8e3d-c59fa3dbaf5c
Faulting package full name:
Faulting package-relative application ID:

[zadjii-msft]

How did you install the Terminal? From scoop perhaps?

[geek2point0]

I installed from the Microsoft Store. I did see the issue with scoop, we don't use that package manager in my organization though.

[zadjii-msft]

Good to know - can you file a feedback with the Feedback Hub? That would help us diagnose the root cause

/feedback

[ghost]

Hi there!

Can you please send us feedback with the Feedback Hub with this issue and paste the link here so we can more easily find your crash information on the back end?

Thanks!

[zadjii-msft]

You know, this might actually just be #9891. To copy-pasta:

This might actually be a weird interaction of #9452, mixed with the unpackaged crash from #9821. For some reason, even when installed from the Store, the OS forgets that we're a packaged application and decides to run the Terminal unpackaged. That would run you right into the crash in #9821. The reasons for this are poorly understood. The time it happened to me, it went away with a reboot or toggling the "app execution alias" for wt.exe in the system Settings app (I can't remember which). #9452 and the linked threads might have more solutions listed if that doesn't work for you. Sorry about this 😕

You might be able to repair this easily by toggling the wt.exe execution alias in the settings app

[geek2point0]

I just submitted the feedback. Unfortunately toggling the execution alias setting did not fix the issue. The same thing happens.

[zadjii-msft]

Oh, can you share the link to the feedback? It should be an aka.ms link

[geek2point0]

Sure thing. Here it is. https://aka.ms/AAc1s04

[kiriDevs]

If this is related to my issue #9891 (which it looks like because for me the only reason why it worked in those locations was a shortcut I created myself), we just found a workaround for that issue over there.
For us, it worked to download the release here from GitHub and update by executing the .msixbundle.

Make sure to copy your config beforehand, at least for me it now uses a different path.

[geek2point0]

@kiriDevs I did try running the .msixbundle as well before opening this issue. Unfortunately that didn't help, the only way for me to successfully open the application is from the Start menu.

[DHowett]

This sounds a lot like #9452.

Can you run through the repro steps in that bug report? I'd love to see what the ACLs are on your WindowsApps directory.

[geek2point0]

@DHowett I just added that information to the bug report. Including here as well for the community at large.

Steps to reproduce

1. Open Command Prompt or Windows PowerShell (does not matter if As Administrator or not)
2. At the prompt enter: wt.exe or windows terminal.exe
3. Press Enter

[PS] C:\Program File> Get-Acl .\WindowsApps\ | fl


Path   : Microsoft.PowerShell.Core\FileSystem::C:\Program Files\WindowsApps\
Owner  : NT SERVICE\TrustedInstaller
Group  : NT SERVICE\TrustedInstaller
Access : NT AUTHORITY\RESTRICTED Allow  ReadAndExecute, Synchronize
         NT AUTHORITY\SYSTEM Allow  FullControl
         NT AUTHORITY\LOCAL SERVICE Allow  ReadAndExecute, Synchronize
         NT AUTHORITY\NETWORK SERVICE Allow  ReadAndExecute, Synchronize
         BUILTIN\Administrators Allow  ReadAndExecute, Synchronize
         BUILTIN\Administrators Allow  FullControl
         BUILTIN\Users Allow  ReadAndExecute, Synchronize
         FFFCU\geek2point0 Allow  FullControl
         FFFCU\admingeek2point0 Allow  FullControl
         NT SERVICE\TrustedInstaller Allow  FullControl
         S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204 Allow
         ReadAndExecute, Synchronize
Audit  :
Sddl   : O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464G:S-1-5-80-956008885-3418522649-1831038044-185
         3292631-2271478464D:PAI(A;OICI;0x1200a9;;;RC)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;LS)(A;OICI;0x1200a9;;;NS)(A;CI
         ;0x1200a9;;;BA)(A;OICI;FA;;;BA)(XA;;0x1200a9;;;BU;(Exists WIN://SYSAPPID))(A;OICI;FA;;;S-1-5-21-439381220-1555
         956578-5522801-12985)(A;OICI;FA;;;S-1-5-21-439381220-1555956578-5522801-14301)(A;OICI;FA;;;S-1-5-80-956008885-
         3418522649-1831038044-1853292631-2271478464)(A;OICI;0x1200a9;;;S-1-15-3-1024-3635283841-2530182609-996808640-1
         887759898-3848208603-3313616867-983405619-2501854204)

[PS] C:\Program Files>

[DHowett]

I don't think those are quite correct. Since your user has Full Control -- both your daily-use and admin user -- you can "see into" WindowsApps.

This actually causes untold havoc on the app platform. It's a problem we're actively discussing with them!

What happens is that:

1. When you install Terminal, the package installer automatically adds a registry value to the AppPaths key, saying that "wt.exe is available at C:\Program Files\WindowsApps\...WindowsTerminal...\wt.exe"
2. When you use wt from cmd or Win+R (Run), it reads AppPaths first
3. You're supposed to get an access denied error for anything under WindowsApps
4. CreateProcess catches the access denied error and translates it into a packaged launch (running wt.exe with the identity Microsoft.WindowsTerminal_8wekybxxxxxxx)

Because you can see inside WindowsApps or the permissions are otherwise damaged, step 3 fails and it actually just runs wt.exe from that folder without associating it with the installed package.

Because of #9821, that results in a crash for 1.7.1033 and 1.8.1032.
If you run this way with 1.7.109x (the fixed build), you'll get a different but still very severe bug:

Terminal won't be able to find its settings, because the OS didn't tell it "by the way, you're living inside the Microsoft.WindowsTerminal_8wekybxzxxxx package."

[DHowett]

Here's what I get:

PS C:\WINDOWS\system32> get-acl \Program` Files\WindowsApps | fl


Path   : Microsoft.PowerShell.Core\FileSystem::C:\Program Files\WindowsApps
Owner  : NT SERVICE\TrustedInstaller
Group  : NT SERVICE\TrustedInstaller
Access : NT AUTHORITY\RESTRICTED Allow  ReadAndExecute, Synchronize
         NT AUTHORITY\SYSTEM Allow  FullControl
         NT AUTHORITY\SYSTEM Allow  268435456
         NT AUTHORITY\LOCAL SERVICE Allow  ReadAndExecute, Synchronize
         NT AUTHORITY\NETWORK SERVICE Allow  ReadAndExecute, Synchronize
         BUILTIN\Administrators Allow  ReadAndExecute, Synchronize
         BUILTIN\Users Allow  ReadAndExecute, Synchronize
         NT SERVICE\TrustedInstaller Allow  268435456
         NT SERVICE\TrustedInstaller Allow  FullControl
         S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204 Allow
          -1610612736
         S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204 Allow
          ReadAndExecute, Synchronize
Audit  :
Sddl   : O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464G:S-1-5-80-956008885-3418522649-1831038044
         -1853292631-2271478464D:PAI(A;OICI;0x1200a9;;;RC)(A;;FA;;;SY)(A;OICIIO;GA;;;SY)(A;OICI;0x1200a9;;;LS)(A;OI
         CI;0x1200a9;;;NS)(A;CI;0x1200a9;;;BA)(XA;;0x1200a9;;;BU;(Exists WIN://SYSAPPID))(A;OICIIO;GA;;;S-1-5-80-95
         6008885-3418522649-1831038044-1853292631-2271478464)(A;;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853
         292631-2271478464)(A;OICIIO;GXGR;;;S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-331
         3616867-983405619-2501854204)(A;;0x1200a9;;;S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-38482
         08603-3313616867-983405619-2501854204)

[geek2point0]

@DHowett, I went and restored my ACLs so they match what you shared. I am now able to launch wt.exe from cmd/posh, but only if I run as my logged in account. Opening PoSH/CMD with my admin account using Run As, and then trying to launch wt.exe I get "access denied".

[DHowett]

So! This is one of the unfortunate things about the version of Windows that's current. When you have a separate admin user (which we call "over-the-shoulder elevation"), an app package needs to be registered for both users. If you run "add-appxpackage -register path_to_windows_terminal\AppxManifest.xml" as the other user the Access Denied error should go away.

[geek2point0]

I realize we're getting out of scope here, but I did try installing the app from the store under both my daily driver and my admin account. Still getting the same error. I ran the PoSH command you suggested and get this:

Add-AppxPackage -register 'C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.7.1033.0_x64__8wekyb3d8bbwe\AppxManifest.xml'
Add-AppxPackage : Deployment failed with HRESULT: 0x80073CF9, Install failed. Please contact your software vendor. (Exception from HRESULT: 0x80073CF9)
Rejecting a request to register from AppxBundleManifest.xml because the manifest is not in the package root.
NOTE: For additional information, look for [ActivityId] cd167183-3cf8-0001-f9ca-16cdf83cd701 in the Event Log or use the command line Get-AppPackageLog
-ActivityID cd167183-3cf8-0001-f9ca-16cdf83cd701
At line:1 char:1
+ Add-AppxPackage -register 'C:\Program Files\WindowsApps\Microsoft.Win ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (C:\Program File...ppxManifest.xml:String) [Add-AppxPackage], IOException
    + FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand

[zadjii-msft]

Hey so this thread got off the rails - what was the next action item here/? Did this get sorted out? It's been like a year.

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.