Last October, Microsoft blessed us with Windows 11 24H2, bringing various improvements like updates to Copilot, better file management with TAR and 7z archive support, a new Energy Saver mode, and enhanced compatibility for newer PCs.
Soon after the update started rolling out, some players of the beloved classic Grand Theft Auto: San Andreas began reporting a bizarre problem: the Skimmer seaplane (shown below) was completely missing from the game world and could not be found anywhere.
These reports started circulating among the game’s community and eventually landed on the radar of Silent, the developer known for SilentPatch. If you don’t know what SilentPatch is, it is a passion project with unofficial fixes to squash bugs and improve how older PC games, especially the Grand Theft Auto titles, run on modern computer systems.
Silent (AKA CookiePLMonster) initially figured it might be an issue caused by other mods or perhaps a specific setup, as is common with older games and many user configurations. However, the reports kept coming, and some players insisted the bug happened even on a game installation with no other modifications after they updated to Windows 11 24H2. One user posting on GTAForums captured the general confusion:
EDIT: So I think I confirmed it, I set up a VM with Windows 11 23h2 and the damn plane spawns fine, and updating that same VM to 24h2 breaks the skimmer, why would a small feature update in 2024 break a random plane in a 2005 game is anyone’s guess.
Convinced the issue was real, Silent decided to investigate directly. He set up a test environment with Windows 11 24H2 and a clean installation of GTA San Andreas. Sure enough, loading the game confirmed the Skimmer was gone from its usual spot on the water.
Things got even weirder when he tried to force the game to create the plane using an in-game command. Instead of appearing normally, the game glitched and launched the player character an astronomical distance into the sky.
Without SilentPatch installed, this sends the game camera into a visual mess; with SilentPatch installed, the game simply freezes.
That chaotic behavior of being launched sky-high strongly hinted at numerical errors, likely involving floating-point values, within the game’s logic. When the game froze with SilentPatch installed, Silent could see exactly where it happened in the code: inside a function called CPlane::PreRender, stuck in a loop trying to adjust the plane’s rotor blade angle.
The value it was using for the blade speed (m_fBladeSpeed) was enormous, around 3.73e+29. This kind of impossibly large number meant tiny adjustments were ineffective, leading to the freeze. This huge speed value was ultimately derived from the plane’s altitude, confirming the launch into the sky was the initial symptom of something being fundamentally wrong with the plane’s properties.
Silent traced the source of this problem back to the code that handles setting up a vehicle’s physics the first time it loads. This process calculates things like the vehicle’s “bounding box” – an invisible box defining its physical boundaries. A critical part of this setup involves adjusting the bounding box’s vertical limit (its Z value) based on the vehicle’s suspension. He discovered that for the Skimmer, this calculation was using incorrect numbers, resulting in a corrupted Z value for the bounding box, specifically something like -4.30747210e+33. This impossible value was what caused the game to think the plane was at an extreme height, triggering the sky-launch and the subsequent numerical errors.
The deeper Silent went, the more he realized the core issue was tied to how the Skimmer is defined in one of the game’s configuration files, vehicles.ide. The Skimmer’s entry in this file was shorter than other planes, missing a couple of key numbers needed for its setup – specifically, the size of its wheels.
This was likely a leftover from Grand Theft Auto: Vice City, where the Skimmer was classified as a boat and did not need these ‘wheel’ parameters. When Rockstar changed it to a plane in San Andreas, they forgot to update its line in vehicles.ide to include these now-required values.
The game’s function for loading vehicle data, CFileLoader::LoadVehicleObject, uses sscanf to read the parameters from the vehicles.ide line into local variables. The critical flaw here is that the game’s code did not initialize the local variables intended for the wheel size parameters to a default value (like 0.0), nor did it check if sscanf successfully read values for them.
This meant that when the game read the Skimmer’s line, which was missing those parameters, the local variables on the program’s stack intended for the wheel sizes simply held whatever data was already present in those memory locations from previous function calls. This is a big no-no in programming because it relies on pure chance – the contents of uninitialized variables are unpredictable.
Now, here is where Windows 11 24H2 enters the picture and exposes this hidden flaw. For nearly twenty years, on many versions of Windows, including Windows 10, a strange bit of luck kept this bug from appearing on PC. The vehicles.ide file is read sequentially. The entry for the ‘Topfun’ van comes right before the Skimmer’s entry. The Top Fun van does have wheel size values defined, and they are both 0.7.
By pure coincidence, on older Windows versions, the memory on the stack used to store Topfun’s wheel sizes after its entry was processed was not overwritten by other operations before the game’s code started reading the Skimmer’s entry. So, when the game looked at the uninitialized stack locations for the Skimmer’s wheel sizes, it accidentally picked up the stale 0.7 values left behind by Topfun. The calculations would then proceed using 0.7, resulting in a mostly functional, if technically incorrect, setup for the Skimmer.
However, Windows 11 24H2 brought some internal changes. One small change was in how a low-level Windows function (LeaveCriticalSection), part of the C runtime library and involved in tidying up after reading files line by line, used temporary memory on the stack. This function started using slightly more stack space. This minor shift was just enough that when the game finished processing the Topfun line and moved to the Skimmer line, that specific stack location where the 0.7 values used to linger was now overwritten by this internal Windows function call before the Skimmer’s variables were accessed.
So, on Windows 11 24H2, when the game went to read the Skimmer line and loaded its uninitialized local variables from the stack, that memory spot no longer held the lucky 0.7 from Topfun. It held arbitrary data left by the updated Windows function. This unpredictable data was then used in the calculation for the Skimmer’s physical setup, resulting in a wildly incorrect value for its bounding box Z coordinate, causing the plane to essentially disappear or launch the player into space.
Silent makes it clear that this is not a bug in Windows 11 24H2. The way internal operating system functions use stack memory is not something programs are supposed to rely on; those details can change anytime Microsoft updates things.
The real bug has always been in Grand Theft Auto: San Andreas, which was incorrectly depending on a lucky memory layout that persisted for years. Silent will include a proper code fix for this in the next SilentPatch update.
For players who want to fix this issue themselves right now, before the next SilentPatch update, it is possible to manually edit the game’s vehicles.ide file. Simply open data\vehicles.ide in your San Andreas directory with Notepad, find the line starting with “460, skimmer”, and replace it with:
460, skimmer, skimmer, plane, SEAPLANE, SKIMMER, null, ignore, 5, 0, 0, -1, 0.7, 0.7, -1
Save the file, and the Skimmer should reappear.
