I've seen in the documentation mentioned, that crashes in 32 bit games caused by running out of memory is a limitation DXVK and cannot be fixed. There's a workaround, that could be mentioned in the documentation that might work in some cases (it helped me).
IF i understand correctly 32 bit applications usually cannot access all 4GBs of RAM, since the operation system needed some too. In case of running it on a 64 bit system, the 32bit application can use the whole 4GB of memory it can address, which can be enabled easily on an exe file.
My example would be Far Cry 3, in which case the game crashed with out of memory error, but by enabling accessing the whole 4GB, it plays fine. (No crashes under a play through)
I've found a software for this, and it can be run under wine:
https://www.techpowerup.com/forums/threads/large-address-aware.112556/
I think it would be nice to mention this in the documentation as it is literally a few clicks and may solve out of memory problems.
That's quite literally what we're already telling users to do when they run into the problem. Some wine builds and Proton support this via env vars (WINE_LARGE_ADDRESS_AWARE=1 and PROTON_FORCE_LARGE_ADDRESS_AWARE=1 respectively).
@SzDavidHUN yes, it's old https://bugs.winehq.org/show_bug.cgi?id=33858
and yes, if don't want\can't patching the wine, need patching the exe-file (if drm/anticheat alow it)
I've found a software for this, and it can be run under wine:
https://www.techpowerup.com/forums/threads/large-address-aware.112556/
alternatively can use this script
just manually make backup of original exe-file,
save python-script (for example as laa-flag-set.py) with changed __Game_ to your
make it executable and run once
#!/usr/bin/env python3.8
# See http://en.wikibooks.org/wiki/X86_Disassembly/Windows_Executable_Files#PE_Header
# and https://msdn.microsoft.com/en-us/library/ms680349%28v=vs.85%29.aspx
import struct
IMAGE_FILE_LARGE_ADDRESS_AWARE = 0x0020
PE_HEADER_OFFSET = 60
CHARACTERISTICS_OFFSET = 18
def set_large_address_aware(filename):
f = open(filename, 'rb+')
# Check for MZ Header
if f.read(2) != b'MZ':
print('Not MZ')
return False
# Get PE header location
f.seek(PE_HEADER_OFFSET)
pe_header_loc, = struct.unpack('i', f.read(4))
# Get PE header, check it
f.seek(pe_header_loc)
if f.read(4) != b'PE\0\0':
print('error in PE header')
return False
# Get Characteristics, check if IMAGE_FILE_LARGE_ADDRESS_AWARE bit is set
charac_offset = pe_header_loc + 4 + CHARACTERISTICS_OFFSET
f.seek(charac_offset)
bits, = struct.unpack('h', f.read(2))
if (bits & IMAGE_FILE_LARGE_ADDRESS_AWARE) == IMAGE_FILE_LARGE_ADDRESS_AWARE:
return True
else:
print('large_address_aware is NOT set - will try to set')
f.seek(charac_offset)
bytes = struct.pack('h', (bits | IMAGE_FILE_LARGE_ADDRESS_AWARE))
f.write(bytes)
f.close()
return False
if set_large_address_aware('_Game.exe'):
print('large_address_aware is set')
else:
print('large_address_aware was NOT set')
See https://github.com/doitsujin/dxvk/issues/1318
We are aware of the problem but we haven't fully found what the cause of using more memory is right now, or if we are able to solve it.
Most helpful comment
That's quite literally what we're already telling users to do when they run into the problem. Some wine builds and Proton support this via env vars (
WINE_LARGE_ADDRESS_AWARE=1andPROTON_FORCE_LARGE_ADDRESS_AWARE=1respectively).