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 installed to Windows Server 2022 via Windows Package Manager (winget) cannot open Windows Subsystem for Linux #20149

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

Originally created by @branpurn on GitHub (Jun 26, 2023).

Windows Terminal version

1.17.11461.0

Windows build number

10.0.20348.0

Other Software

Name   Id            Version  Source
--------------------------------------
Debian Debian.Debian 1.12.2.0 winget

Steps to reproduce

  1. Fresh install Windows Server 2022
  2. Install Windows Package Manager (winget)
  3. Install Windows Terminal
  4. Install WSL and Debian; setup Debian and ensure working independently
  5. Attempt to launch Debian in new Windows Terminal tab

Expected Behavior

Debian would launch with immediate access to bash prompt

Actual Behavior

The following error appears:

The system cannot find the file specified.

[process exited with code 4294967295 (0xffffffff)]
You can now close this terminal with Ctrl+D, or press Enter to restart.
Originally created by @branpurn on GitHub (Jun 26, 2023). ### Windows Terminal version 1.17.11461.0 ### Windows build number 10.0.20348.0 ### Other Software ``` Name Id Version Source -------------------------------------- Debian Debian.Debian 1.12.2.0 winget ``` ### Steps to reproduce 1. Fresh install Windows Server 2022 2. Install Windows Package Manager (winget) 3. Install Windows Terminal 4. Install WSL and Debian; setup Debian and ensure working independently 5. Attempt to launch Debian in new Windows Terminal tab ### Expected Behavior Debian would launch with immediate access to bash prompt ### Actual Behavior The following error appears: ``` The system cannot find the file specified. [process exited with code 4294967295 (0xffffffff)] You can now close this terminal with Ctrl+D, or press Enter to restart. ```
claunia added the Needs-TriageIssue-BugNeeds-Author-FeedbackNo-Recent-Activity labels 2026-01-31 07:05:06 +00:00
claunia commented 2026-01-31 07:05:07 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 26, 2023):

There are multiple other issues with the same failure code. See here:

Do the comments in any of these solve your issue?

@lhecker commented on GitHub (Jun 26, 2023): There are multiple other issues with the same failure code. See here: * #12474 * #12754 * #15072 Do the comments in any of these solve your issue?
claunia commented 2026-01-31 07:05:07 +00:00
Author
Owner
Copy Link

@branpurn commented on GitHub (Jun 26, 2023):

There are multiple other issues with the same failure code. See here:

Do the comments in any of these solve your issue?

Thanks-- will report back

  • #12474, source is winget vs Microsoft Store but will try
  • #12754, hex is same but error string is different, will fall-back to trying this
  • #15072, DISM repair, will try this lastly

Edit: Unfortunately, none of this appeared to resolve.

@branpurn commented on GitHub (Jun 26, 2023): > There are multiple other issues with the same failure code. See here: > > * [Unable to launch WSL Ubuntu - The system cannot find the file specified. #12474](https://github.com/microsoft/terminal/issues/12474) > * [fail to launch WSL (both 1 and 2) from terminal after update to win 11 Build 22581.ni_release.220318-1623 #12754](https://github.com/microsoft/terminal/issues/12754) > * [Error 0xffffffff starting WSL from WT #15072](https://github.com/microsoft/terminal/issues/15072) > > Do the comments in any of these solve your issue? Thanks-- will report back - #12474, source is `winget` vs Microsoft Store but will try - #12754, hex is same but error string is different, will fall-back to trying this - #15072, DISM repair, will try this lastly *** Edit: Unfortunately, none of this appeared to resolve.
claunia commented 2026-01-31 07:05:07 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Jun 28, 2023):

This bug from the WSL repo seems like it might be related (same error code and version of windows server).

@carlos-zamora commented on GitHub (Jun 28, 2023): [This bug](https://github.com/microsoft/WSL/issues/6301) from the WSL repo seems like it might be related (same error code and version of windows server).
claunia commented 2026-01-31 07:05:07 +00:00
Author
Owner
Copy Link

@branpurn commented on GitHub (Jun 28, 2023):

This bug from the WSL repo seems like it might be related (same error code and version of windows server).

Could be related. FWIW, WSL works fine outside of Windows Terminal from default shell launcher.

@branpurn commented on GitHub (Jun 28, 2023): > [This bug](https://github.com/microsoft/WSL/issues/6301) from the WSL repo seems like it might be related (same error code and version of windows server). Could be related. FWIW, WSL works fine outside of Windows Terminal from default shell launcher.
claunia commented 2026-01-31 07:05:08 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 28, 2023):

WSL works fine outside of Windows Terminal from default shell launcher.

Really!

Okay, this is going to sound crazy... but can you change the commandline of your WSL profile from wsl -d Whatever to wsl ~ -d Whatever and see if it is still broken?

@DHowett commented on GitHub (Jun 28, 2023): > WSL works fine outside of Windows Terminal from default shell launcher. _Really!_ Okay, this is going to sound crazy... but can you change the commandline of your WSL profile from `wsl -d Whatever` to `wsl ~ -d Whatever` and see if it is still broken?
claunia commented 2026-01-31 07:05:08 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 29, 2023):

