I've been working on getting ARM64 builds out for Space Station 14, a game that I'm passionate about. Yesterday, I made significant progress on the launcher builds, but my excitement was short-lived as the game client crashed on Windows ARM64.

The crash happened after SDL was initialized, and the client logs were empty. This meant it had to be a native crash, which led me to pull out WinDbg (Windows Debugger) for debugging purposes.

At first, I started Space Station 14 Launcher.exe directly through WinDbg, but this was frustrating because I had to navigate child processes twice and deal with a lot of waiting. However, it eventually worked, and I found the issue was in USER32!GetDC on an illegal instruction.

I barely glanced at the disassembly, assuming there was some UB (undefined behavior) happening, but that didn't make sense to me. So, I decided not to investigate further with C# debugging because WinDbg couldn't pull stack frames from C# code.

Instead, I pulled SDL3.pdb from the server and dropped it next to SDL3.dll to reload symbols. This gave us some function names for SDL3!, so we could double-click on one of the entries in the UI's stack trace view.

"But then, the entire debugger broke," I said. "Every action I try to make causes more of these errors to be printed."

Googling these errors gave me nothing useful. One of them even had no results.

I thought, "Wait, why is the command prompt still saying ARM64EC?" This was confusing because it's for emulation, but my active debugger processes were both native ARM64.

"That's when I realized that starting Space Station 14 Launcher.exe directly was causing WinDbg to get extremely confused,"

I started launching SS14.Launcher.exe directly again, which fixed the issues with showing C# stack traces. It also made sense that there were some compatibility issues with the bitblt model in DXGI.

When I put a hardware breakpoint for whenever something would write to USER32!GetDC, it revealed a lot about what was happening,"

"It turned out that DXGI needed to install detours for the flip model. Microsoft is using this in DXGI because of compatibility issues with the bitblt model,"

I tested this by cloning an old DirectX SDK sample, updating it to ARM64, and adding some GetDC() calls. The crash didn't happen, so I verified the detour installation.

"Microsoft put me on a list that ships with every Windows install,"

Space Station 14 won't have official Windows ARM64 support until these bugs are fixed. Or when I rewrite the renderer to drop OpenGL, which is also an option."

Debugging was a long process but ultimately led us to discover issues with DXGI on ARM64, which we have since verified in a minimal example. The reason for the bug being on that list is still unknown."