世界を動かす技術を、日本語で。

DXGIデバッグ: マイクロソフトが私をリストに載せた

2025年9月21日原文(slugcat.systems)

概要

  • Space Station 14 のARM64版で発生したクラッシュの詳細なデバッグ記録。
  • SDL 初期化直後に空のログでクラッシュ、WinDbgも混乱する現象。
  • DXGIのdetour と「ウィンドウゲーム最適化」機能が原因。
  • 実行ファイル名が「SS14.Loader.exe」の場合のみ発生。
  • Microsoftのゲーム互換リスト による影響と対処法。

Space Station 14がARM64でANGLE利用時にクラッシュする理由

  • Space Station 14 のARM64ビルド作業中、 Windows ARM64 環境でのみゲームクライアントがクラッシュする現象を確認。
  • SDL初期化直後 にログが途切れ、WinDbgでもスタックトレース取得や.NETデバッグが困難な状況。
  • USER32!GetDC 関数呼び出し時に不正命令(illegal instruction)でクラッシュ、WinDbgの「ARM64EC」モードによる混乱も発生。
    • WinDbgはx64ネイティブなSS14.Launcher.exeからデバッグを開始すると、子プロセス(ARM64ネイティブ)で混乱し、スタックトレース表示やC#デバッグが機能しなくなる。
    • SS14.Launcher.exeを直接ARM64で起動し直すことでエラーが解消。
  • SDL3.dll のローカルビルド版でソース追跡し、クラッシュ発生箇所を特定。
  • GetDC() は本来安全なWin32 APIだが、 DXGI!My_GetDC によるdetour(ランタイム書き換え)が行われていることを発見。

DXGIと「ウィンドウゲーム最適化」機能によるdetourの影響

  • DXGI はDirectX 10以降の基盤API、Windows 11では「ウィンドウゲーム最適化」機能でflip model強制切替を実施。
    • これにより、古いゲームやbitblt swapchain利用ゲームで互換性維持のためdetourが挿入される仕様。
  • detourの実装ミスかARM64固有の問題で、 GetDC() 呼び出し時にクラッシュ発生。
  • Windows設定で「ウィンドウゲーム最適化」機能を無効化 するとクラッシュが解消。
  • SS14 はANGLE経由でswapchainを生成しており、flip model未対応。
    • ANGLE側の制約により、独自でswapchain管理が困難。

実行ファイル名によるMicrosoftの互換リスト判定

  • クラッシュは「SS14.Loader.exe」の時のみ発生
    • 開発環境(別名実行)では発生しないため、Microsoftの「互換リスト」判定が原因。
  • Microsoftは特定のゲーム名でのみ「ウィンドウゲーム最適化」を強制適用
    • ARM64対応ゲームが少なく、リストに載ったことで副作用が発生。
  • リスト入りの経緯は不明、だがWindowsに同梱されている互換リストが直接影響。

OpenGL on Windows ARM64とANGLE利用の背景

  • 従来のOpenGL はNvidia/AMD/Intelのドライバ依存、Snapdragon XではMicrosoftの「OpenGL on D3D12」ドライバ(Mesaベース)を利用。
  • Space Station 14 では「OpenGL on D3D12」ドライバに深刻なグラフィックバグがあり、 ANGLE (OpenGL→D3D変換レイヤ)を強制使用。
  • ANGLE利用時のswapchain制御制約 により、最新のDirectX最適化機能との相性問題が発生。

まとめ・対策

  • Space Station 14 のARM64版で発生するクラッシュは、「ウィンドウゲーム最適化」機能+互換リスト判定が主因。
  • 実行ファイル名変更 やWindows側設定変更で暫定回避可能。
  • Microsoftのリスト運用・ARM64対応状況 による副作用への注意が必要。
  • ANGLEやOpenGL on D3D12の制約 も移植時の重要課題。

Hackerたちの意見

タイトルはちょっと釣りっぽいけど、いい記事だね ;) これはOSからGPUドライバーまで、APIレベルのソフトウェアで広まってる話だよ。どれくらい文書化されてるかは分からないけど、exeの名前をQuakeとかFIFAとかMinecraftに変えると面白いことが見つかるかも。

TrickNvidiaDriversForPerformance_javaw.exe.minecraft.exe

昔、Raymond Chenの「The Old New Thing」ブログを読んでた人には驚きじゃない話だよ。Microsoftがこういうトリックで後方互換性や前方互換性を高めるために、かなり absurdなことをやってたからね。この開発者にとっては一つのニッチなケースで不幸な状況になったかもしれないけど、全体的には、基盤となるAPIがどれだけ古くなっても、ほとんどのソフトウェアがそのまま動くのはユーザーにとってすごく助かることだよね(何十年もそうだし)。

2001年、ATIはQuake 3 Arenaを実行しているときに、意図的にすべてのテクスチャをぼかしていたことが明らかになって、ちょっとした騒ぎになったんだ。すべての文字列を「Quake」から「Quack」に変える(実行ファイルの名前も変える)ことで、劣化したミップマップが無効になって、グラフィックスが改善されたんだ(フレームレートも下がったけど)。 https://web.archive.org/web/20190728022442/https://techrepor...

ちょっとクリックベイトっぽいけど、もし会社が俺のソフトウェアの名前をOSに付属する不透明なリストに載せて、俺のソフトが期待通りに動かなくなった上に、何も教えてくれなかったら、こいつよりもずっと怒ると思う。

こういう話を読むと、Windows開発をやったことがない自分はラッキーだなって思う。

心配しないで、OpenGLやVulkanでも同じ体験ができるよ。特定のOSのバージョンやOEMドライバーによるけどね。

こういう通りすがりのコメントは理解できないな。競合のために開発するのが簡単だとか、単純だとかじゃないし。著者は、さまざまなサードパーティライブラリを使った、クロス言語(管理されたものとネイティブの両方)、クロスアーキテクチャのビデオゲームをデバッグしてるんだ。Windowsのグラフィックススタックが複雑なのは、そのためにメンテナンスされてないクローズドソースのプログラムをサポートする必要があるからなんだ。特定のプログラムを最適化するための互換性レイヤーが、著者のプログラムもマスターリストに引っかかっちゃったってわけ。

私もWindowsでこういうことに遭遇したことがあるけど、ほとんどの開発者はこういう問題には直面しないってことを強調したい。これは、コンパイラのバグを見つけるのと同じようなもので、確かに遭遇することもあるけど、一般的には遭遇する問題はコンパイラやOSが原因じゃないことが多いんだ。OSやコンパイラの問題は、10年前よりも今の方が一般的なのかな?可能性はあるけど、逆に少なくなっているかもしれないね。ドライバのバグには何度も遭遇したことがあるけど、OSのバグよりも多いかもしれない。それは本当にイライラする。

各オペレーティングシステムには、そういう余計な層があって、時にはデバッグが難しくなることもあるんだよね。

Windowsでこれらの互換性リストを無効にして、実際に問題やクラッシュを開発者に報告できるようにしたいな。でも、これって自分にとってはすごくLinux的な考え方かも。

Linuxカーネルには、個々のマザーボードやシステム、デバイスのための大きなハックがたくさんあるんだ。残念ながら、どのレベルでもこういうことが起きてる。最近になって、あなたの64コアCPUが初期ブート時に8086のふりをするのをやめたばかりなんだよね。

Hacker Newsで議論の続きを見る