Dxgi Debugging: Microsoft Put Me on a List
Key topics
The author describes their experience debugging a DXGI issue on Windows, discovering that Microsoft had added their executable name to a compatibility list, and the discussion revolves around the implications of such practices and the challenges of developing on Windows.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
2h
Peak period
38
6-12h
Avg / period
10.8
Based on 86 loaded comments
Key moments
- 01Story posted
Sep 21, 2025 at 10:45 AM EDT
4 months ago
Step 01 - 02First comment
Sep 21, 2025 at 12:59 PM EDT
2h after posting
Step 02 - 03Peak activity
38 comments in 6-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 24, 2025 at 1:24 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
https://web.archive.org/web/20190728022442/https://techrepor...
He said that's what 99% of the game optimizations are. Putting stuff in place to fix broken API stuff.
Also it's not easy to get them fixed in the game, because of the realities of engine update cycles and things like console certification process. Unless you report the issue several months before release, there is a slim chance you will get a fix in the game.
It may have lead to an unfortunate situation for this developer in this one very niche corner case, but overall it has been wildly beneficial for users over the years (decades even) to have most software Just Work regardless of how deprecated the underlying APIs they were built on are now.
Could you have a SS14.Loader.arm.exe for arm? Then the exe name wouldn't match and it woildn't trigger the crash?
I suspect that the fix to the detour bug will be unevenly distributed as well, so avoiding it would help user experience regardless.
The current situation is derpy, but understandable. The patching system was ported with the rest of the arm stuff, and the executable for arm matches the name list so it makes sense to do the patch, but nobody ported the patch data. Whoops.
In the end, we added the list of loaded Vulkan layers to the diagnostic log of our software to help customer support spot fishy ones.
Turns out that the Windows graphics stack is complicated (mainly because it needs to support a variety of closed-source programs that never saw maintenance after initial release), so compatibility layers meant to optimise for certain programs (an easy optimisation, frankly) accidentally caught the author's program in the master list, too.
EDIT: typo
Are OS or compiler problems more common now than they were 10 years ago? Possibly, but I wouldn't be surprised if they're less common, either.
I have run into driver bugs multiple times though, perhaps more often than OS bugs. And that's really frustrating.
Also happens when some pedantic people decide to turn on -Wall -Wextra -Werror because they think it's safer; now any incorrect warning bug is a fatal compiler bug.
- On Windows, this is Window's fault - On Apple OS, this is the application's fault - On Linux, this is the user's fault
Of course exception do apply, but as far as I know MacOS I have noticed some instance of application patching by the OS itself (although I haven't dug deeper, I can confirm that the application did have a slight change of behavior even before applying vendor patches, and I doubt it was anything done by the anti-malware protection)
Still Does[1]:
>> After a RESET or INIT, the processor is operating in 16-bit real mode. Normally within real mode, the code-segment base-address is formed by shifting the CS-selector value left four bits. The base address is then added to the value in EIP to form the physical address into memory. As a result, the processor can only address the first 1 Mbyte of memory when in real mode.
The UEFI hands off the boot CPU to the OS loader (GRUB/NTLoader etc) in long mode. But when the OS brings up any CPU that is not the initial bootstrap CPU via the interprocessor interrupt... that CPU comes up in 16bit* real mode.
[1]: https://docs.amd.com/v/u/en-US/40332-PUB_4.08 (the intel one says the same thing last I checked, Intel has discussed changing this... but AFAIK has not yet)
* This is a lie... note how the quote references EIP and not IP? That's because it's actually booting up in Unreal mode. Hence the initial instruction run is actually at 0xFFFF_FFF0 IIRC
https://en.wikipedia.org/wiki/Unreal_mode
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.
https://devblogs.microsoft.com/directx/gettingstarted-dx12ag...
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.
https://microsoft.github.io/DirectX-Specs/d3d/D3D12Redistrib...
For my DirectX hobby coding, what is in the box even if a bit oldie is good enough, so I got my info about the Agility SDK wrong.
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.
Note that the detouring problem is only an issue for native ARM64 programs. x64 programs running in emulation on Windows ARM64 work fine.
This isn't something only Microsoft does but also graphics drivers, etc. TBH sometimes i consider using using GUIDs in exe names at build time to avoid such lists :-P.
Cue in a few dozen oldschool game developers thinking, right from the first paragraph, "did he name his game game.exe"?
https://techcommunity.microsoft.com/blog/askperf/two-minute-...
This is still the case today. An operating system breaking apps is not desirable behavior. Not all apps are still in development, the work may have been contacted out, the development studio may have been bankrupted, the source code may have been lost, etc. Either you add a compatibility hack to the OS or you drop support for that app.
It isn't really a binary choice like this in real life. This really depends on the specifics of what the breakage is. The best way is to not break the caller's expectation to begin with.
Anyway, my point is that patching on the vendor side is way more common than it would be in the days before internet updates were common.
Windows 1.0 apps that properly follow all the documented caveats still work, often without anything more than the compatibility hacks to emulate "Windows 3" or similar.
But even back in the 90s, Microsoft found that devs would do things that the documentation explicitly said would break things, and ship it as is.
Things like copy/pasting the code the manual said, in big bold letters, DO NOT DO THIS
Most popular computer games in the 90s did things like "try to allocate all virtual memory and crash if that's possible" and "turn off interrupts globally" despite being written against virtual driver systems that were meant to cooperatively manage interrupts!
>https://ptgmedia.pearsoncmg.com/images/9780321440303/samplec...
"How to ensure your Program does not run on Windows 95"
The most memorable example of a bad behavior that I recall was a 90s video game. It used the area beyond the stack pointer as some kind of bonus storage area. It worked by coincidence because in 9x, every kernel32 call trapped directly into the kernel and would swap your stack. Suddenly NT's Win32 support sometimes involves bigger user space wrappers to ntdll. FindFirstFile was one. NT's kernel32 needed a lot of stack space to call NtQueryDirectoryFile and copy it over to a WIN32_FIND_DATA. The game's data structures got clobbered. So there was a shim that would swap the stack pointer before doing this.
Even still ... There's something in this thread that I think is missing about all this. You don't need to litter your code base with "if (!strcmp(exename, "SIMCITY.EXE"))"... I did see examples here and there of that sort of thing in the Windows code base, but mostly, that is not how this stuff actually works.
Further, I don't think the Win3.1 era is a fair comparison at all. There was no protection between processes then and it was standard practice to bypass the operating system. By Windows 95, this was starting to be less and less the case.
You are right that it's not a binary choice, they are others like maintaining tech debt forever or paying out of pocket to upgrade people's apps. But it's common for those to not be viable options and operating systems need to keep evolving forward.
1. BusyBox is a single executable that executes different commands based on which symlink was used to call it
2. Bash puts itself into compatibility mode if invoked as "sh"
3. "ping" can be invoked as "ping4" or "ping6"
4. Some of git's subcommands are symlinks back to the main executable
5. Clang switches to C++ mode if invoked as "clang++"
6. AppArmor profiles activate on file paths
This is entirely different than when DirectX behaves differently for a program named foo.exe and another one called bar.exe.
AppArmor (and for that matter SELinux) are a different thing yet again. Here the goal is not to fix bugs or incompatibilities, but to add extra security. Similar perhaps, but not nearly as intrusive. Neither involve runtime patching, which is the most salient feature of this crash report.
In your list these are executables that change their own behaviour based on how they are called, whereas in the OP it's the OS changing code based on the name of an application.
This has been one of the primary ways microsoft has managed compatibility for decades.
Windows 95 had hacks based on filenames of games to make sure popular stuff worked on Windows.
Raymond Chen has an entire book! (And a free chapter about exactly this!)
https://ptgmedia.pearsoncmg.com/images/9780321440303/samplec...
They had to do these hacks for things like Wing Commander, Simcity, even Microsoft Office itself needed massive hacks (to the point that a significant portion of the profanity in the Windows 2000 source leaks is explicitly calling the Office team a bunch of idiots and losers who don't know what they are doing)
>For all we know, there was another game with the same filename and this game has been caught in the crossfire
Microsoft has been doing this for 30 years and I am unaware of even one case of "program got wrong compatibility hacks"! It would be unlikely to be reported well so that's not great evidence, but it's been a massive success.
https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/uti...
> Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here’s the amazing part: On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.
https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...
This insane amount of knowlage is rare. And the ability to write about it is also not common.
You are very talented and hard working person.
I am in awe.
Is "this broken API" responsible for a library monkey patching?
Also, we are lucky that linux libraries generally don't use such hacks. That's really bad style of programming. Also legacy games probably would run just fine with a bitblt if they were running fine on older software.
They ranted/vented about OpenGL sucking and DirectX being best thing since butter on toast was invented.
https://news.ycombinator.com/item?id=34138028