Adrian aka Silent aka CookiePLMonster did a deep investigation into how a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2.
One reaction I saw to this was “Why is Windows still tinkering with critical sections? Surely there aren’t any bugs in it after all these years.”
While there may not be bugs in critical sections, there may still be performance issues. And since critical sections are so heavily used, small performance issues can add up to large ones.
We saw some time ago that many synchronization objects were made unfair to avoid lock convoys.
At around the same time, critical sections were optimized to reduce their memory footprint, particularly their cost to non-paged pool. Non-paged pool is an expensive resource since (as the name suggests) it cannot be paged out. On systems doing large-scale computing, even a small cost in non-paged pool is multiplied by a enormous number of critical sections, resulting in outsized non-paged pool pressure that creates performance and reliability problems.
More recently, changes were made to critical sections to try to detect and mitigate priority inversions, and (what is significant in 24H2) those mitigations were optimized further by moving more of the work into user mode and avoiding some cases that previously entailed kernel mode transitions.
The critical section may be an old dog, but it’s still learning new tricks in order to keep pace with a computing environment that is bigger, faster, and more concurrent that it was three decades ago.
> First, what difference does it make…
The difference is that if the software is updated, you will just be able to fix the bug.
Also, you want Microsoft to test legacy software before making changes, I don’t think that’s at all reasonable for a game.
Leaving a single reply to everyone who responded to me since Microsoft can't even license discussion forum software that works like phpBB, or vBulletin, let alone write one that works.
> Just calling “Should I do things the new way?” function will consume additional stack and create the problem it was trying to avoid.
Except the OS would call that when loading the executable before any of its code has run.
> If you say that the contents of uninitialized data is contractual behavior, then not only can no code ever change, you can never upgrade the compiler either. (Because changes to the...
So you want everyone in the world to stop getting updates so that janky old video games could run?
First, what difference does it make whether it is "janky old video games" (Saints Row IV was released in 2013 so not even that old), or some other software that depends on like 3 decades of established behavior of critical sections?
Second, no I don't mind others getting updates as long as I have a choice.
This kind of potentially breaking behavior change should be opt-in. As in, there should be a new manfest entry saying "I am OK with new critical section behavior" which developers add to new executables going forward, not something that retroactively applies to every executable ever compiled...
Just calling “Should I do things the new way?” function will consume additional stack and create the problem it was trying to avoid.
If you say that the contents of uninitialized data is contractual behavior, then not only can no code ever change, you can never upgrade the compiler either. (Because changes to the compiler may change register allocation or inlining decisions.)
This kind of potentially breaking behavior change should be opt-in.
Following your logic, almost every change in Windows would have to be listed in this manifest entry, because even a minor change, such as the API using an additional 8 bytes of stack space, could potentially cause a crash in programs that rely on uninitialized stack garbage have valid values
Or if the the behavior is global and can’t be enabled / disabled per process, then add a settings option “Optimize Windows for : [o] Performance [ ] Compatibility” whose change would result in enabling / disabling of changes like this after...
@Raymond Chen You should tell your colleagues that they either stop jerking around with critical sections or start testing legacy software and games to make sure they still work after those changes.
And I was wondering why Saints Row IV (specifically sriv_legacy branch on Steam) which I never had problems playing on this machine has become unplayable (it keeps hanging at random intervals with Windows popping its [End Program] [Cancel] message) unless I set the process affinity to only 2 out of 12 cores.
Too bad we users don't have a clear way of knowing about and opting out of such changes.
And...
Sorry, the performance improvements and therefore thousands of tons of coal and CO₂ saved from a billion of PCs compound are absolutely worth one old bugged game breaking.
Well the situation has arguably changed quite a lot over the past 30 years. There is so many software now that you can’t plausibly test everything. This bug affects only older versions of classic GTA San Andreas (an edition that is not sold anymore ‒ thanks R*), which is still miraculously relevant only because it’s the only version the multiplayer mod is compatible with.
@Igor Levicki
Your ideas are very unusual, to say the least. Thankfully, you are not in charge of Windows and nobody relevant listens to you otherwise you’d force total freeze of any development of everything. Total stasis.
And your claim about Linux and Proton is very hilarious (and from alternate universe)…
If they can’t test, then they shouldn’t change what works. It’s as simple as that.
But nowadays it’s all the rage to push untested changes into production and wait for complaints. And if not enough people complains? Success. Critical threshold for “won’t fix” to be determined by a dice roll.
If this continues, the best way of playing PC games will be on Linux using Proton — at least that’s not going to break randomly because of an update.
As far as I am concerned Microsoft’s arrogant attitude of “we know best what you need” has long outstayed its welcome.
Wow, I got some reports of this bug from people on my SA-MP server and I would have never believed this was the cause!