[Bug] WoW Classic (_anniversary_) on Winlator+FEX: NoExec instruction in entry block then C0000005 storm

[FrontMage]

[Bug] WoW Classic (_anniversary_) on Winlator + FEX: NoExec instruction in entry block then C0000005 exception storm

Summary

On Android (Winlator + Wine arm64ec + FEX DLL backend), launching WoW Classic starts loading normally, then fails with:

• NoExec instruction in entry block: 1921612
• first AV at native_pc=7FFFFE0528 guest_rip=1921612
• repeated C0000005 loop (1921612 / 192054F)

This looks like an executable mapped region not being tracked as executable by FEX code-region tracking.

Environment

• Host app package: com.winlator.llm
• Winlator repo commit: a226467
• FEX subrepo commit used to build DLLs: 1268a3910
• Wine: proton-10-arm64ec
• HODLL=libwow64fex.dll
• GPU stack: Turnip 26.0.0, WRAPPER_VK_VERSION=1.3.335, GALLIUM_DRIVER=zink
• WoW path: D:\wow\World of Warcraft\_anniversary_\WowClassic.exe

Relevant env (trimmed):

• FEX_AV_TRACE=1
• FEX_SILENTLOG=0
• FEX_SMC_CHECKS=mtrack
• FEX_VOLATILEMETADATA=1
• FEX_DISABLEL2CACHE=0
• FEX_DYNAMICL1CACHE=0
• FEX_TRACE_MEM_EVENTS=1
• FEX_TRACE_SYSCALL_MEM=1

Repro

1. Launch Winlator container.
2. Start WoW Classic (_anniversary_) in x86 path under FEX.
3. Observe immediate failure/hang/exit.

Expected

WoW continues startup (at least past loader stage) without entering AV loop.

Actual

WowClassic.exe and WowClassic_loader.dll load successfully, then execution enters NoExec + AV loop.

Key log excerpts

From wine.log:

1. Module load succeeds:

   • Load module WowClassic.exe ...
   • Load module WowClassic_loader.dll ...

2. NoExec on unknown executable address:

   • exec.query addr=1921612 -> base=0 size=0 writable=0 thread_arg=1
   • exec.query.mem: addr=1921612 base=1921000 end=1A20000 size=FF000 state=1000 protect=20 alloc_protect=20 type=40000
   • NoExec instruction in entry block: 1921612

3. First AV:

   • Exception: Code: C0000005 Address: 7FFFFE0528
   • first_av native_pc=7FFFFE0528 guest_rip=1921612 fault=0
   • first_av.guest_rip: 1921612 (unknown module)

4. Exception storm:

   • repeated:
     • Exception: Code: C0000005 Address: 7FFFFE0528
     • Exception: Code: C0000005 Address: 192054F
     • Reconstructing context ... Passing through exception

5. Important detail:

   • failing address is in mapped executable memory (type=0x40000, protect=0x20)
   • but exec.query still returns empty tracked range (base=0 size=0)

Additional observation

Extra tracing around map/unmap was added locally.

This run shows many NotifyUnmapViewOfSection traces (tracker=1 thread_state=1), but no matching NtMapViewOfSection-style registration logs for the failing region.

Questions for FEX maintainers

1. In WOW64/ARM64EC flow, should MEM_MAPPED + PAGE_EXECUTE_READ regions always be registered into executable code tracking?
2. Is this a known gap in NtMapViewOfSection(Ex) (or another map path) in the Windows frontend?
3. Which exact registration path is expected to cover this region?
4. Any known regressions around NoExec instruction in entry block with unknown-module addresses on Windows backend?

Artifacts

I will attach full artifacts in follow-up comments:

• full wine.log
• filtered logcat
• full launch env block
  issue-5328-logs.tar.gz

[Sonicadvance1]

This sounds like a limitation of wine arm64ec, it doesn't know how to handle old applications that require NX to be missing and it has no way to tell FEX to ignore NX.

afaik arm64 on Windows on ARM would have the same problem. (Unless it has some key on wow.exe or whatever)

[FrontMage]

Thanks for the hint — I tested the NX workaround path.

I set FEX_WIN_EXEC_QUERY_FALLBACK_MODE=2 (ignore NX executable query result in our Wine+FEX
setup) and re-ran WoW Classic.

Result:

• It does get past the previous immediate execution-permission failure path.
• WowClassic.exe stays alive (not instant process death).
• But it now hits a deeper stall: repeated Exception: Code: 80000002
  (EXCEPTION_DATATYPE_MISALIGNMENT) with many Handled unaligned atomic messages.
• The app remains black-screened and does not progress to graphics init (dxgi/d3d11/d3d12/ vkd3d never appear in module load path for this run).

So it looks like ignoring NX removes one blocker, but we then hit a second blocker (heavy
unaligned-atomic exception loop) before render initialization.

If you have recommended knobs/diagnostics for this second stage (especially around alignment/
atomic emulation behavior in this arm64ec + Wine scenario), I can run those immediately and
share logs.

[Sonicadvance1]

Unaligned atomic handling is just a requirement for x86 emulation. This is why FEX installs a SIGBUS handler.

[FrontMage]

Thanks for the clarification.

I re-checked our latest repro while filtering out 0x80000002
(EXCEPTION_DATATYPE_MISALIGNMENT) as a non-root signal.

So after excluding 0x80000002, we still have a stall, but no new hard-failure signature to
anchor root cause yet.
At the moment, the practical symptom is: execution gets past image loading, then stops making
forward progress before graphics initialization.

[bylaws]

This feature is pending and is supported on arm64 windows

[FrontMage]

@bylaws Thanks for the clarification.

Just to confirm, by “this feature is pending and is supported on arm64 Windows”, do you mean
support for this NX-related compatibility path (i.e., handling older apps that expect executable
behavior not fully aligned with NX enforcement)?

If yes, is the expected long-term fix primarily on the Wine arm64ec side, the FEX side, or
coordinated between both?