ARM64EC static libraries fail when linked into ARM64X DLLs

[thantthet]

Summary

Rust-generated ARM64EC static libraries cause crashes (0xc0000096 - privileged instruction) when statically linked into ARM64X DLLs and loaded by x64 processes on ARM64 Windows. The same scenario works correctly with MSVC-compiled ARM64EC static libraries.

Environment

• Rust version: rustc 1.88.0 (6b00bc3 2025-06-23)
• Platform: Windows 11 ARM64 (10.0.26100)
• Target: arm64ec-pc-windows-msvc
• Toolchain: Visual Studio 2022 17.11+ with ARM64/ARM64EC build tools

Steps to Reproduce

1. Create a minimal Rust library with C FFI exports
2. Build it as static library for both aarch64-pc-windows-msvc and arm64ec-pc-windows-msvc
3. Link both static libraries into an ARM64X DLL using /machine:arm64x
4. Load the DLL from an x64 process on ARM64 Windows
5. Process crashes with 0xc0000096

Attached arm64x-rust-test.zip for minimal reproducible example

Expected Behavior

The ARM64X DLL should load successfully in x64 processes, with the ARM64EC code handling the x64 emulation layer properly, just as it does with MSVC-compiled ARM64EC static libraries.

Actual Behavior

x64 processes crash immediately upon loading the ARM64X DLL with error 0xc0000096 (privileged instruction).

Additional Context

• Works: Standalone ARM64EC DLL (not ARM64X) loads fine in x64 processes
• Works: ARM64X DLL without Rust (pure C++) loads fine in x64 processes
• Works: Same ARM64X DLL with Rust loads fine in ARM64 processes
• Fails: Only fails when x64 process loads ARM64X DLL containing Rust ARM64EC static lib

This suggests the issue is specific to the static library format and how the ARM64X linker processes Rust-generated ARM64EC objects.

Workarounds

1. Build separate architecture-specific DLLs instead of ARM64X
2. Use dynamic linking (Rust as separate DLL)
3. Avoid Rust in ARM64X components

---

This issue affects any Windows on ARM application trying to use Rust in system components that must support both ARM64 and x64 processes (like Text Services Framework, shell extensions, COM servers, etc.).

[wesleywiser]

cc @dpaoliello

[dpaoliello]

Can you please try with Nightly: LLVM 21 contains a bunch of fixes to Arm64EC that may help with this.

[thantthet]

Unfortunately, still crashes with rustc 1.91.0-nightly (ca77504 2025-08-09)

[dpaoliello]

I enabled debug symbols, and the crash is happening at std::sys::thread_local::guard::windows::tls_callback+0x9.

If I set a breakpoint for std::sys::thread_local::guard::windows::tls_callback and step through, I see an AV and then illegal instruction exceptions at tls_callback+0x2.

Note the offsets: all Arm64 instructions are 4 bytes long, so we should never be executing at +0x2 or +0x9 UNLESS Windows is interpreting the code stream as x64 instead of Arm64.

tls_callback is a weird function in that a pointer to it is placed in the .CRT$XLB section and, by some magic, Windows will execute the code at DLL attach/detach time. My current theory is that, since this is an x64 process and we're directly executing the function rather than calling via some entry thunk, Windows is executing in x64 mode and doesn't switch to Arm64 mode.

I'm not entirely sure how to fix this, but I'll see what we can do...