@branpurn got back to me over e-mail, as they were unable to comment here due to our interaction limits.

Below, for posterity:

Forcing to home directory in the commandline does appear to resolve the issue. So perhaps a WSL issue?

...and my reply:

a-ha! That’s both WSL’s and Terminal’s fault. I’ll write up a response on the issue explaining why and what we can do about it! Thanks for testing with me.

So, this is an unexpected interplay between WT's automatic starting directory promotion and WSL's relative outdatedness on Windows Server 2022.

As a bit of stage-setting: WT wants to support starting directories that are not Windows paths when you're launching a WSL profile, so that you can set one to start in /home/dustin/projects or /foo or wherever.

To do that, WT takes your starting directory and yeets it into the command line directly. This moves the responsibility for parsing it over into WSL, so CreateProcess() (a Win32 API call) doesn't try and fail to find ~ or /foo.

In effect, we transform a profile that looks like this:

"commandline": "wsl",
"startingDirectory": "/foo"

into this:

"commandline": "wsl --cd /foo",
"startingDirectory": null

It just so happens that the version of WSL that was inbox with Server 2022 does not support --cd.

Adding ~ is a permanent workaround. We will not try to mangle the starting directory if we can tell that the user has done so intentionally themselves. wsl ~ is a (supported) legacy way to make WSL start in ~, so its existence counts as intention.

Fixes

  1. Upgrade to the version of WSL available in the Windows Store (sorry)
  2. Live with wsl ~ -d bar

Number 2 precludes you from having profiles that start in /foo, but so does the lack of --cd support. Number 1 might have its own problems, but we are not yet aware of what they are.

@DHowett commented on GitHub (Jun 29, 2023): @branpurn got back to me over e-mail, as they were unable to comment here due to our interaction limits. Below, for posterity: > Forcing to home directory in the commandline does appear to resolve the issue. So perhaps a WSL issue? ...and my reply: > a-ha! That’s both WSL’s and Terminal’s fault. I’ll write up a response on the issue explaining why and what we can do about it! Thanks for testing with me. --- So, this is an unexpected interplay between WT's automatic starting directory promotion and WSL's relative outdatedness on Windows Server 2022. As a bit of stage-setting: WT wants to support starting directories that are _not_ Windows paths when you're launching a WSL profile, so that you can set one to start in `/home/dustin/projects` or `/foo` or wherever. To do that, WT takes your starting directory and yeets it _into the command line_ directly. This moves the responsibility for parsing it over into WSL, so `CreateProcess()` (a Win32 API call) doesn't try and fail to find `~` or `/foo`. In effect, we transform a profile that looks like this: ``` "commandline": "wsl", "startingDirectory": "/foo" ``` into this: ``` "commandline": "wsl --cd /foo", "startingDirectory": null ``` It just so happens that the version of WSL that was inbox with Server 2022 _does not support `--cd`._ Adding `~` is a permanent workaround. We will not try to mangle the starting directory if we can tell that the user has done so intentionally themselves. `wsl ~` is a (supported) legacy way to make WSL start in `~`, so its existence counts as intention. --- Fixes 1. Upgrade to the version of WSL available in the Windows Store (sorry) 2. Live with `wsl ~ -d bar` Number 2 precludes you from having profiles that start in `/foo`, but so does the lack of `--cd` support. Number 1 might have its own problems, but we are not yet aware of what they are.
claunia commented 2026-01-31 07:05:08 +00:00
Author
Owner
Copy Link

@microsoft-github-policy-service[bot] commented on GitHub (Jul 3, 2023):

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.

@microsoft-github-policy-service[bot] commented on GitHub (Jul 3, 2023): 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**.
claunia commented 2026-01-31 07:05:08 +00:00
Author
Owner
Copy Link

@microsoft-github-policy-service[bot] commented on GitHub (Jul 3, 2023):

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.

@microsoft-github-policy-service[bot] commented on GitHub (Jul 3, 2023): 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**.
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-Bug Needs-Author-Feedback Needs-Triage No-Recent-Activity
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#20149
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?