[Runtime Bug]: The Sims 3: null-deref in game on scene load (bridge-synthesized device IDs suspected)

[wgalternate]

Describe the bug

The Sims 3 (32-bit, DX9, Shader Model 3.0) crashes deterministically when
loading any 3D scene under the RTX Remix bridge. Main menu and Alt+X dev UI
render correctly. After clicking Play → world (or loading a saved game),
TS3.exe null-derefs inside its own code.

Crash signature (identical across many reproductions, including in
rasterization-passthrough mode with rtx.enableRaytracing = False):

• Exception: ACCESS_VIOLATION reading address 0x00000000
• EIP: 0x00610329 (TS3.exe + 0x00210329)
• eax = 0, ebp = 0 — characteristic of a vtable / function-pointer call
  through a null this

Bridge is healthy at moment of crash — remix-dxvk.log contains zero
err: entries. The last commands TS3.exe issued, per bridge64.log's
post-mortem ring buffer:

IDirect3D9Ex_CheckDeviceFormat × 5
IDirect3D9Ex_GetAdapterMonitor × 1

i.e., the game was performing device-capability queries at the precise moment
of the crash; TS3.exe then died asynchronously in its own CPU-side code, not
while inside a D3D9 call.

The bridge presents synthesised device-identification values to the game.
Comparing Sims 3's own DeviceConfig.log with-vs-without Remix:

Field	Without Remix	With Remix
Driver DLL	nvldumd.dll	nvd3dum.dll
Driver version	32.0.15.9571	32767.65535.65535.65535 (sentinels)
Chipset Board	205710de	00000000
Chipset	00a1	0000

These synthesised values are not exposed by any dxvk.conf / rtx.conf /
user.conf option, including d3d9.customDeviceId / customVendorId /
customDeviceDesc. They appear to be generated at a bridge layer below DXVK.

Environment

• GPU: NVIDIA GeForce RTX 5090, Driver 596.21.0
• OS: Windows 11 (10.0 Build 26220)
• RTX Remix runtime: remix-1.4.2+cfb6edc9
• RTX Remix bridge: remix-main+cfb6edc9
• Game: The Sims 3 (EA App, "Legacy Update", TS3.exe build 1.0.0.18)

---

How do you reproduce the bug

1. Install The Sims 3 (EA App version) with EA's "Legacy Update" applied.
2. Confirm the game launches and loads worlds normally without Remix.
3. Drop the latest RTX Remix release (d3d9.dll, .trex\) into Game\Bin\.
4. Launch the game. Main menu renders; Alt+X dev UI confirms the bridge has
   hooked the process.
5. Click Play → choose any world, or load any saved game.
6. Crash within ~90 seconds with the signature above.

Diagnostic files attached:

• Game\Bin\rtx-remix\logs\bridge32.log, bridge64.log, remix-dxvk.log
• Documents\Electronic Arts\The Sims 3\xcpt *.txt (text) and *.mdmp
  (binary minidump)
• Documents\Electronic Arts\The Sims 3\DeviceConfig.log (with-Remix and
  without-Remix versions show the synthetic-IDs comparison directly)

---

What is the expected behavior

The host process should not silently null-deref before any rendering takes
place. If the game's loader is reading one or more of the synthesised
device-identification fields and failing on them, exposing those fields as
user-overridable — or passing them through unmodified — would give users a
route to a diagnosable failure mode rather than a silent crash.

Version

1.4.2

Log

bridge32.log
bridge64.log
remix-dxvk.log
xcpt 26-04-26 12.49.32.txt
DeviceConfig.log

Crash dumps

None_

[wgalternate]

Update — apitrace baseline + correction on post-mortem ring buffer reading.

Captured an apitrace of a normal (Remix-disabled) world load to get a
reference for the cap-query phase. Two findings:

1. Sims 3's full cap-query phase is just 6 D3D9 calls during init —
   GetAdapterIdentifier (×2), GetAdapterMonitor (×2),
   CheckDeviceMultiSampleType, and CreateDevice. After that, the game
   transitions immediately to render setup. The GetAdapterIdentifier
   payload returned by the real nvldumd.dll driver is:
   Driver = "nvldumd.dll", DriverVersion.QuadPart = 9007199255733653,
   SubSysId = 0x205710DE, Revision = 0xa1 — exactly the four fields the
   bridge substitutes with sentinels/zeros under Remix.

2. Correction to the original report: the
   IDirect3D9Ex_CheckDeviceFormat × 5 entries in the bridge log's
   post-mortem are from the Module Queue ring buffer (cap-query phase,
   recorded earlier in the load). The actual moment-of-crash D3D9 activity
   is in the Device Queue: SetDepthStencilSurface, SetRenderTarget,
   IDirect3DDevice9Ex_CreateTexture × 5 — i.e., the crash happens during
   render-setup texture allocation, not during cap query.

Refined chain: synthetic GetAdapterIdentifier payload at startup →
Sims 3's loader picks a render-path branch based on those values → during
the branch's CreateTexture sequence, the bridge returns something the
loader's branch can't tolerate → null deref at 0x00610329.

So the most targeted fix is still cap pass-through, but specifically for
the four GetAdapterIdentifier fields above (Driver, DriverVersion,
SubSysId, Revision). The other fields in that struct (VendorId,
DeviceId, Description) already pass through correctly — they're
overridable via DXVK's existing d3d9.customDeviceId / customVendorId /
customDeviceDesc options, which I tested per xoxor4d/gta4-rtx's
dxvk.conf workaround; the customDevice* overrides propagate to the
game (DeviceConfig.log reflects them) but do not change the crash —
confirming the trigger is in the four bridge-only fields, not the
DXVK-overridable ones.

[NV-LL]

Hey @wgalternate - thanks for reaching out! We've filed REMIX-5432 for internal investigation.