Pulse Agent Host service not starting

[sibberio]

Describe the bug
After upgrading Pulse to version 4.26.4 and successfully installed the host on my Windows PC I was not able to start the service.
The error on event viewe is: The Pulse Host Agent is not compatible with this Windows version

To Reproduce
Steps to reproduce the behavior:

1. Run the command in powershell
2. Get the error
3. Check event viewer

Expected behavior
Service start correctly

Environment:

• Pulse Version: 4.26.4
• Installation Type: Proxmox LXC
• Windows 11 version 25H2

[rcourtman]

Windows 11 25H2 hardware is ARM64. The installer pulled the windows amd64 host agent, so the Service Control Manager tried to load an amd64 PE on an ARM64 loader. That raises ERROR_BAD_EXE_FORMAT, which Windows surfaces as "The Pulse Host Agent is not compatible with this Windows version".

Windows arm64 binaries now build and the installer detects ARM64 properly. Dockerfile, build-release.sh, and install-host-agent.ps1 already carry the fix and it ships in the next Pulse release. After upgrading, rerun the installer so it fetches the arm64 binary.

To confirm the system architecture run

[System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture

[sibberio]

In my case the architecture is X64.
I just upgraded form 24H2

[rcourtman]

ERROR_BAD_EXE_FORMAT on x64 Windows only happens when the file the Service Control Manager launches is not a valid 64 bit executable. The host agent is statically built and carries all its own runtime code, so the message almost always means the wrong bits reached the machine rather than a missing dependency.

First confirm the download is intact. Run Get-FileHash "C:\Program Files\Pulse\pulse-host-agent.exe" -Algorithm SHA256. A healthy build is 356b70b3a3ad8b8606e0e164942b6938dde0ac4e531b6f7930fa23d88baab5d2 and is roughly 6.2 MB. Anything else points to corruption, antivirus tampering, or a proxy handing back the wrong file.

Next run Format-Hex -Path "C:\Program Files\Pulse\pulse-host-agent.exe" | Select-Object -First 1. The very first two bytes must be 4d 5a. If you see text such as HTML, a gzip header, or zeros then something upstream delivered the wrong content.

Run sc.exe qc PulseHostAgent and check that BINARY_PATH_NAME still points at C:\Program Files\Pulse\pulse-host-agent.exe .... If that path was edited to a zip file, a quarantine stub, or anything else, Windows will throw the same error before the agent even starts.

Finally look in Windows Security or your AV console for a recent entry mentioning pulse-host-agent.exe. Some products silently replace blocked programs with placeholders, which again makes the loader report ERROR_BAD_EXE_FORMAT.

Those checks will tell whether the download pipeline is handing you the expected binary or if something in the path is swapping it out. Once you have the hash or hex snippet from your host, post it here and it will be clearer where to dig next.

[sibberio]

I tried again with version 4.26.5 but I had to manually download the host agent pulse-host-agent-v4.26.5-windows-amd64.zip copy to the right folder and rename it to pulse-host-agent.exe because the powershell command from Pulse was not working (I think it install a wrong agent)

As you can see now is working and it's realy cool!!

[rcourtman]

The 4.26.4 Docker image most likely shipped without the Windows host-agent binary inside /opt/pulse/bin, so the download endpoint tried its fallback and sent the Linux build instead of stopping. PowerShell stored that Linux file as pulse-host-agent.exe, which Windows cannot run, so the installer showed ERROR_BAD_EXE_FORMAT.

Manual download from the GitHub release worked because the release zip always contained the correct Windows binary. Extracting it yourself bypassed the broken endpoint.

The next release will include these changes.

1. The download endpoint now stops with a clear error anytime a requested platform or architecture binary is missing.
2. The PowerShell installer now checks the Windows executable header and machine type before it touches the service.
3. The installer now fetches the SHA256 checksum and confirms the download matches.
4. The installer now prints the architecture it detected, the download URL it used, and the size of the file it saved, so future reports can include that information.