0

I'm trying to figure out what is going on. I observe the following.

  • exe binary compiled on Windows 10
  • elf binary compiled on CentOS7 with musl
  • User 1 WSL2: elf binary runs, exe binary runs (updated)
  • User 2 WSL2: elf binary error, exe binary runs (surprised #1)
  • User 3 WSL2: elf binary runs, exe binary runs (surprised #2)

Note, the errors are executable format errors from the OS, not program crashes.

On a new machine I can recreate the User 1 experience, but I have no clue why the other users are having their experiences. I have verified through screen sharing what they are observing.

EDIT This information about compatibility for running different types of executables in WSL and how it has changed over time may be helpful when I can learn more about the users during the next meeting. https://stackoverflow.com/questions/38920710/how-can-i-run-a-windows-executable-from-wsl-ubuntu-bash

EDIT I plan to gather more information next time I can meet with the users, such as:

  • windows version
  • WSL version
  • terminal shell / how the terminal was invoked
4
  • A few questions -- What are the errors that were seen in each case? I'm assuming the elf error might have been an Exec format error? Also, confirm that each user really is using WSL2 with wsl -l -v. Often times, even though the WSL2 subsystem itself is installed, the instance is still WSL1 for various reasons. Finally, check uname -a on each system.
    – NotTheDr01ds
    Feb 15, 2022 at 20:25
  • @NotTheDr01ds I will add uname -a to the diagnostics for our next meeting. Yes, exec format error - I will update my answer.
    – GGibson
    Feb 16, 2022 at 16:58
  • Sounds good - I'll try to keep an eye out for any edits to the question. Just in case I miss it, feel free to @tag me so I get notified when you update. I'm pretty confident we can come up the reason for the differences.
    – NotTheDr01ds
    Feb 16, 2022 at 18:51
  • @NotTheDr01ds I had the User 1 story wrong, so maybe the set of experiences makes more sense. I've been unable to meet with the users but believe I have the answer. Will post as an answer.
    – GGibson
    Feb 18, 2022 at 17:45

2 Answers 2

Reset to default
2

Not a complete answer, but I'll come back to it as you gather more information.

But for now, you mention surprise at the User #2 case, where both elf and Windows (PE) binaries run.

But that's the "normal" case for WSL. WSL allows execution of Windows binaries as long as the full name is specified, including the .exe extension. For instance, executing notepad.exe in WSL will pretty much always work with the out-of-the-box defaults.

It does this by registering with the PE format with Linux's binfmt_misc during init. You can see this via cat /proc/sys/fs/binfmt_misc/WSLInterop. Interesting (to me, anyway) TIL sidenote that the magic bytes of 4d5a that designate a Windows binary have their roots in the original DOS PE format, and those are the hex ASCII characters "mz", standing for Mark Zbikowsky, one of the original DOS architects.

Note that this support can be disabled in a number of ways, so if a user isn't able to run a Windows binary, check the results of cat /proc/sys/fs/binfmt_misc/WSLInterop as mentioned above.

Also, as you've mentioned, check the WSL version, along with more information on the executable. Are the executables compiled for 32-bit or 64-bit architecture? If I recall correctly, WSL1 can only run 64-bit binaries, but WSL2 can run both.

1

I've been unable to meet with the users again yet, but I believe I have figured out what is going on.

  1. WSL has a spotty history of supporting UPX compressed binaries. Our binary has always been UPX compressed, but support in WSL for this has varied across time. I've now disabled UPX compression and the binary runs for every linux distribution - WSL included - without issue.

  2. Windows is now automatically removing our exe from user computers as the result of a new false positive Windows Defender status. This caused User 1 to report the "program wasn't running correctly and giving an error" when actually the program didn't exist, which is a completely different error. I've rolled back windows-specific support to an earlier version that did not trigger this behavior, thus solving this problem suboptimally for the time being.

2
  • Special thanks to @NotTheDr01ds for helpful discussion and encouragement.
    – GGibson
    Feb 18, 2022 at 17:52
  • Cool - Great find on the UPX info. For the Windows Defender problem, if user 1 is running WSL2, you could try moving the Windows binary into the instance itself (somewhere not on a Windows drive). In my experience, Defender can't find/scan binaries in the virtual HDD.
    – NotTheDr01ds
    Feb 18, 2022 at 18:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .