Interop is broken when WSL is started prior to user logon

[KentoNishi]

Version

Microsoft Windows [Version 10.0.22000.318]

WSL Version

• WSL 2
• WSL 1

Kernel Version

Linux version 5.10.102.1-microsoft-standard-WSL2 (oe-user@oe-host) (x86_64-msft-linux-gcc (GCC) 9.3.0, GNU ld (GNU Binutils) 2.34.0.20200220) #1 SMP Wed Mar 2 00:30:59 UTC 2022

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

1. Create a task scheduler entry with the following settings:
   
   
   
   
   

2. Restart the machine

3. Log into Windows as usual

4. Open WSL and execute cmd.exe, observe that interop (both wslg and executing .exe files) do not work

Expected Behavior

WSL should work as intended, regardless of whether it was launched from a command line prior to logon or not.

Actual Behavior

Diagnostic Logs

No response

Requested Change

I would like WSL to have an option to launch at system startup. Without such an option, it is impossible to start WSL automatically without breaking interop.

[NotTheDr01ds]

This may be the same as #4260. This can occur if the 9P server isn't working correctly. If you try to access \\wsl$\Ubuntu (or whatever the distribution is named -- could be Ubuntu-20.04), does that work?

[KentoNishi]

This may be the same as #4260. This can occur if the 9P server isn't working correctly. If you try to access \\wsl$\Ubuntu (or whatever the distribution is named -- could be Ubuntu-20.04), does that work?

no, it isn't possible to access the path. is this an issue on my end, or is this a bug with wsl?

[NotTheDr01ds]

@KentoNishi Could be either, honestly. Based on a number of comments in #4260, it may be a permission/ownership issue.

In scanning through #4260, it sounds like that particular issue was due to the WSL distribution being "owned" by the Administrator, rather than your regular user. One (but not the only) cause of this could be installation via chocolatey.

If it is the permission issue, then a common fix for the \\wsl$\.. problem, at least, is to ...

Start an Admin prompt (PowerShell or CMD):

wsl -l -v
# Confirm the correct distro name, and substitute below as needed
subst s: \\wsl$\Ubuntu-20.04\home\

If that resolves your \\wsl$\ issue, then hopefully/perhaps it will also resolve the Invalid argument one.

[elsaco]

@KentoNishi what is the output of wslpath -w /mnt/c/Windows/system32/cmd.exe when run from /root? It should be C:\Windows\system32\cmd.exe. When you run cmd.exe from a WSL prompt it defaults to C:\Windows\system32 because of UNC.

Sample output:

[root@eleven elsaco]# cd ~
[root@eleven ~]# cmd.exe
'\\wsl.localhost\ArchLinux\root'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
Microsoft Windows [Version 10.0.22000.832]
(c) Microsoft Corporation. All rights reserved.

C:\Windows>

[KentoNishi]

@KentoNishi what is the output of wslpath -w /mnt/c/Windows/system32/cmd.exe when run from /root? It should be C:\Windows\system32\cmd.exe. When you run cmd.exe from a WSL prompt it defaults to C:\Windows\system32 because of UNC.

Sample output:

[root@eleven elsaco]# cd ~
[root@eleven ~]# cmd.exe
'\\wsl.localhost\ArchLinux\root'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
Microsoft Windows [Version 10.0.22000.832]
(c) Microsoft Corporation. All rights reserved.

C:\Windows>

it's C:\Windows\system32\cmd.exe

[KentoNishi]

Update: I think I figured out what was going wrong. I had a task scheduler entry to auto-start my wsl instance on startup without login, and disabling that made it work again. I assume that wsl interop depends on the desktop environment being fully loaded? This error disappeared when I disabled the task scheduler item.

[NotTheDr01ds]

@KentoNishi Good find. And most likely -- It's been a while since I've done that, so I don't remember the exact details, but I did have issues with WSL instances started via Task Scheduler at Computer Startup. Something has probably changed since then, since I believe my problem was that the instance would self-terminate even if a service was running inside it if it wasn't "associated" with the desktop. But it's clear that WSL behaves differently when started without a desktop/logged-in user.

You might want to edit the main issue above to make it clear (without reading the comments) how to reproduce the issue.

[KentoNishi]

I updated the title and issue content.

[OneBlue]

/logs

[ghost]

Hello! Could you please provide more logs to help us better diagnose your issue?

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

Thank you!

[KentoNishi]

@OneBlue
WslLogs-2022-07-26_14-58-28.zip

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!