GUI apps via VcXsrv not starting from 14 Jun 2024

[bobf32]

Windows Version

Microsoft Windows [Version 10.0.22631.3737]

WSL Version

2.2.4.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

Linux version 5.15.153.1-microsoft-standard-WSL2 (root@941d701f84f1) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.37) #1 SMP Fri Mar 29 23:14:13 UTC 2024

Distro Version

Ubuntu 22.04.2 LTS

Other Software

VcXsrv X Server 1.20.8.1

Repro Steps

1. Start VcXsrv
2. Start WSL2
3. export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0
4. Run emacs &

Expected Behavior

Emacs starts (as it has for months under Windows 10 and the last week or so under Windows 11) in a new GUI window.

Actual Behavior

$ emacs &
[1] 10158
$ Display 10.255.255.254:0 unavailable, simulating -nw

[1]+ Stopped emacs

$ fg

Non-GUI emacs starts in WSL2 terminal window

Diagnostic Logs

WslLogs-2024-06-14_17-10-15.zip

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The scipt will output the path of the log file once done.

Once completed please upload the output files to this Github issue.

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to [email protected] with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Closed similar issues:

• WSL version: 1.0.3.0: no longer able to use external X server with Windows 10 (20H2) (#9541), similarity score: 0.74
• wslg cannot open display if wsl started with Task Scheduler (#8217), similarity score: 0.74
• wslg not working on windows 11 (#9206), similarity score: 0.71
• WSL2 Windows 11 suddenly cannot open display (#7950), similarity score: 0.71
• X Windows broken on fast ring WSL2 (?) (#5106), similarity score: 0.70

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[github-actions]

The log file doesn't contain any WSL traces. Please make sure that you reproduced the issue while the log collection was running.

Diagnostic information

Issue was edited and new log file was found: https://github.com/user-attachments/files/15840842/WslLogs-2024-06-14_17-10-15.zip
Detected appx version: 2.2.4.0
Found no WSL traces in the logs

[bobf32]

Logs added.

[bobf32]

Weird. I have DISPLAY set as:

export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0

which currently results in DISPLAY=10.255.255.254:0. I assume this was the same value when all was good but I don't know. With DISPLAY set thusly I am getting the behaviour decribed above.

But...if I get the IP address of the ethernet adapter using ipconfig I get 192.168.0.223. And setting DISPLAY=192.168.0.223:0 makes the X GUI apps work OK again.

I wonder why this is.

[redfinemd]

Weird. I have DISPLAY set as:

export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0

which currently results in DISPLAY=10.255.255.254:0. I assume this was the same value when all was good but I don't know. With DISPLAY set thusly I am getting the behaviour decribed above.

But...if I get the IP address of the ethernet adapter using ipconfig I get 192.168.0.223. And setting DISPLAY=192.168.0.223:0 makes the X GUI apps work OK again.

Same behavior here, using X410.
My suspicion is that the problem was introduced by 'Windows 11 Version 23H2 for x64-based Systems (KB5039212)'.

[Maxim-Mazurok]

Having the same issue.
DISPLAY=10.255.255.254:0.0 - doesn't work
DISPLAY=172.20.144.1:0.0 - works.

I'm pretty sure that nameserver in /etc/resolve.conf used to be 172.20.144.1.
The 10.255.255.254 address looks new and unexpected to me.

Both me and two of my teammates are having the same issue since recent Windows upgrade.

My Windows system info:

Edition	Windows 11 Enterprise
Version	23H2
Installed on	‎04-‎May-‎2023
OS build	22631.3737
Experience	Windows Feature Experience Pack 1000.22700.1009.0

WSL info:

WSL version: 2.2.4.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5326
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26091.1-240325-1447.ge-release
Windows version: 10.0.22631.3737

[Maxim-Mazurok]

This seems to work:

export DISPLAY=$(ip route | grep default | awk '{print $3}'):0.0

Credit - GPT4o

[Youngerkind]

export DISPLAY=$(ip route | grep default | awk '{print $3}'):0.0

Maxim's solution seems to work. And the interpretation is given by bobf32.
ip route will give the right ip, while /etc/resolv.conf will not.

[craigloewen-msft]

Folks you are likely seeing this as we change and upgrade networking in WSL. In the latest WSL versions we turned on DNStunneling by default which I think is affecting this path.

As others have put in the thread please update your variable to be the logic above instead (Thank you to @Maxim-Mazurok and others who posted their working configs!!).

We had that old string in our docs page which is why folks might be using it (It's also floating around on GitHub somewhere) but we've gone ahead and updated our docs to use the latest working string.

Since this doesn't have any actionable items for the WSL team I'm going to close it out, thank you for filing this! :)

[mikelor]

Thank you. This solved my problem I was having with Git Credential Manager after upgrading from WSL 2.1.5.0 to WSL 2.2.4.0