Death stranding ошибка failed to load api ms win core libraryloader l1 2 0 dll

I have the same error with an Nvidia GPU (RTX 2070 Super) and its proprietary driver (440.100) on Debian (kernel version 5.4.0)

Same here on Arch Linux with kernel 5.7.7 and an Nvidia GTX 760 with driver 450.57.

I’ve drafted this patch: https://source.winehq.org/patches/data/188960 I don’t have the game to test, so it might not work.

Turns out it was already in wine haha (zebediah figura already added it), I just hadn’t updated my source tree.

I’ve drafted this patch: https://source.winehq.org/patches/data/188960 I don’t have the game to test, so it might not work.

Turns out it was already in wine haha (zebediah figura already added it), I just hadn’t updated my source tree.

does that mean you got it working?

@yurgburg No, I have no idea if it works or not with that patch. Just that it turns out that the patch wasn’t necessary, as it had already been added a few days prior to wine 🙂 That being said, you’ll still need a development build of wine (or a wine with https://source.winehq.org/git/wine.git/commit/37238a74a5fea133b8dbcf55ca62cd0d80dc49f7 patched in) in order for it to work.
Oh alright, do you have any idea how I could add that to my wine?

@yurgburg You’ll need to apply this patch to the wine directory:

Patch

commit 37238a74a5fea133b8dbcf55ca62cd0d80dc49f7
Author: Zebediah Figura <zfigura@codeweavers.com>
Date:   Tue Jul 7 10:05:59 2020 -0500

    api-ms-win-core-systemtopology-l1-1-0: New DLL.
    
    Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
    Signed-off-by: Alexandre Julliard <julliard@winehq.org>

diff --git a/configure b/configure
index 032f4e3d0f..1eafbace7f 100755
--- a/configure
+++ b/configure
@@ -1030,6 +1030,7 @@ enable_api_ms_win_core_synch_l1_2_1
 enable_api_ms_win_core_sysinfo_l1_1_0
 enable_api_ms_win_core_sysinfo_l1_2_0
 enable_api_ms_win_core_sysinfo_l1_2_1
+enable_api_ms_win_core_systemtopology_l1_1_0
 enable_api_ms_win_core_threadpool_l1_1_0
 enable_api_ms_win_core_threadpool_l1_2_0
 enable_api_ms_win_core_threadpool_legacy_l1_1_0
@@ -20362,6 +20363,7 @@ wine_fn_config_makefile dlls/api-ms-win-core-synch-l1-2-1 enable_api_ms_win_core
 wine_fn_config_makefile dlls/api-ms-win-core-sysinfo-l1-1-0 enable_api_ms_win_core_sysinfo_l1_1_0
 wine_fn_config_makefile dlls/api-ms-win-core-sysinfo-l1-2-0 enable_api_ms_win_core_sysinfo_l1_2_0
 wine_fn_config_makefile dlls/api-ms-win-core-sysinfo-l1-2-1 enable_api_ms_win_core_sysinfo_l1_2_1
+wine_fn_config_makefile dlls/api-ms-win-core-systemtopology-l1-1-0 enable_api_ms_win_core_systemtopology_l1_1_0
 wine_fn_config_makefile dlls/api-ms-win-core-threadpool-l1-1-0 enable_api_ms_win_core_threadpool_l1_1_0
 wine_fn_config_makefile dlls/api-ms-win-core-threadpool-l1-2-0 enable_api_ms_win_core_threadpool_l1_2_0
 wine_fn_config_makefile dlls/api-ms-win-core-threadpool-legacy-l1-1-0 enable_api_ms_win_core_threadpool_legacy_l1_1_0
diff --git a/configure.ac b/configure.ac
index d596422320..4829648c3a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2946,6 +2946,7 @@ WINE_CONFIG_MAKEFILE(dlls/api-ms-win-core-synch-l1-2-1)
 WINE_CONFIG_MAKEFILE(dlls/api-ms-win-core-sysinfo-l1-1-0)
 WINE_CONFIG_MAKEFILE(dlls/api-ms-win-core-sysinfo-l1-2-0)
 WINE_CONFIG_MAKEFILE(dlls/api-ms-win-core-sysinfo-l1-2-1)
+WINE_CONFIG_MAKEFILE(dlls/api-ms-win-core-systemtopology-l1-1-0)
 WINE_CONFIG_MAKEFILE(dlls/api-ms-win-core-threadpool-l1-1-0)
 WINE_CONFIG_MAKEFILE(dlls/api-ms-win-core-threadpool-l1-2-0)
 WINE_CONFIG_MAKEFILE(dlls/api-ms-win-core-threadpool-legacy-l1-1-0)
diff --git a/dlls/api-ms-win-core-systemtopology-l1-1-0/Makefile.in b/dlls/api-ms-win-core-systemtopology-l1-1-0/Makefile.in
new file mode 100644
index 0000000000..beed9fb9c2
--- /dev/null
+++ b/dlls/api-ms-win-core-systemtopology-l1-1-0/Makefile.in
@@ -0,0 +1 @@
+MODULE    = api-ms-win-core-systemtopology-l1-1-0.dll
diff --git a/dlls/api-ms-win-core-systemtopology-l1-1-0/api-ms-win-core-systemtopology-l1-1-0.spec b/dlls/api-ms-win-core-systemtopology-l1-1-0/api-ms-win-core-systemtopology-l1-1-0.spec
new file mode 100644
index 0000000000..b5365eb930
--- /dev/null
+++ b/dlls/api-ms-win-core-systemtopology-l1-1-0/api-ms-win-core-systemtopology-l1-1-0.spec
@@ -0,0 +1,2 @@
+@ stdcall GetNumaHighestNodeNumber(ptr) kernelbase.GetNumaHighestNodeNumber
+@ stdcall GetNumaNodeProcessorMaskEx(long ptr) kernelbase.GetNumaNodeProcessorMaskEx
diff --git a/tools/make_specfiles b/tools/make_specfiles
index 420d850b73..f60fbbf6d2 100755
--- a/tools/make_specfiles
+++ b/tools/make_specfiles
@@ -323,6 +323,7 @@ my @dll_groups =
   "api-ms-win-appmodel-runtime-l1-1-2",
   "api-ms-win-core-path-l1-1-0",
   "api-ms-win-core-quirks-l1-1-0",
+  "api-ms-win-core-systemtopology-l1-1-0",
   "api-ms-win-security-grouppolicy-l1-1-0",
  ],
  [

As to how to build it, I’m not sure, I’ve never built proton before (only wine), sorry! I think there are probably some guides available for that though 🙂

@yurgburg You’ll need to apply this patch to the wine directory:
Patch

As to how to build it, I’m not sure, I’ve never built proton before (only wine), sorry! I think there are probably some guides available for that though 🙂

No problem, you’ve given enough info to figure it out. Cheers!

I’ve tested it with the wine patch suggested by @qsniyg. I now get the error message «Death Stranding requires Windows 10 version 1809 or later».

@xythobuz Could you send the proton log? Alternatively, if you don’t mind sending a rather large log (though it compresses very well, so please do compress it haha), run it with WINEDEBUG=+all,-heap, to get a full log, which will probably be more helpful in the not unlikely case the proton log doesn’t contain enough information 🙂

6686.111:00c0:00c4:Call ntdll.RtlGetVersion(0051f880) ret=14162ef78
6686.111:00c0:00c4:Ret  ntdll.RtlGetVersion() retval=00000000 ret=14162ef78
6686.111:00c0:00c4:Call user32.MessageBoxA(00000000,143761de8 "Death Stranding requires Windows 10 version 1809 or later.",143761db8 "Death Stranding",00000010) ret=14162efcf

@xythobuz Could you try setting the windows version in winecfg to windows 10? (or protontricks 1190460 win10 I believe)

As far as I can tell (running winecfg with the run script generated in /tmp with PROTON_DUMP_DEBUG_COMMANDS), the windows version is already set to Windows 10.

As you can see in the image, the default is set to Windows 10 and the one listed applications has «Use global settings». But I also get the same error when setting the application to Windows 10 explicitly, too.

@xythobuz Could you check if the following patch fixes it?

diff --git a/dlls/ntdll/version.c b/dlls/ntdll/version.c
index 4fef2b5e43..1c8fe83ffb 100644
--- a/dlls/ntdll/version.c
+++ b/dlls/ntdll/version.c
@@ -181,7 +181,7 @@ static const RTL_OSVERSIONINFOEXW VersionData[NB_WINDOWS_VERSIONS] =
     },
     /* WIN10 */
     {
-        sizeof(RTL_OSVERSIONINFOEXW), 10, 0, 0x42EE, VER_PLATFORM_WIN32_NT,
+        sizeof(RTL_OSVERSIONINFOEXW), 10, 0, 0x4A61, VER_PLATFORM_WIN32_NT,
         {0}, 0, 0, VER_SUITE_SINGLEUSERTS, VER_NT_WORKSTATION, 0
     },

