This is due to an overall odd strategy by the DirectX graphics team, which is to implement many of the optimization and enhancement features by Detour-ing API calls in the OS. Essentially, the Windows OS is patching itself to implement features.

Unfortunately, this is being done without core OS assistance like the AppCompat system, so it comes with similar problems to unassisted regular user-space patching. In this case, the Detours code used by DXGI is unable to support the current PAC-enabled function prologues in the current version of Windows 11 ARM64. It isn't limited to just the OP's scenario; attempting to enable Auto Super Resolution (AutoSR) on any native ARM64 program using DirectX will also currently crash in a similar manner in EnumDisplaySettings().

The full screen optimization that is mentioned also has some history. It's well intentioned to remove an entire full-screen copy per frame and increase performance/efficiency, but had some problems. When it was originally implemented in Windows 10, it broke full screen mode for some DirectX 9 apps because it made some incorrect assumptions about the window handle supplied by the application for focus tracking. But it was frustrating to deal with, because the mechanism was nearly undocumented and had no opt-out besides a manual user compatibility checkbox. It took me a couple of days of tearing apart the core windowing guts of my program to figure out what Microsoft had done and how to work around it, and it took several months for the Windows team to fix it on their end.

▲

pjmlp 9 hours ago | parent | next [-]

That strategy is described here, and comes from game developers wanting DirectX to be untied from OS versions as it used to be.

https://devblogs.microsoft.com/directx/gettingstarted-dx12ag...

▲

ack_complete 8 hours ago | parent | next [-]

The Agility SDK is unrelated to what is being discussed here. It is a delivery mechanism for the Direct3D 12 runtime instead of DXGI, it is opt-in from the application side, and is done through a more stable loader stage in the core OS instead of hot-patching.

It does, however, give insight into the situation that the DirectX team is in. The in-box version of D3D12Core in the latest version of Windows 11 is SDK version 612. This can be compared against the released Agility SDK versions:

https://devblogs.microsoft.com/directx/gettingstarted-dx12ag...

SDK version 612 is just before the 613 Agility SDK release on 3/11/2024. This means that the version of DirectX 12 they are able to ship in the main OS is a year and a half behind the latest released version.

▲

pjmlp 5 hours ago | parent [-]

I thought that it also included updated DXGI components.

	▲	ack_complete 4 hours ago \| parent [-]
		No, the Agility SDK only includes updated D3D12 core and debug layer components. https://microsoft.github.io/DirectX-Specs/d3d/D3D12Redistrib...

▲

8 hours ago | parent | prev [-]

[deleted]

▲

AnotherGoodName 8 hours ago | parent | prev [-]

>In this case, the Detours code used by DXGI is unable to support the current PAC-enabled function prologues in the current version of Windows 11 ARM64

Surely microsoft could avoid patching this on arm in the first place though right? As in whatever gating they use should make sure it’s not on arm.

	▲	ack_complete 7 hours ago \| parent [-]
		The features in question are platform agnostic. They could temporarily disable the detouring for native ARM64 apps since the mechanism is broken on that architecture, but it's not ideal since the Snapdragon X platform is one of the main platforms for the Auto Super Resolution feature. Upgrading sequential/blit mode swap chains to flip model theoretically should be legacy, but as OP shows, it's not really as new graphics code is still being shipped without flip model support. Note that the detouring problem is only an issue for native ARM64 programs. x64 programs running in emulation on Windows ARM64 work fine.