Type of issue

• Error when running a workflow.
• Request for additional tools or software for an existing image.
• Request for a new image, Linux or Windows.
• Other

Describe the issue

Composite action steps using shell: bash on windows-11-arm intermittently produce zero output and exit code 0, even though the bash script (set -CeEuo pipefail) has no valid code path that exits 0 silently. The step is reported as "success" but the tool it was supposed to install is missing, causing downstream steps to fail.

This has been observed across two repositories (microsoft/Windows-rust-driver-samples and microsoft/windows-drivers-rs). A scan of ~500 Build workflow runs found at least 9 occurrences in Windows-rust-driver-samples alone, and the issue likely affects any composite action using shell: bash on this runner. It occurs exclusively on windows-11-arm — zero occurrences across thousands of windows-latest (amd64) jobs in the same workflows.

The affected step runs taiki-e/install-action@v2, which is a composite action whose main step is:

- run: bash --noprofile --norc "${GITHUB_ACTION_PATH:?}/main.sh"
  shell: bash

On windows-11-arm, shell: bash resolves to C:\Program Files\Git\bin\bash.EXE, which is an x86_64 binary running under WoW64 arm64 emulation. The actions/runner builds a native win-arm64 runner. This cross-architecture parent-child process launch (native arm64 runner starting x86_64 emulated bash) is unique to windows-11-arm and is the suspected root cause.

Crucially, the failure is transient per-process-invocation. In this windows-drivers-rs job, two consecutive taiki-e/install-action@v2 steps ran on the same runner, same job, 6 seconds apart:

• Install Cargo Expand (step 8): bash main.sh -> zero output, exit 0, cargo-expand not installed
• Install Cargo Make (step 9): bash main.sh -> normal output, cargo-make installed successfully

This rules out image corruption, runner misconfiguration, or persistent state issues.

To Reproduce

This is an intermittent issue. It can be observed by running a workflow with a composite action using shell: bash on windows-11-arm at scale.

Sample occurrences from microsoft/Windows-rust-driver-samples (Build workflow, cargo-make not installed):

From microsoft/windows-drivers-rs (Test workflow, cargo-expand not installed):

In each case, the composite action's bash step shows the command and env dump in the log but produces zero output from the script itself. Downstream steps then fail with errors like:

error: no such command: `make`

or:

error: no such command: `expand`

Expected behavior

The composite action step should either:

1. Execute the bash script and produce its normal output (e.g., info: host platform: x86_64_windows, info: installing cargo-make@latest, etc.), OR
2. If execution fails, report a non-zero exit code so the step is marked as failed.

For reference, a successful arm64 job in the same run produces:

info: host platform: x86_64_windows
info: cargo is located at /c/Users/runneradmin/.cargo/bin/cargo
info: installing cargo-make@latest
info: downloading https://github.com/sagiegurari/cargo-make/releases/download/0.37.24/cargo-make-v0.37.24-x86_64-pc-windows-msvc.zip
info: verifying sha256 checksum for cargo-make-v0.37.24-x86_64-pc-windows-msvc.zip
info: cargo-make installed at /c/Users/runneradmin/.cargo/bin/cargo-make.exe
+ cargo-make make --version
cargo-make 0.37.24

Desktop (please complete the following information):

• OS: windows-11-arm (Windows 11 Enterprise, 10.0.26100, Arm64)
• Image: Microsoft Windows 11 Desktop by Arm Limited (partner image, version 20260127.44.1)
• Runner version: 2.331.0
• Shell: C:\Program Files\Git\bin\bash.EXE (x86_64 under WoW64 arm64 emulation)

Additional context

• The main.sh script uses set -CeEuo pipefail and has no valid code path that exits 0 with zero output. The first unconditional output (info: host platform: ...) is reached before any tool-specific logic. Zero output means the script never executed.
• The failing steps take 0-3 seconds (vs 2-7 seconds normally), suggesting the bash process starts but the script body does not run.
• The issue is not specific to any particular composite action or tool -- it affects the shell: bash execution itself. It has been observed with both cargo-make and cargo-expand installs via taiki-e/install-action@v2, and the windows-drivers-rs job demonstrates that it can hit one step while the very next step on the same runner succeeds.
• On windows-11-arm, Git Bash is x86_64 under emulation (uname -m returns x86_64). The suspected root cause is an intermittent failure in x86_64 process execution under arm64 WoW64 emulation when launched by the native arm64 runner process.
• No existing issues found in actions/runner, actions/partner-runner-images, or taiki-e/install-action for this pattern.