cannot open explorer.exe/code in WSL2

[lanyuer]

Version

10.0.22000.978

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.15.68.1

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

explorer.exe .
code .

Expected Behavior

open folder

Actual Behavior

exec: Failed to execute process: '/mnt/c/Windows/explorer.exe' the file could not be run by the operating system.
/mnt/f/Users/mylan/AppData/Local/Programs/Microsoft VS Code/bin/code: line 61: /mnt/f/Users/mylan/AppData/Local/Programs/Microsoft VS Code/Code.exe: cannot execute binary file: Exec format error

Diagnostic Logs

No response

[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!

[lanyuer]

WslLogs-2022-10-11_20-02-58.zip

[OneBlue]

Thank you @lanyuer but unfortunately I'm not seeing any WSL logs in the file you shared. Did you reproduce the issue while the log collection was running ?

[benhillis]

@lanyuer - are you using systemd? Looks like in some situation the binfmt interpreter may be getting unregistered.

[thomasemter]

I have the same problem with Visual Studio Code since WSL 0.7 and I have systemd activated:
/mnt/c/Program Files/Microsoft VS Code/bin/code: 61: /mnt/c/Program Files/Microsoft VS Code/Code.exe: Exec format error

Unfortunately, I cannot use an administrative powershell prompt because our IT has deprived us of our administrative privileges.

@benhillis - is there a possibility to register binfmt again? Is this the service binfmt-support.service?

sudo systemctl status binfmt-support.service shows:

● binfmt-support.service - Enable support for additional executable binary formats
Loaded: loaded (/lib/systemd/system/binfmt-support.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:update-binfmts(8)

After starting the service with sudo systemctl start binfmt-support.service it shows:

● binfmt-support.service - Enable support for additional executable binary formats
Loaded: loaded (/lib/systemd/system/binfmt-support.service; enabled; vendor preset: enabled)
Active: active (exited) since Fri 2022-10-14 16:47:25 CEST; 6s ago
Docs: man:update-binfmts(8)
Process: 629 ExecStart=/usr/sbin/update-binfmts --enable (code=exited, status=0/SUCCESS)
Main PID: 629 (code=exited, status=0/SUCCESS)

Oct 14 16:47:25 xxxxxx systemd[1]: Starting Enable support for additional executable binary formats...
Oct 14 16:47:25 xxxxxx systemd[1]: Finished Enable support for additional executable binary formats.

But the Exec format error persists.

Thank you!

[lanyuer]

@lanyuer - are you using systemd? Looks like in some situation the binfmt interpreter may be getting unregistered.

Yes, everything is back to normal when I closed systemd in /etc/wsl.conf

[thomasemter]

When I set systemd=false in /etc/wsl.conf I am able to start Visual Sudio Code once after a restart of WSL. But after a few seconds the Exec format error appears again.

[benhillis]

Ok - unfortunately there's not going to be a perfect fix until the Linux kernel supports binfmt namespaces.

[thomasemter]

Ok, thank you for looking into it. Do you know an approximate time horizon?

[Sangresz]

I set systemd=false and everything works well now

tried to do the same thing but code does still bring the exec format error

[zyazhb]

have a look at #8843

[thomasemter]

have a look at #8843

Brilliant, the fix with WSLInterop.conf is working. Thank you very much.

[bartdorsey]

I feel like the Ubuntu install for WSL2 should just include the WSLInterop.conf file. That would fix this for all systemd users I believe....

[bartdorsey]

So suddenly my WSLInterop.conf file isn't being picked up by the binfmt-support service...

I added the WSLInterop.conf file into /usr/lib/binfmt.d The contents look like this:

:WSLInterop:M::MZ::/init:PF

However, when I run systemctl restart binfmt-support it does not add the wsl interop to the kernel in /proc/sys/fs/binfmt_misc

[bartdorsey]

I even tried adding the conf file to /etc/binfmt.d and it doesn't seem to see it there either

[bartdorsey]

Okay I figured it out, there's TWO things that configure binfmts on Ubuntu... both are systemd services....

1. binfmt-support.service - This just runs the update-binfmts --enable command when it starts.. Which appears to read from /var/lib/binfmts/
2. systemd-binfmt.service - This is a built in thing that comes with systemd which reads from the various binfmt.d directories.

If your WSL interop ever breaks you should run the following in this order:

sudo systemctl restart systemd-binfmt
sudo systemctl restart binfmt-support

This will fix it up and make all of your binfmts registered.

I still don't know why this isn't happening when the WSL first starts up. Or what runs that breaks it.

[dead-claudia]

Unfortunately for me, @bartdorsey's workaround didn't work. However, disabling systemd worked.

This didn't happen for me initially and I couldn't reproduce it on fresh installs, so creating a 100% reproduction will be difficult.

[freckhard]

Hey @dead-claudia, some clever people found the solution, by adding one line to the binfmt.d/WSLInterop.conf file. By doing so you get to keep systemd and *.exe files working again right from WSL. Check the summary I made on #8843 (comment) 👍

[deCaldas]

I think running sudo reboot in WSL2 is a bad idea because after that it stops running Windows11 programs...

Look:
-bash: /mnt/c/WINDOWS/system32/notepad.exe: cannot execute binary file: Exec format error

-bash: /mnt/c/WINDOWS/explorer.exe: cannot execute binary file: Exec format error

/mnt/c/Users/Laptop/AppData/Local/Programs/Microsoft VS Code/bin/code: 61: /mnt/c/Users/Laptop/AppData/Local/Programs/Microsoft VS Code/Code.exe: Exec format error

-bash: /mnt/c/WINDOWS/system32/wsl.exe: cannot execute binary file: Exec format error

I don't know what I did right, just I followed the instructions I found in this discussion...

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

sudo systemctl restart systemd-binfmt

sudo systemctl restart binfmt-support

sudo systemctl start binfmt-support.service

And try update WSL2

wsl --install

And I restarted my machine. Now everything works as before... thank you!!

[DarkStar777]

I had this same issue after 'systemctl halt' (WSL2 Ubuntu 22_04), powershell.exe wouldn't execute, etc. All I had to do was 'wsl --shutdown' and bring it back up and everything started working again, didn't require any further changes for me in this case.

[lackovic]

I am suddenly getting this error with any executable, examples:

$ explorer.exe .
-bash: /mnt/c/WINDOWS/explorer.exe: cannot execute binary file: Exec format error

$ code .
/mnt/c/Users/Marco/AppData/Local/Programs/Microsoft VS Code/bin/code: 61: /mnt/c/Users/Marco/AppData/Local/Programs/Microsoft VS Code/Code.exe: Exec format error

I did not change anything from yesterday nor fiddle with any configuration, I just ran a regular system update with:

sudo apt update; sudo apt upgrade -y; sudo apt autoremove -y

Any idea what might have caused this issue and how to fix it?

[theko2fi]

I just want to report that I have the same problem as @lackovic . I'm running WSL2 with systemd enabled. I didn't make any change to my system and this error suddenly show up after turning on my computer this morning.

[strottie]

Same here, I just noticed today that running PE32s didn't work. I have systemd enabled.

I know I ran an aptitude safe-upgrade in the last week, that's probably when the issue started for me. Even the "binfmt-support" package got removed.

I re-installed binfmt-support (wasn't enough on its own).
I then ran @freckhard's WSLInterop.conf suggestion from #8843 (comment) and rebooted wsl.

In short, this fixed it for me:

wsl> sudo apt install binfmt-support
wsl> sudo sh -c 'echo :WSLInterop:M::MZ::/init:PF > /usr/lib/binfmt.d/WSLInterop.conf'
wsl> exit
powershell> wsl --shutdown
powershell> wsl
wsl> /mnt/c/WINDOWS/explorer.exe
(now works!)

Thanks all!

[duelSwords]

I ran into this issue this morning. It working fine last night but this morning got that /mnt/c/Program Files/Microsoft VS Code/bin/code: 61: /mnt/c/Program Files/Microsoft VS Code/Code.exe: Exec format error

Running the binfmt-support and WSLInterop.conf resolved the issue.

@strottie Thank you for the step by step fix.

[newbenji]

Same problem as others .the changes mentioned here works

[phillipdebruin]

wsl> sudo apt install binfmt-support
wsl> sudo sh -c 'echo :WSLInterop:M::MZ::/init:PF > /usr/lib/binfmt.d/WSLInterop.conf'
wsl> exit
powershell> wsl --shutdown
powershell> wsl

Thanks so much, it's working again for me. I have some error output when launching links to my browser.

Cannot find an overload for "GetEncoding" and the argument count: "0".
At line:1 char:59
+ ... ing]::UTF8; [Console]::InputEncoding = [System.Text.Encoding]::GetEnc ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodException
    + FullyQualifiedErrorId : MethodCountCouldNotFindBest

[weibeld]

This error appeared out of the blue. And the crazy thing is that it seems to be non-deterministic. Sometimes Windows executables work fine at the beginning of a sesssion in a Linux distribution, and then suddenly after a while they don't work anymore and the cannot execute binary file: Exec format error error occurs.

Terminating and restarting the Linux distribution sometimes helps and sometimes it doesn't. However, then after a while the error usually occurs again.

The solution proposed above (i.e. install binfmt-support and creating /usr/lib/binfmt.d/WSLInterop.conf) so far didn't fix the problem.

[maroskukan]

@strottie solution worked for me.

[YevheniiPokhvalii]

Something's just happened out of nowhere. Never had this problem before:

$ wslview .
grep: /proc/sys/fs/binfmt_misc/WSLInterop: No such file or directory
WSL Interopability is disabled. Please enable it before using WSL.
grep: /proc/sys/fs/binfmt_misc/WSLInterop: No such file or directory
[error] WSL Interoperability is disabled. Please enable it before using WSL.
/usr/bin/wslview: line 216: /mnt/c/Windows/System32/reg.exe: cannot execute binary file: Exec format error
/usr/bin/wslview: line 316: [: -ge: unary operator expected
[error] This protocol is not supported before version 1903.
$ explorer.exe .
-bash: /mnt/c/WINDOWS/explorer.exe: cannot execute binary file: Exec format error
$

> wsl --version
WSL version: 1.2.5.0
Kernel version: 5.15.90.1
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.1992

The solution from @strottie helped. For some reason this file /usr/lib/binfmt.d/WSLInterop.conf got disappeared on my system.

[jura1243]

I had the same error. But after removing docker-desktop and restarting the computer, it disappeared.

wsl --version Версия WSL: 1.2.5.0
Версия ядра: 5.15.90.1
Версия WSLg: 1.0.51
Версия MSRDC: 1.2.3770
Версия Direct3D: 1.608.2-61064218
Версия DXCore: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Версия Windows: 10.0.22621.2215

[kimu]

This issue happens to me every time I start or stop Minikube with docker driver in WSL.
I am using Docker Desktop, and based on @jura1243 comment, I wonder if there is a correlation.
Currently I have systemd enabled, but I have come across the same issue also with systemd disabled.

Creating the /usr/lib/binfmt.d/WSLInterop.conf file works with systemd enabled, but I have to run sudo systemctl restart systemd-binfmt every time I do something with Minikube .
This solution in my case is not permanent, it is just temporarily removed/patched between minikube start and stop commands.

With systemd disabled I could not find a workaround, which suggests to me that creating the WSInterop.conf file is a patch that happens to work with systemd enabled, but it is masking the real problem more than anything.
I cannot pinpoint what is causing this issue, and I am not sure Minikube is directly involved either in this case.
As I have seen this error both with systemd enabled and disabled, chances are that the problem lies somewhere else, it just happens that Minikube does that one thing that triggers it.
I work on 2 PC, the first one has never shown this behaviour, but I am also quite sure than I have never enabled systemd on that machine. On the second machine, where systemd has been turned on and off a few times, this issue happens regardless of whether systemd is enabled or disabled.
I have also uninstalled Ubuntu, cleaned the distro files, and re-installed everything from scratch again but to no avail. The issue persists.

Anyway, thanks for providing a workaround in this thread. It has been extremely helpful.

[alkuzad]

This issue happens to me every time I start or stop Minikube with docker driver in WSL. I am using Docker Desktop, and based on @jura1243 comment, I wonder if there is a correlation. Currently I have systemd enabled, but I have come across the same issue also with systemd disabled.

Creating the /usr/lib/binfmt.d/WSLInterop.conf file works with systemd enabled, but I have to run sudo systemctl restart systemd-binfmt every time I do something with Minikube . This solution in my case is not permanent, it is just temporarily removed/patched between minikube start and stop commands.

With systemd disabled I could not find a workaround, which suggests to me that creating the WSInterop.conf file is a patch that happens to work with systemd enabled, but it is masking the real problem more than anything. I cannot pinpoint what is causing this issue, and I am not sure Minikube is directly involved either in this case. As I have seen this error both with systemd enabled and disabled, chances are that the problem lies somewhere else, it just happens that Minikube does that one thing that triggers it. I work on 2 PC, the first one has never shown this behaviour, but I am also quite sure than I have never enabled systemd on that machine. On the second machine, where systemd has been turned on and off a few times, this issue happens regardless of whether systemd is enabled or disabled. I have also uninstalled Ubuntu, cleaned the distro files, and re-installed everything from scratch again but to no avail. The issue persists.

Anyway, thanks for providing a workaround in this thread. It has been extremely helpful.

I had similar issue and this is my perma workaround that helps in the case that some command (docker in my case) is breaks the interop

#8843 (comment)