Edit: And Zebediah is one step ahead of me again haha: https://source.winehq.org/patches/data/188498 and https://source.winehq.org/patches/data/188499 (I don’t think the second patch should be necessary for getting death stranding running, but it shouldn’t hurt to apply either).

I’m guessing he was probably given an early build of the game, considering both these patches and the one before were written a week ago at about the same time.

I tried both your patch and also the two patches you’ve linked. They don’t fix the issue, I still get the same message as above. Here are the logs with the two patches from Zebediah.

• proton-ds.log
• proton-ds-full.log.gz

Hey there!
From your log:

dwBuildNumber=17134

Somehow the value returned still matches the value 0x42EE.
Was the change taken into account ? (I believe that version.c patch didn’t make it yet in the wine source tree)

I was worried about that, but I took extra care to do a full rebuild in the vagrant VM (deleting the build folder) and made sure the change is in the source tree of the wine subdirectory inside the VM.

What am I missing? How can I force a rebuild of wine? I was just expecting that deleting the build folder would be enough.

Edit:

See the screenshot below, the changes are there. Also, I can see the log-output from the ERR(…) call added by @qsniyg, and if this has been compiled in then the other change has been compiled in as well, for sure!

47468.831:003c:0040:err:ver:RtlGetVersion dwMajorVersion=10, dwMinorVersion=0, dwBuildNumber=17134, dwPlatformId=2

