博士

ロボ子、大変なのじゃ！Space Station 14のARM64版で、ゲームクライアントがWindows ARM64でクラッシュする問題が発生したらしいぞ！

ロボ子

それは大変ですね、博士。具体的にはどのような状況でクラッシュが発生するのでしょうか？

博士

ふむ、どうやらSDLの初期化直後にクラッシュするみたいで、クライアントログは空っぽらしいのじゃ。まるで、何もない空間で突然爆発するみたいだぞ！

ロボ子

原因の特定は難しそうですね。クラッシュの根本原因は何だったのでしょう？

博士

WinDbgを使ってネイティブクラッシュを調査したところ、`USER32!GetDC`で不正な命令が実行されていることが判明したのじゃ！

ロボ子

`USER32!GetDC`ですか。それがどのように関係しているのでしょう？

博士

SDLがウィンドウを表示する際に、GDIコマンドで背景をクリアしているらしいのじゃ。その過程で`USER32!GetDC`が呼ばれるんだけど、命令が欠落していたらしいぞ。

ロボ子

命令が欠落…ですか？それは一体なぜ？

博士

`DXGI!My_GetDC`というMicrosoftによるデツアー（ハック）が原因らしいのじゃ！Windows 11の「Optimizations for windowed games」機能が影響しているみたいだぞ。

ロボ子

「Optimizations for windowed games」ですか。それがどのように影響するのでしょう？

博士

Windows 11では、古いゲームのために強制的にフリップモデルを有効にする機能があるのじゃ。でも、Space Station 14はANGLEが`SWAP_EFFECT_SEQUENTIAL`を使用しているから、フリップモデルを使えないらしい。

ロボ子

なるほど。それで、なぜ特定のプログラム名でのみクラッシュが発生するのでしょう？

博士

なんと、プログラム名が`SS14.Loader.exe`の場合にのみ発生するのじゃ！Microsoftが特定のゲームに対して「Optimizations for windowed games」を有効にしていて、そのリストに`SS14.Loader.exe`が含まれていたらしいぞ！

ロボ子

それは驚きですね。Microsoftが特定の実行ファイルに対して最適化を適用しているとは。

博士

さらに、OpenGL on D3D12ドライバーがSpace Station 14でグラフィックの不具合を引き起こしているから、QualcommデバイスでANGLEを強制的に使用しているらしいのじゃ。OpenGL on D3D12ドライバーはQualcommのドライバーには付属していないから、ややこしいのじゃ！

ロボ子

色々な要因が重なっているんですね。結局、Windows ARM64の公式サポートはどうなるのでしょうか？

博士

残念ながら、OpenGL on D3D12またはARM64 DXGIデツアーのバグが修正されるまで延期されるみたいじゃ。それまでは、お預けなのじゃ！

ロボ子

そうですか。解決には時間がかかりそうですね。

博士

まあ、気長に待つしかないのじゃ。しかし、まさかMicrosoftの最適化機能がこんな落とし穴を作るとは思わなかったぞ。まるで、親切な人が落とし穴を掘ってくれたみたいなものじゃな！

ロボ子

博士、それは少し違いますよ。でも、今回の問題は、OSの最適化が特定の条件下で予期せぬ副作用を引き起こす良い例ですね。

博士

そうじゃな。しかし、今回の件で、私は一つ賢くなったぞ！今度から、ゲームをデバッグするときは、まず最初にMicrosoftのせいにするのじゃ！

ロボ子

博士、それは少し乱暴な結論だと思います…！