Crash on Snapdragon cpu

[mirh]

Game name and version:

Don't Stop, Girlypop! (please no shade, it's just a normal UE 5.4.4 game like another.. it's comfy because it has a free demo)

Mods and mod versions used

OptiScaler v0.9.3

GPU

Adreno X2-90

OS

Win 11 26H1

Used automated or manual install?

• Automated
• Manual

If on AMD/Intel and Automated, used DLSS inputs?

• Yes
• No

Did you check the Wiki and Compatibility List?

I did check Luma. Which can get in-game at least? Even though it also crashes sometimes.

Please describe the issue and steps to reproduce it

When I use the dxgi, winmm, d3d12 names the game altogether crash on start with ERROR_ILLEGAL_INSTRUCTION in the vanilla UE crash reporter.
I also tried to attach windbg, but I couldn't get much more than this because I guess it may be crashing the x86 emulator.

Illegal instruction - code c000001d (first chance)
Access violation - code c0000005 (first chance)
INVALID_POINTER_READ_c0000005_ntdll.dll!#RtlEcContextToNativeContext

And now, you will tell me: that's the life when jumping on the arm64 boat.
But I'm actually reporting this because I swear, this is the first time of all the stuff I have thrown at this new laptop that I'm getting problems.
Like prism should support even AVX2 since a good while by now, so I really cannot understand what's special here to fail it.

I have attached

• OptiScaler.log

[TheRazerMD]

You're probably on your own here, there's 0 info in the log, and there's no way for us to reproduce this.

[mirh]

I understand.
Would it be possible to get custom builds with just a subset of apis/features enabled, or some random foo bar logging added?
Actually now that I check the log.. the crash seems to happen somewhere in the DxgiFactoryHooks::HookToFactory function, before DxgiSpoofing::AttachToAdapter can work.
So that either means something with the EnumAdapters calls, or something with detours. And after casually checking it I noticed one of its proxies involves Kernelbase hooking, which was actually the line before to the other ones in the debugger (but I thought The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s. was just random noise).
And would you guess, microsoft/Detours#385 sounds a hella lot similar to this.

[cdozdil]

Hi,

For testing I have compiled that ARM aware Detours and prepared an Opti build with it. Here you can test it:

OptiScaler_20260720_133619.zip

[mirh]

Well, holy shit, it worked?
I mean.. To be fair once in-game I couldn't manage to get either DLSS or Xess inputs to make any difference, but I know UE can be kinda bitchy and this seems like a problem for another thread.

[mirh]

Ok nevermind, it seems like there's still something sketchy here, as OptiScaler (2).log has HookToFactory (and possibly everything else involving detours?) fails with error 9. Which should be ERROR_INVALID_BLOCK.

[cdozdil]

It's a different error this time:

ERROR_INVALID_BLOCK 9 (0x9) The function referenced is too small to be detoured.

Not sure if it's ARM related.

[mirh]

It seems at least system specific because when I try the same dll on my desktop it works just fine (though there the game is also defaulting to d3d11 for some reason). I guess this is at least far more serviceable then.

Can you compile with DETOUR_DEBUG (which should enable the tracing calls) as to be sure I'm hitting that specific DetourAttachEx error?

[cdozdil]

Hi,

This one is with DETOUR_DEBUG enabled

OptiScaler_20260722_110748.zip

[mirh]

Ok this actually crashed with a 0x80000003 exception for some reason...
Did you actually still include the PR? (I saw optiscaler.log stopped in the previous HookToFactory point)

But the first time I launched the thing I had accidentally left the older version named as winmm (and the new one as dxgi), and I could indeed see the "Arm64EC pointer" warning as the last line before stdout stopped. So.. I would guess this is on them? It's not like you are doing much of anything except calling DetourAttach on whatever the address of the dxgi functions is.