@xythobuz Ahhh right, the issue (I believe) is that the registry hasn’t been updated yet. Could you run the winecfg command again, set it to windows 7, click apply, then set it to windows 10, then click apply again? In theory this should update the build number (I should probably note that zebediah’s second patch is likely required for this to work).

Not the one you were asking, but after many failed attempts I simply edited registry file in proton pfx (steamapps/compatdata/1190460/pfx/system.reg)

"CurrentBuild"="19041"
"CurrentBuildNumber"="19041"

Now game takes its time and then crashes with following

Build : dso 100/1892587 17:50 - Fri Jul 10 2020

An Access Violation (C0000005h) has occurred in thread 'Main' at instruction location 000000014174E0D8h

CallStack : 417276342

  0. 0x00007BCDB36E    NtRaiseException
  1. 0x00007BCD458A    raise_func_trampoline
  2. 0x00014174E0D8    ds, 0x4174E0D8
  3. 0x0001417586FD    ds, 0x417586FD
  4. 0x0001423D8570    ds, 0x423D8570
  5. 0x0001423D5F1E    ds, 0x423D5F1E
  6. 0x00014169417A    ds, 0x4169417A
  7. 0x0001416944AA    ds, 0x416944AA
  8. 0x00014169433D    ds, 0x4169433D
  9. 0x0001437196B2    ds, 0x437196B2
 10. 0x00007B456C6B    __wine_start_process
 11. 0x000000000000    
 12. 0x00015C096020    ds, 0x5C096020
 13. 0x7FFFFFDAF000    
 14. 0x000000000000    


