Possible race condition in WSL enumeration? #12140

Open
opened 2026-01-31 03:07:18 +00:00 by claunia · 0 comments
Owner

Originally created by @davidchisnall on GitHub (Jan 22, 2021).

Environment

Microsoft Windows [Version 10.0.19042.746]
Windows Terminal version (if applicable): 1.5.3242.0

I have only seen this once and I believe it happened because, after a reboot, I heavily loaded the system starting applications and delayed the start of the WSL service.

My default terminal comes from a setting with the source set like this:

"source": "Windows.Terminal.Wsl"

When I started the terminal, it informed me that the GUID for my default terminal did not exist and did not show it in the menu. The error message was slightly unhelpful - I hadn't realised that the GUIDs were purely internal to the WSL configuration file and had assumed that they were used to communicate with the WSL service.

When I quit and restarted the terminal, everything worked.

I suspect that it initially failed to connect to the WSL service. It would be nice to have a short retry interval (maybe a few seconds?) for this, and an error message if it fails indicating that the terminal could not talk to the WSL service, rather than the mysterious 'GUID is invalid' message.

You might be able to reproduce the failure by configuring the terminal to use a WSL terminal by default and then stopping the WSL subsystem.

Originally created by @davidchisnall on GitHub (Jan 22, 2021). # Environment ```none Microsoft Windows [Version 10.0.19042.746] Windows Terminal version (if applicable): 1.5.3242.0 ``` I have only seen this once and I believe it happened because, after a reboot, I heavily loaded the system starting applications and delayed the start of the WSL service. My default terminal comes from a setting with the source set like this: ```json "source": "Windows.Terminal.Wsl" ``` When I started the terminal, it informed me that the GUID for my default terminal did not exist and did not show it in the menu. The error message was slightly unhelpful - I hadn't realised that the GUIDs were purely internal to the WSL configuration file and had assumed that they were used to communicate with the WSL service. When I quit and restarted the terminal, everything worked. I suspect that it initially failed to connect to the WSL service. It would be nice to have a short retry interval (maybe a few seconds?) for this, and an error message if it fails indicating that the terminal could not talk to the WSL service, rather than the mysterious 'GUID is invalid' message. You might be able to reproduce the failure by configuring the terminal to use a WSL terminal by default and then stopping the WSL subsystem.
claunia added the Needs-TriageNeeds-Tag-Fix labels 2026-01-31 03:07:18 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#12140