RETIP Memory Collision with RivaTuner

[DotJberg]

Describe the bug
While launching the game, it would crash. After seeing the Microsoft and Rare opening credits, the game would crash going to the main menu.

To Reproduce
Steps to reproduce the behavior:

1. Have RivaTuner running in the background
2. Launch retip

Expected behavior
Game launches in main menu.

Desktop (You can find this information on task manager):

• OS: Windows 11
• GPU: RTX 3060 TI
• CPU: AMD Ryzen 7 7700X 8 Core

retip-windows-x64.exe.3732.zip

I was able to fix by closing RivaTuner.

AI found the solution by reading the dump.

Chain of evidence, in the order it came together:

  1. Empty log + repeated crashes → game dies before flushing. Need a different artifact than logs.
  2. Found 10 crash dumps in AppData/Local/CrashDumps/ — Windows Error Reporting was capturing full memory dumps. Picked the latest one.
  3. Parsed the minidump header to pull the exception record:
    - Code 0xC0000005 = access violation
    - Parameter[0] = 1 = write attempt (vs. 0 for read)
    - Faulting address: 0x0000000182BEBC90
    - Faulting RIP was inside retip-windows-x64.exe, not a system DLL — so the game's own code did the bad write, not a callback into Windows.
  4. Recognized the fault address shape. 0x182BEBC90 lines up suspiciously with 0x180000000 + 0x2BEBC90. From the strings I'd already pulled (rex::filesystem, XamShowDirtyDiscErrorUI, Xenia-style
  cvars), I knew this was a XenonRecomp-style static recompilation. Those projects map guest Xbox 360 RAM at a fixed host base — typically 0x100000000 for cached RAM and 0x180000000 for the
  physical-mirror region (guest 0x80000000+). So 0x182BEBC90 translates to guest physical 0x82BEBC90, which is a legitimate Xbox 360 RAM offset. Meaning: the recompiled code was doing a perfectly
  correct write to its own guest RAM — and the host pages backing it weren't writable.
  5. Listed all loaded modules and checked which one sat in that range. RTSSHooks64.dll was loaded at base 0x180000000, size 0x267000. RivaTuner had reserved exactly the address range the
  recompiler needed for the guest physical-memory mirror.
  6. The pattern fit a known class of bug. Overlay injectors (RTSS, MSI Afterburner, Discord, ShadowPlay) reserve fixed host VA ranges. Emulators and static recompilers also need fixed VA ranges.
  When they collide, the emulator gets STATUS_ACCESS_VIOLATION on the first write that lands in the contested range. The menu was just the first screen that allocated enough state to push a write
  into that region — earlier screens happened to write only to lower guest addresses that mapped to host memory the recompiler had successfully reserved before RTSS hooked in.

  The "menu crash" / "save file" framing was a red herring — the crash had nothing to do with file I/O. It was the address layout of physical RAM colliding with an unrelated tray app.