RAX = 80004002 RBX = 51e640 RCX = 0 RDX = 51e4c0 RSI = ffffffff RDI = ffffffff
R8 = 51e4b8 R9 = f00 R10 = 0 R11 = 3d6ecea0 R12 = 0 R13 = 0
R14 = 0 R15 = 0 RIP = 4174e0d8 RSP = 51e460 RBP = 51e560 EFL = 10246



  0. 0x0001417BEE4E    ds, 0x417BEE4E
  1. 0x0001417C0E31    ds, 0x417C0E31
  2. 0x0001417C1276    ds, 0x417C1276
  3. 0x00007BC776AB    __wine_spec_unimplemented_stub
  4. 0x00007BCDAF72    RtlVirtualUnwind
  5. 0x00007BCDB36E    NtRaiseException
  6. 0x00007BCD458A    raise_func_trampoline
  7. 0x00014174E0D8    ds, 0x4174E0D8
  8. 0x0001417586FD    ds, 0x417586FD
  9. 0x0001423D8570    ds, 0x423D8570
 10. 0x0001423D5F1E    ds, 0x423D5F1E
 11. 0x00014169417A    ds, 0x4169417A
 12. 0x0001416944AA    ds, 0x416944AA
 13. 0x00014169433D    ds, 0x4169433D
 14. 0x0001437196B2    ds, 0x437196B2
 15. 0x00007B456C6B    __wine_start_process
 16. 0x000000000000    
 17. 0x00015C096020    ds, 0x5C096020
 18. 0x7FFFFFDAF000    
 19. 0x000000000000    

I probably need to attach long log file, but haven’t figured how to create it through steam yet.

(probably need to think about building wine with d3d12? Or it’s too soon to do that?)

@0f3b79350c99d Thank you! To create a log file, prepend: PROTON_LOG=1 to the game’s launch arguments. Since it crashes on __wine_spec_unimplemented_stub, I’m pretty sure a full log (WINEDEBUG=+all,-heap) won’t be required, we only need to know which function needs to be stubbed out and/or implemented 🙂

@0none Huh, the unimplemented_stub thing doesn’t show up in the log (and unfortunately it doesn’t appear like any relevant information as to what caused the crash is displayed, at least from a quick glance):

Crash portion of the log

877.252:00b8:00bc:trace:seh:RtlRestoreContext returning to 7b475c96 stack 51a2b0
877.306:00b8:00bc:trace:loaddll:load_so_dll Loaded L"C:\windows\system32\opengl32.dll" at 0x7a850000: builtin
877.306:00b8:00bc:trace:loaddll:load_so_dll Loaded L"C:\windows\system32\wined3d.dll" at 0x7fb09c200000: builtin
877.306:00b8:00bc:trace:loaddll:load_so_dll Loaded L"C:\windows\system32\dxgi.dll" at 0x7fb09c390000: builtin
877.441:00b8:00bc:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
877.466:00b8:00bc:trace:seh:raise_exception code=c0000005 flags=0 addr=0x14174e0d8 ip=14174e0d8 tid=00bc
877.466:00b8:00bc:trace:seh:raise_exception  info[0]=0000000000000000
877.466:00b8:00bc:trace:seh:raise_exception  info[1]=0000000000000000
877.466:00b8:00bc:trace:seh:raise_exception  rax=0000000080004002 rbx=000000000051e640 rcx=0000000000000000 rdx=000000000051e4c0
877.466:00b8:00bc:trace:seh:raise_exception  rsi=00000000ffffffff rdi=00000000ffffffff rbp=000000000051e560 rsp=000000000051e460
877.466:00b8:00bc:trace:seh:raise_exception   r8=000000000051e4b8  r9=0000000000000780 r10=0000000000000000 r11=0000000000000000
877.466:00b8:00bc:trace:seh:raise_exception  r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000
877.466:00b8:00bc:trace:seh:call_vectored_handlers calling handler at 0x1417c11f0 code=c0000005 flags=0

Can you submit a full log then? (PROTON_LOG=1 WINEDEBUG=+all,-heap) Remember to compress it after, otherwise it might be quite big haha 🙂

@qsniyg
Sorry for the long delay
I could not get it to compress smaller than 20 MiB. Original Log file is about 900 MiB.
I have created a repo for the files now as a work around:
https://github.com/0none/FileDump

11335.933:00b8:00bc:trace:dxgi:dxgi_output_QueryInterface iface 0x9f3fc0, iid {068346e8-aaec-4b84-add7-137f513f77a1}, object 0x51e4b8.
11335.933:00b8:00bc:warn:dxgi:dxgi_output_QueryInterface {068346e8-aaec-4b84-add7-137f513f77a1} not implemented, returning E_NOINTERFACE.
11335.933:00b8:00bc:trace:seh:raise_exception code=c0000005 flags=0 addr=0x14174e0d8 ip=14174e0d8 tid=00bc

