ER 1.10.1 Failures

[whoisj]

Elden Ring crashes immediately when loading mods which depend on eldenring_alt_saves.dll.

Without any kind of symbols, it's very difficult for me to understand exactly what is happening, but it seems like one or both of the offsets used to interact with eldenring.exe is no longer valid.

const REGBIN_CHECK_FLAG_IBO: usize = 0x3acea92;
const REGULATIONMANAGER_CONSTRUCTOR_IBO: usize = 0xdc95e0;

My assumption is based on the fact that the crash is caused by invalid memory access, likely caused by memory corruption (this library is accidentally overwriting some value in eldenring.exe's memory causing it to attempt dereference memory it does not own thus getting killed by the operating system.

A mostly incompetent inspection of the resulting minidump provides the following:

Unhandled exception at 0x00007FF68B8395E1 (eldenring.exe) in eldenring.exe.37736.dmp: 0xC0000005: Access violation reading location 0x000000000000007B.

I have a few dump files I can look at, but (again) without symbols I'm not great a dissecting minidumps. One easy bit of information is that I can see the following libraries have been loaded:

• modengine2.dll
• dinput8.dll
• eldenring_alt_saves.dll
• elden_ring_seemless_coop.dll
• lua.dll
• ErdTools.dll

If you have any instructions on how to better debug this issue, I'd be happy to assist.

Call stack (same for multiple crashdumps) is provided below:

> eldenring.exe!00007ff68b8395e1()  
  eldenring.exe!00007ff68b83a872()  
  eldenring.exe!00007ff68b83a136()  
  eldenring.exe!00007ff68b839dce()  
  eldenring.exe!00007ff68ac7a3ae()  
  eldenring.exe!00007ff68d08423d()  
  eldenring.exe!00007ff68d07cd1c()  
  eldenring.exe!00007ff68d07d21e()  
  eldenring.exe!00007ff68ac67d0f()  
  eldenring.exe!00007ff68ac68b28()  
  eldenring.exe!00007ff68ac67847()  
  eldenring.exe!00007ff68d100165()  
  eldenring.exe!00007ff68d100460()  
  eldenring.exe!00007ff68d0b74f2()  
  eldenring.exe!00007ff68d07ffae()  
  eldenring.exe!00007ff68b8e26b4()  
  eldenring.exe!00007ff68b81fc04()  
  eldenring.exe!00007ff68b6d03a4()  
  eldenring.exe!00007ff68b6d06de()  
  eldenring.exe!00007ff68cf252bb()  
  modengine2.dll!00007ffc0086f4df() 
  kernel32.dll!BaseThreadInitThunk()    
  ntdll.dll!RtlUserThreadStart()    

The call stack is the same (offsets varying of course) with The Convergence or without, so long as modengine2 is used w/ eldenring_alt_saves.dll.

[vswarte]

My assumption is based on the fact that the crash is caused by invalid memory access

it seems like one or both of the offsets used to interact with eldenring.exe is no longer valid.

Yup, spot on.

These have been updated for ER 1.10.1 in release v1.3.1 (which I just published).

In the long run I need to implement a strategy based on locating the code I'm patching during game boot at runtime. That should make the mod much less prone to breakage across updates.

On that note I am closing this issue since the new version should work for ER 1.10.1 and if it doesn't that's another issue altogether :-)

[whoisj]

Great work, very quick turn around. Rather impressive.

Curious, how do you determine the correct offsets @vswarte?

[vswarte]

Thanks @whoisj!

I use ghidra extensively as a disassembler to analyze and document the games binary. The offsets/IBOs usually point to some machinecode or static variable that I want to change. The IBOs themselves are basically just offsets from the first byte of the executable since the executable will be loaded into a random location in memory as far as pointers go per ASLR.

Simply put: Finding the IBOs initially is a matter of reading an assload of machinecode/assembly and note-taking.

Once documented however... Ghidra offers a set of tooling to migrate documentation from one version of the binary to another by comparing the instructions in both versions (hence me being able to update it a day after an update drops).