WoW Classic on Android (box64 + Wine x86_64): after fixing dynarec FillBlock storm, startup still fails on INT 0x2c -> STATUS_ASSERTION_FAILURE (0xC0000420)

[FrontMage]

Environment

• Device: Snapdragon 8 Gen 2 (Android)
• Stack: box64 + Wine x86_64 (Winlator-based environment)
• Wine baseline: Proton 9.0 codebase, with local integration/debug patches
• box64: local debug build with extra instrumentation for FillBlock + INT paths

Summary

This was debugged in two stages:

1. Stage A (fixed): dynarec FillBlock storm
2. Stage B (current blocker): INT 0x2c -> c0000420 unhandled

---

Stage A: FillBlock storm (pre-fix)

Before the current assertion failure, runs repeatedly hit FillBlock segfault/cancel loops.
From /tmp/winlator_cmod/wfm_2026-02-24_20-24-56.txt:

[BOX64] FillBlock triggered a segfault at 0x2 from 0x6237543b08
[BOX64] FillBlock at 0x6edec400 triggered a segfault, canceling
[BOX64] FillBlock triggered a segfault at 0x2 from 0x6237543b08
[BOX64] FillBlock at 0x6edec400 triggered a segfault, canceling
[BOX64] FillBlock triggered a segfault at 0x2 from 0x6237543b08
[BOX64] FillBlock at 0x6edec409 triggered a segfault, canceling
[BOX64] FillBlock triggered a segfault at 0x2 from 0x6237543b08
[BOX64] FillBlock at 0x6edec40f triggered a segfault, canceling

After fixing this path (safe diagnostics + robust fault-path handling), startup proceeds further and no longer dies at this stage.

---

Stage B: Current blocker (INT 0x2c -> c0000420)

WoW loader attach completes

01b4:err:module:process_attach [LDRDBG] process_attach initdll leave tid=01b4 dll=L"WowClassic_loader.dll" status=00000000
01b4:err:module:process_attach [LDRDBG] process_attach end tid=01b4 dll=L"WowClassic_loader.dll" status=00000000

box64 emits INT 0x2c

[BOX64] [BOX64_INTDBG] EmitInterruption num=0x2c rip=0x7fff623ea0 rsp=0x7dafd18 rbp=0x7dafd50 cs=0x33 ss=0x2b si_code=44 si_errno=0xdead addr=0x7fff623ea0
[BOX64] [BOX64_INTDBG] signal-map int=0x2c trapno=13 err=0x162 skip=3 rip=0x7fff623ea0 rsp=0x7dafd18 rbp=0x7dafd50 si_code=44

Wine sees assertion failure and does not recover

01c4:err:seh:dispatch_exception [LDRDBG] dispatch_exception enter tid=01c4 code=c0000420 flags=00000000 addr=0000007FFF623EA0 rip=7fff623ea0 rsp=7dafd18 rbp=7dafd50
01c4:err:seh:dispatch_exception unknown exception (code=c0000420) raised

Current understanding

• WowClassic_loader.dll attach completes successfully.
• Fatal path is later: INT 0x2c -> STATUS_ASSERTION_FAILURE.
• This is no longer the old FillBlock crash.
• Likely compatibility/semantics issue in assertion delivery/handling under box64 + Wine.

Questions

1. Is current box64 INT 0x2c mapping/delivery (trapno=13, err=0x162) correct for Wine x86_64 expectation?
2. Is this a known compatibility gap for WoW/Blizzard binaries on this stack?
3. Any recommended box64-side handling tweak for this specific assertion path?

[ptitSeb]

1. Yes
2. No
3. Try BOX64_DYNAREC_SAFEFLAGS=2 as it might be needed for DRM/Encrypted binaries.

[ptitSeb]

Do you plan to commit the pre-fix for the FillBlock faillure?

[FrontMage]

Yes, PR is on the way.

[FrontMage]

Thanks for the quick suggestion.

I tested BOX64_DYNAREC_SAFEFLAGS=2 (both globally and process-scoped for WowClassic.exe),
but it doesn’t change the behavior on my side.

The run still progresses past loader attach, then hits the same path:

• INT 0x2c emitted by box64
• Wine receives STATUS_ASSERTION_FAILURE (0xC0000420)
• exception remains unhandled and process exits

I’ve also sent the FillBlock pre-fix separately in PR #3590, as discussed.

If you have other knobs you’d like me to test next (e.g. specific dynarec options / profile
combinations), I can run them and report back with logs.

[ptitSeb]

Pretty sure the "int 2c" is triggered by the program because there is an assertion faillure. So the issue must happens before the int 2c. That interupt is the conclusion, the issue is before.
You can also try to run without dynarec (at the process level, for speed consideration), as it might be an issue on the Dynarec side ony.

[FrontMage]

Thanks for the clarification — agreed, int 0x2c looks like the conclusion, not the root cause.

I tested process-level no-dynarec as you suggested, and the behavior is still reproducible:

• startup goes past the previous FillBlock failure stage(which will also be fixed in the PR),
• then reaches the same STATUS_ASSERTION_FAILURE (0xC0000420) path.

So at this point it does not look dynarec-only on my side.

If helpful, I can provide a reduced pre-assert trace window focused only on:

• WowClassic_loader.dll attach completion
• the last successful LdrLoadDll/process_attach sequence before the first c0000420.

My current hypothesis is that this may be a timing/order issue (state initialization sequence),
where some earlier condition is not fully established before the assertion path is reached.

[ptitSeb]

I have reduce the case where the check at a page frontier is done to only memory not file-mapped. As this test will disallow dynarec to be used in the last 15 byte of a page if the next page is not readeable, this bother me, so I want to reduce even more those cases. Can you check if it's still ok on your side?

[FrontMage]

Tested on commit f288184.

The change significantly reduces the FillBlock fault storm on my side.
Most of the previous FillBlock segfault/cancel spam is now gone, but I still see a few residual cases leaking through.

[BOX64] FillBlock triggered a segfault at 0x1401bb000 from 0x591d3557fc
[BOX64] FillBlock at 0x1401bafff triggered a segfault, canceling
[BOX64] FillBlock triggered a segfault at 0x1401bb000 from 0x591d3557fc
[BOX64] FillBlock at 0x1401bafff triggered a segfault, canceling

Only these two are still leaking.

[ptitSeb]

That seems acceptable for now.
I'll have a better solution later, I have an idea on how to refactore FillBlock to have it more resiliant to error like that.

[ptitSeb]

So, I have change the way error handling occur, and if a segfault appears durring pass0, the block will be truncated (prior to the segfault) instead of being canceled. That means you will still see the FillBlock error, but only 1 time, warning that the block is truncated. That way, there is no waste, the good part of the block will be proceeded correctly.

[FrontMage]

Awesome, that way they won't actually "block" anything. Should I close this issue then?

[ptitSeb]

not yet, I want to remove all the check and rely on the segfault signal handling completly, but I haven't pushed that change yet