Seems like IDXGIOutput6 (DXGI 1.6) needs to be implemented for this to work. From a quick grep in the wine source tree, it seems like it’s not implemented yet. It appears to be implemented in DXVK, but it won’t be of much help for us (other than an implementation reference I guess), since it doesn’t work with vkd3d, which is needed for dx12.

So that means there is nothing left to do but wait for it to be implemented in Wine?
Or, at least for me, since that task is vastly outside of my abilities.

@0none

Here’s a completely untested patch to stub out support for DXGI 1.6: https://gist.github.com/qsniyg/84550f4421c8ee3ff4134ca07d4ad398 (note that I have absolutely zero knowledge about anything relating to directx, I just basically copied what I saw done for DXGI 1.4)

I would be very surprised if it were to actually work, but I guess it’s worth a shot 🙂 If it doesn’t, please attach a log anyways, it might be possible that we’ll be able to progress a bit further.

6867.786:0124:0148:err:fsync:get_shm Failed to map page 59062 (offset 0xe6b6000).
6867.794:0124:0140:trace:seh:handle_syscall_fault code=c0000005 flags=0 addr=0x7f9ab8689050 ip=7f9ab8689050 tid=0140
6867.794:0124:0150:trace:seh:handle_syscall_fault code=c0000005 flags=0 addr=0x7f9ab8689d0a ip=7f9ab8689d0a tid=0150
6867.794:0124:0140:trace:seh:handle_syscall_fault  info[0]=0000000000000000
6867.794:0124:0150:trace:seh:handle_syscall_fault  info[0]=0000000000000000
6867.794:0124:0140:trace:seh:handle_syscall_fault  info[1]=0000000000000297
6867.794:0124:0150:trace:seh:handle_syscall_fault  info[1]=0000000000000297
6867.794:0124:0140:trace:seh:handle_syscall_fault  rax=00007f99344ad4a0 rbx=0000000000000001 rcx=0000000000000000 rdx=00007f9ab8689040
6867.794:0124:0150:trace:seh:handle_syscall_fault  rax=00007f99344ad4a0 rbx=0000000000000001 rcx=000000000000000f rdx=0000000000000001
6867.794:0124:0140:trace:seh:handle_syscall_fault  rsi=0000000000000297 rdi=0000000000000000 rbp=0000000000000000 rsp=0000000003ebb950
6867.794:0124:0150:trace:seh:handle_syscall_fault  rsi=0000000000000297 rdi=000000000003ed2c rbp=0000000000000000 rsp=000000000671f690
6867.794:0124:0140:trace:seh:handle_syscall_fault   r8=0000000000000001  r9=0000000003ebbba0 r10=0000000000000000 r11=000000013fe60000
6867.794:0124:0150:trace:seh:handle_syscall_fault   r8=0000000000000000  r9=000000007fffffff r10=00007f9ab86ef770 r11=000000000000009c
6867.794:0124:0140:trace:seh:handle_syscall_fault  r12=0000000000000000 r13=0000000003ebb9a0 r14=0000000000000001 r15=00007f9ab86d2300
6867.794:0124:0150:trace:seh:handle_syscall_fault  r12=0000000000000000 r13=0000000000000000 r14=0000000000000001 r15=0000000000000000
6867.794:0124:0140:trace:seh:handle_syscall_fault returning to user mode ip=000000007bc0d314 ret=c0000005
6867.794:0124:0150:trace:seh:handle_syscall_fault returning to user mode ip=000000007bc0cc34 ret=c0000005
6867.795:0124:0140:trace:seh:handle_syscall_fault code=c0000005 flags=0 addr=0x7f9ab8689050 ip=7f9ab8689050 tid=0140
6867.795:0124:0150:trace:seh:handle_syscall_fault code=c0000005 flags=0 addr=0x7f9ab8689d0a ip=7f9ab8689d0a tid=0150
6867.795:0124:0140:trace:seh:handle_syscall_fault  info[0]=0000000000000000
6867.795:0124:0150:trace:seh:handle_syscall_fault  info[0]=0000000000000000
6867.795:0124:0140:trace:seh:handle_syscall_fault  info[1]=0000000000000567
6867.795:0124:0150:trace:seh:handle_syscall_fault  info[1]=0000000000000567
6867.795:0124:0140:trace:seh:handle_syscall_fault  rax=00007f9957c09530 rbx=0000000000000001 rcx=0000000000000000 rdx=00007f9ab8689040
6867.795:0124:0150:trace:seh:handle_syscall_fault  rax=00007f9957c09530 rbx=0000000000000001 rcx=0000000000000008 rdx=0000000000000001
6867.795:0124:0140:trace:seh:handle_syscall_fault  rsi=0000000000000567 rdi=0000000000000000 rbp=0000000000000000 rsp=0000000003ebb950
6867.795:0124:0150:trace:seh:handle_syscall_fault  rsi=0000000000000567 rdi=0000000000021150 rbp=0000000000000000 rsp=000000000671f690
6867.795:0124:0140:trace:seh:handle_syscall_fault   r8=0000000000000001  r9=0000000003ebbba0 r10=0000000000000000 r11=000000013fe60000
6867.795:0124:0150:trace:seh:handle_syscall_fault   r8=0000000000000000  r9=000000007fffffff r10=00007f9ab86ef770 r11=000000000000009c
6867.795:0124:0140:trace:seh:handle_syscall_fault  r12=0000000000000000 r13=0000000003ebb9a0 r14=0000000000000001 r15=00007f9ab86d2300
6867.795:0124:0150:trace:seh:handle_syscall_fault  r12=0000000000000000 r13=0000000000000000 r14=0000000000000001 r15=0000000000000000
6867.795:0124:0140:trace:seh:handle_syscall_fault returning to user mode ip=000000007bc0d314 ret=c0000005
6867.795:0124:0150:trace:seh:handle_syscall_fault returning to user mode ip=000000007bc0cc34 ret=c0000005

