On Fri Mar 20 15:07:28 2026 +0000, Joerg Rueppel wrote:
The game writes into the heap header at returned_ptr - 4 after calling GetData() on the mesh (increases it by 1) and reduces it by 1 after its done with the rest of the file. So during the load the heap header is corrupted. warn+heap doesn't flag it though and through random chance this doesn't seem to have any adverse effect with the way things are implemented right now in wine. We could allocate more and return an offsetted pointer to protect against this, or add padding in the internal buffer between elements and not do individual allocs for each element. Interesting! I wonder if the game is abusing d3dxof implementation details, like maybe it's expecting the `IDirectXFileData` object refcount in that place and it's being "efficient" / "smart" by manually incrementing and decrementing it instead of calling `AddRef()` and `Release()`.
It should be possible to test that in a clean way by replicating what the game is doing in the d3dxof tests and e.g. use the existing `get_refcount()` helper to check if that affects the refcount of some d3dxof object. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10278#note_133079