Working directory not preserved when running Windows executable from WSL directory

[dc46and2]

Windows Version

Microsoft Windows [Version 10.0.22631.4460]

WSL Version

2.3.26.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

5.15.167.4-1

Distro Version

Ubuntu 22.04 and 24.04

Other Software

No response

Repro Steps

1. Open WSL1 or WSL2 or Powershell terminal window (using Windows Console Host or Windows Terminal.)
2. cd to any directory within WSL file system, e.g. /home/username or \\wsl.localhost\distroname\home\username.
3. Run a Windows .exe that attempts to open a file in current working directory. E.g. notepad.exe foo.txt, assuming foo.txt is an existing file in the directory.

Expected Behavior

The current working directory is preserved, so notepad.exe find the existing file foo.txt within the working directory, which should be \\wsl.localhost\distroname\home\username. This was working up until fairly recently, although I'm not sure exactly when it broke.

Actual Behavior

The current working directory of the Windows .exe is C:\WINDOWS, so it does not find the desired file.

Note that a command like notepad.exe '\\wsl.localhost\distroname\home\username\foo.txt' works. So Windows executables are able to access the WSL directory. The only issue is the current working directory is not being set correctly.

Diagnostic Logs

I will send logs via email.

[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 script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

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!

Open similar issues:

• Windows interop doesn't work for .exe files that live inside of a Docker container (#11967), similarity score: 0.71

Closed similar issues:

• Access files in WSL filesystem by exe in Windows' filesystem (#7691), similarity score: 0.76
• CurrentDirectoryPath doesn't get updated on directory change (#9404), similarity score: 0.71
• Executables that access the WSL disks fail to open (#6656), similarity score: 0.71
• WSL command from windows not executed in appropriate folder in WSL file system (#8585), similarity score: 0.71

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

[dc46and2]

Per CONTRIBUTING.md, I sent the logs to [email protected].

[dc46and2]

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 script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

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!

Open similar issues:

• Windows interop doesn't work for .exe files that live inside of a Docker container (#11967), similarity score: 0.71

Closed similar issues:

• Access files in WSL filesystem by exe in Windows' filesystem (#7691), similarity score: 0.76
• CurrentDirectoryPath doesn't get updated on directory change (#9404), similarity score: 0.71
• Executables that access the WSL disks fail to open (#6656), similarity score: 0.71
• WSL command from windows not executed in appropriate folder in WSL file system (#8585), similarity score: 0.71

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

/emailed-logs

[github-actions]

Diagnostic information

Found '/emailed-logs', adding tag 'emailed-logs'

[benhillis]

I cannot reproduce this on 2.4.4.0

[dc46and2]

I tried this again today, and now it is working as expected from both WSL1 and WSL2 on the same PC. Probably some Windows updates have been installed since I created the issue, but WSL and kernel version have not changed. So I'm not sure why the behavior changed.

[seppestas]

For me, this issue still exists. @dc46and2, what version of Windows fixed the issue?

I think this problem is most likely caused by some corporate AV/spyware software. Are you also using an IT managed system?

[dc46and2]

what version of Windows fixed the issue?

I'm not sure if a Windows update fixed it. If it did, I don't know which one.

I think this problem is most likely caused by some corporate AV/spyware software. Are you also using an IT managed system?

Yes.

[seppestas]

Seems to be magically fixed for me now as well. Of note is that according to Windows Update, no Windows updates were installed recently. Who knows though what updates / policy changes were rolled out by my company's IT though 🤷‍♂️.