System Information:
Kernel Version: 5.16.1-arch1-1
GPU: NVIDIA Corporation NVIDIA GeForce RTX 3080
Driver/LLVM version: 4.6.0 NVIDIA 495.46
Proton version: experimental-6.3-20220119
#4568

Update: Game does not crash during longer sessions with PROTON_NO_FSYNC=1

I got a crash using the latest proton experimental when loading my existing save (An Access Violation (C0000005h) has occurred in thread 'Background 3' at instruction location 00000001416B3085h at 21% load progress). Starting a new game is fine though, loading a save data from that new session is also working. Reverting to proton 6.3-8 fixed the issue.

Hello @arifwn, please add PROTON_LOG=1 %command% to the game’s launch options, reproduce the regression, and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.) Also, please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.

It would be interesting to know how Proton 7.0-1 fares too.

I can’t start the game, because my pc runs out of memory during the loading screen after selecting «new game». The memory usage sits at 8Gb when I reach the title menu.
systeminfo & logs

I just want to report that the latest proton experimental works again on my old save.

Edit: the crash still occurs after playing for a little while, just not when loading save.

I get a consistent crash while loading after completing most of the cinematics following the gameplay from the first parcel delivery. This occurs on Proton 7.0-1, not long after a new game is started. I also cannot load into previous saves from a finished story on 7.0-1, but can load in just fine on 6.3-8.

UPDATE: After further testing, it seems switching between 6.3-8 and then back to 7.0-1 was enough to allow me to load back into prior saves and past the loading bug. Very odd! At least it works for now.

error.txt (From the game’s root folder)

System Information (From Steam)

steam-1190460.zip (Proton log from $HOME)

Using Proton 6.3-8 and following #4069 (comment) and #4069 (comment) did help.

I think the issue was only FSYNC, but I’m leaving the VKD3D_CONFIG option anyway, as the game is now stable.

Here’s the command I’m using on the game’s «Properties -> General» Launch Options:

PROTON_NO_FSYNC=1 VKD3D_CONFIG=no_upload_hvv %command%

I think the issue was only FSYNC

