Crash on startup

[evakili]

Windows Terminal version (or Windows build number)

1.8.210524004

Other Software

No response

Steps to reproduce

I know there are other issues about crashing at startup, but I could not find any similar one to my issue.

I install the Windows terminal via scoop.

After upgrading from 1.7 to 1,8, when I open the terminal it immediately closed. After playing around I found that some of the profiles open without problem (opening from taskbar menu), while some other profiles are crashed at startup. Finally, I found every PowerShell profile that I set its startingDirectory to ~ will face the crash. After changing ~ to %USERPROFILE% (as the settings editor suggested) the problem is solved.

Expected Behavior

The ~ as startingDirectory is worked fine in the older versions (1.7-).

Actual Behavior

It crashed at startup.

[zadjii-msft]

Root cause: In #10045, we thought it was a good idea to stop validating your startingDirectory's before spawning processes. In prior releases, we'd check that path exists, and fall back to %USERPROFILE% if it didn't. Turns out, WSL can take a excessive amount of time to report if a path exists or not.
As it also turns out, more people were relying on that silent fallback to %USERPROFILE% than we were expecting.

Now, if you've got "closeOnExit": "always" in your settings, the Terminal will close instantly when it determines that it couldn't launch your commandline in the given startingDirectory.

• This is tracked in /dup error when launching..Could not access starting directory #10245
• We've got a "fix" in Ignore closeOnExit when a conn. moves from Connecting to Failed #10263

Mitigation

• Change closeOnExit to "closeOnExit": "graceful".
• Update the startingDirectory of your profile to an actual Windows path. Remember, it MUST be a Windows path, even for WSL profiles. ~ is not a Windows path, even if PowerShell uses it as a shorthand for %USERPROFILE%. WSL paths will need to use the //wsl$/{distro}/home/{wsl username} format.

[ghost]

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!