“cannot execute binary file: Exec format error” means the environment rejected the executable before PHP started. Confirm the WSL architecture, package architecture, ELF interpreter, and dependency chain before replacing binaries or wrapping the dynamic loader.
Last updated: November 3, 2026.
wsl.exe -l -v
uname -m
dpkg --print-architecture
file /usr/bin/php8.5
readelf -l /usr/bin/php8.5 | grep interpreter
ldd /usr/bin/php8.5
dpkg -S /usr/bin/php8.5
apt-cache policy php8.5-cliRun the Windows command from PowerShell and the remaining commands inside the affected distribution. Save the output and compare it with a PHP version that still runs.
Separate architecture problems from WSL compatibility
An amd64 package should report an x86-64 ELF executable and a dynamic interpreter that exists in the distribution. A mismatched CPU architecture, damaged download, missing interpreter, or third-party package built with incompatible assumptions can all fail before normal dependency errors appear.
Microsoft’s WSL version comparison explains that WSL 1 translates Linux system calls, while WSL 2 runs a real Linux kernel with full system-call compatibility. A valid Linux binary can therefore expose a WSL 1 compatibility limit even when its architecture matches.
Prefer a supported environment over modifying package files
Update WSL and the distribution, then reproduce with the distribution’s supported PHP package. If only one third-party build fails, report the exact package version, Windows build, WSL mode, ELF details, and a minimal reproduction to the package maintainer.
When possible, convert the distribution with wsl --set-version <Distribution> 2 and keep active project files in the Linux filesystem to reduce cross-filesystem overhead. Test the application and extensions after conversion. If WSL 1 is mandatory, use a PHP build known to support that environment until the incompatibility is understood.
Invoking a binary directly through ld-linux can be a useful diagnostic, but replacing package-managed executables with wrapper scripts is fragile: upgrades overwrite them, service units may behave differently, and the real incompatibility remains. Do not make that the first production fix. Continue with installing PHP on Windows, diagnosing PHP DLL dependencies, and PHP runtime troubleshooting.