After a lot of trial & error, I’m not quite sure. I’ve been playing with Proton Experimental and PROTON_NO_FSYNC=1, which went fine for a good while, but out of the blue I got the infamous ‘Access Violation (C0000005h)’ again… I immediately restarted the game, only for it to get stuck at 21% loading and displaying the same error. I then switched Proton Experimental to Proton 6.3-8, tried again, and that worked! Played a while, no problems yet.

It’s still quite vague to me where the issue exactly lies. It does seem PROTON_NO_FSYNC=1 helps, as does the VKD3D_CONFIG=no_upload_hvv, and combined with Proton 6.3-8 it makes it the least likely to crash. But I’m not convinced it won’t ever crash again, it just seems to reduce the chance of it crashing. For that matter, I also had good experiences with rebooting my PC and only starting the game (nothing else).

cant start game ( its work before ), its crashing while loading game (on 30% — 40%)

strange is — its not use GPU memory when loading … like it run with integrated GPU

UPD: not work even when i donwgrade from 510 to 470 nvidia driver

@savegame Can you post a proton log and a steam systems report (let it run for atleast 10 seconds before copying)
Also the error.txt mentioned in your screenshot might be interesting.

Also check out the comment above

Replying to #4069 (comment)

On Fedora, two things that gave me headaches, crashing games and steam were NVIDIA 470.x drivers series and PipeWire (5-7 crashes per gameplay). Death Stranding was extremely affected by both. DS has some memory handling, problems it seems, but after 495.x I had, if related, a fraction of the crashes (once per day and sometimes). Pipewire would, now is much, much less frequent, crash even just keeping Steam or a Browser opened (chromium based were more frequent).

it seems related to proton 7.0. All my problems are gone in GE 6.21-2

@Blisto91 , i was install Proton GE 6.21-2, and its help, now game work (did not try DLSS yet)

Replying to #4069 (comment)

I had the same problem, I fixed it by downgrading to Proton 6.3-8. Proton 7.0 does not like this game xD.

I can’t start the game, because my pc runs out of memory during the loading screen after selecting «new game». The memory usage sits at 8Gb when I reach the title menu. systeminfo & logs

Do you have amdvlk installed? I removed it and keep mesa installed. Now this memory eating behavior is gone and I can play.

They seem to be using amdvlk according to the log yes.

My game is crashing before the logos appear and the game reaches the title screen if any PS5 controller is connected on Proton Experimental. Downgrading to Proton 6.3-8 resolves this crashing issue, however, the controller is now not working.

EDIT: It seems both the issue is gone and the controller works on Proton 7.0-1, so definitely something off in Experimental.

@TheNH813 The experimental update today included some HID controller changes — could you confirm if you are still seeing this with experimental-7.0-20220331?

Tested on Experimental [bleeding-edge], experiencing the same issue at launch.

That said, I also have periodic crashing and crashes during save loads with 7.0-1.

I got this access violation errors randomly. And it’s hard to save because of all cutscenes. I’m also using Proton 7.0. I changed to Proton 6.3-8 and crashed before the game begins. I’m using Proton Experimental and is working quite right so far. But there is a key difference: I’m playing the Director’s Cut version.

Attempting to run Death Stranding while Xbox One controller is connected causes a crash

Issue transferred from #5862.
@Ointm3nt posted on 2022-05-26T00:19:57:

Death Stranding opens and runs perfectly well, but if my Xbox One controller is connected to the computer via bluetooth at any point during or after the game being launched/open, the game crashes with the below error message.
error.txt

I’m on Arch Linux with the latest version of Steam, running Proton Experimental. My system is fully up-to date, and I’m running an AMD 6800 XT with vulkan-radeon drivers, along with an Intel 12700 CPU.

Are you experiencing any issues with RADV and this game nowadays?

I’m getting two, maybe three issues with Death Stranging on :
Manjaro Gnome Latest,
AMD Ryzen™ 7 3700X
AMD Radeon™ RX 5700 XT
32Go RAM

Am using Proton 6.3.8, with gamemoderun.
The game crashes after a while (mileage varies), leaving 7 corrupted files that don’t repair themselves after File Integraty Validation.

I’m currently waiting to see if I get an other Corrupted Files update.
I’ll run with logs and post them here after said crash.