Proton 🚀 - DEATH STRANDING (1190460)

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)

jul-ben on 14 Jul 2020

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

xythobuz on 14 Jul 2020

~~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.

qsniyg on 14 Jul 2020

~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?

lorddickfist on 14 Jul 2020

@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.

qsniyg on 14 Jul 2020

@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?

lorddickfist on 14 Jul 2020

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

Patch

commit 37238a74a5fea133b8dbcf55ca62cd0d80dc49f7
Author: Zebediah Figura <[email protected]>
Date:   Tue Jul 7 10:05:59 2020 -0500

    api-ms-win-core-systemtopology-l1-1-0: New DLL.

    Signed-off-by: Zebediah Figura <[email protected]>
    Signed-off-by: Alexandre Julliard <[email protected]>

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 :)

qsniyg on 14 Jul 2020

@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!

lorddickfist on 14 Jul 2020

👍1

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 on 14 Jul 2020

👍2

@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 :)

qsniyg on 14 Jul 2020

Sure, there you go.

xythobuz on 14 Jul 2020

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)

qsniyg on 15 Jul 2020

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 on 15 Jul 2020

@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.

qsniyg on 15 Jul 2020

👍1

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.

xythobuz on 15 Jul 2020

@xythobuz Huh weird... could you try the following patch? It won't fix it, but it'll at least print what it's sending to the game so we can get a sense of what's not working.

diff --git a/dlls/ntdll/version.c b/dlls/ntdll/version.c
index 1c8fe83ffb..6984cfb74f 100644
--- a/dlls/ntdll/version.c
+++ b/dlls/ntdll/version.c
@@ -585,6 +585,11 @@ NTSTATUS WINAPI RtlGetVersion( RTL_OSVERSIONINFOEXW *info )
     info->dwMinorVersion = current_version->dwMinorVersion;
     info->dwBuildNumber  = current_version->dwBuildNumber;
     info->dwPlatformId   = current_version->dwPlatformId;
+    ERR("dwMajorVersion=%i, dwMinorVersion=%i, dwBuildNumber=%i, dwPlatformId=%i\n",
+        info->dwMajorVersion,
+        info->dwMinorVersion,
+        info->dwBuildNumber,
+        info->dwPlatformId);
     wcscpy( info->szCSDVersion, current_version->szCSDVersion );
     if(info->dwOSVersionInfoSize == sizeof(RTL_OSVERSIONINFOEXW))
     {

qsniyg on 15 Jul 2020

Ok, here you go:

xythobuz on 15 Jul 2020

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)

a0kami on 15 Jul 2020

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

Screenshot_20200715_155542

xythobuz on 15 Jul 2020

@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).

qsniyg on 15 Jul 2020

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 on 15 Jul 2020

@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 :)

qsniyg on 15 Jul 2020

@qsniyg Not the other guy but I did the same thing, got the same error and here is the proton log:
steam-1190460.log

0none on 15 Jul 2020

@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 on 15 Jul 2020

@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

0none on 16 Jul 2020

I also get the same error message. Here are my logs:

xythobuz on 16 Jul 2020

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.

qsniyg on 16 Jul 2020

👍1

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 on 16 Jul 2020

@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.

qsniyg on 16 Jul 2020

Hello. The next branch of the Proton app in the Steam client is now available. Death Stranding is playable on this branch. Please see issue #4070 for more details.

aeikum on 16 Jul 2020

🎉9

Yo?! Is this true

On Wed, Jul 15, 2020, 16:04 Andrew Eikum notifications@github.com wrote:

Hello. The next branch of the Proton app in the Steam client is now
available. Death Stranding is playable on this branch. Please see issue

4070 https://github.com/ValveSoftware/Proton/issues/4070 for more

details.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/4069#issuecomment-659058750,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFLFPNSEVPS4RITFPZYF3JLR3YYW3ANCNFSM4OZUFSMQ
.

lorddickfist on 16 Jul 2020

@aeikum
The branch is not showing up for me, even after restarting steam. Do I need to refresh the list manually?
@qsniyg
The patch is giving me errors at dlls/dxgi/dxgi_private.h:144 and dlls/dxgi/output.c:569. On what wine branch are you?

0none on 16 Jul 2020

@0none Ah sorry, it's written against https://github.com/wine-mirror/wine/commit/54b2a10659871032720df31ae9ca6cba2ff4acf0. If you want to compile from scratch, I'd say just compile https://github.com/ValveSoftware/Proton/tree/proton_5.0-next instead :) (the next branch aeikum mentioned above)

qsniyg on 16 Jul 2020

I am compiling that right now and will be reporting shortly :wink:
Funny that, I was just pulling proton when the new branch popped up. "Huh, what's that all about?"

Edit: Compiling fails and it's late, I take the "shortly" back

0none on 16 Jul 2020

It does work with the proton 5.0 -Next branch. Playing it right now 144fps

lorddickfist on 16 Jul 2020

It does build (if it fails -- did you update submodules after switching branches/recreate vagrant? git submodule update --init --recursive)

However it does crash with this message: Error initializing rendering configuration, check video card and drivers\n\nThe details of the error are output in error.txt..

error.txt

CallStack : 3981695165

Error initializing rendering configuration, check video card and drivers

  0. 0x00007BC47CA3    RtlCreateActivationContext
  1. 0x0001417C353F    ds, 0x417C353F
  2. 0x0001417BEE4E    ds, 0x417BEE4E
  3. 0x0001417BAF33    ds, 0x417BAF33
  4. 0x0001423D8C26    ds, 0x423D8C26
  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    
rt_process
 13. 0x000000000000    
 14. 0x00015C096020    ds, 0x5C096020
 15. 0x7FFFFFDAF000    
 16. 0x000000000000    


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



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

Is there a minimum version of nvidia drivers? Currently I have 435.

Edit: nevermind, I actually read in the link above that I need at least 440 or 450.

0f3b79350c99d on 16 Jul 2020

I got to the point of building proton with the patches @qsniyg proposed and got to the same crash.

Hopefully the recent changes on the next branch of Proton 5 on the steam client announced by @aeikum, let me play the game 3 hours straight through a few chapters. Stutters as hell to initially compile shaders but then it's pretty smooth except some massive loading times, if it looks like it froze, give it time, be ex-tre-me-ly patient, you likely ran out of memory but the game will catch up. This sometimes can cause some brief audio buffers corruption.

a0kami on 16 Jul 2020

I just tested the game for roughly an hour with 5.0-10 RC, I could launch the game and start playing but there are some major issues.

Game crashes when messing around in the options menu. I only went into it from the main menu so I don't know if it's different in game.
Objects will spawn in random places in the environment, there will be things like grass patches and rocks in the air and on the ground with no collision. There will also be invisible objects with collision (see attached pictures)
There seems to be quite a bit of stuttering and drops in framerate
Got up to the truck cutscene half hour in but then the framerate tanked to the point of crashing. Started the game up again and skipped it. Game was fine until the cut scene with the president another half hour later where the same happened.

### System information:

GPU: RTX 2060
Driver version: 4.6.0 NVIDIA 440.82
Kernal version: 5.6.15-1-MANJARO
Full system information report: https://gist.github.com/SevgiZ/c7e846279f4ced6a9ae61d0ca3a2a65a

Crash logs:
President cutscene:
https://gist.github.com/SevgiZ/db2b351cb54e783b171c628b69131321

Options menu:
https://gist.github.com/SevgiZ/8d5a10d4186b947baf52cdfdec96e5b6

Hopefully I'm not missing anything, I'm pretty new to this stuff

Screenshots

20200716134125_1
20200716134138_1
20200716135603_1
20200716135720_1

SevgiZ on 16 Jul 2020

I actuslly dont have any of these issues when I play and I played for 3 hours straight. Only stuttering I saw was in the beginning and nothing since

lorddickfist on 16 Jul 2020

With 5.0-10-rc2 working flawlessly on my hardware in 4K with maximum graphics quality.
steam-1190460.log

Screenshots

Screenshot from 2020-07-16 10-51-41
Screenshot from 2020-07-16 11-01-47

NTMan on 16 Jul 2020

I also am getting the random flying textures. Playing on Medium settings.

Edit: restarting game solved it.
I think it has to do with changing the settings.

Undeadhunter on 16 Jul 2020

@NTMan on screenshot no. 2 you can see some sky rendering issues; that's a known problem with RADV at the moment.

doitsujin on 16 Jul 2020

👍1

I run into the game visuals freezing after making the first delivery. The cutscene continues but the visuals are completely frozen. If I force-close the game and try pressing "continue" in the game the loading screen too freezes. If I on the other hand load an autosave from just before making the delivery, the game again freezes during the cutscene. My thinking is that something in the next area is being loaded, and the game doesn't like something about it.

Update: gave it another try and this time it didn't freeze. I avoided touching any input this time, but don't know if it's related or a coincidence.

Herbstein on 16 Jul 2020

The game seems to be launching fine now, but after a few minutes of gameplay it seems to freeze and not recover.
Sound is unaffected.
steam-1190460.log

Edit: Game seems to freeze pretty much instantly if I attach a controller for some reason.
The log above has no controller.

The log doesn't really update at the time of the freeze, and my GPU seems fine (using radeontop for monitoring).

0none on 16 Jul 2020

👍1

Regarding my last comment:

I switched from KDE Plasma to openbox, just to check, and the game lasted a lot longer. I was actually able to complete the first mission playing on default settings. So for me, it surely has to do with either me DE or Hardware consumption (memory maybe?)

0none on 16 Jul 2020

I'm seeing the _exact_ same stuff that @SevgiZ mentioned and showcased in those screenshots: floating rocks, patches of grass in the sky, invisible walls, etc. Performance is close to 40% of Windows (doesn't bother me too much, though). Running the latest NVIDIA drivers on Arch Linux, with the current latest stable kernel (5.7.8), GTX 1070, 16GB DDR4, AMD Ryzen 5 1600.

WaywardPooch on 17 Jul 2020

First of all want to say thank you to everyone involved, it's incredible to be able to play DS two days after release. Thank you for your hard work!

Game runs okay, in 4k, without crashes. Occasionally I see random chunk of stone textures in the sky.

Performance, however, could probably be better: ryzen 3900x, gtx1080ti, 2160p resolution, 450.57 driver, fps bounces between 30 and 40 fps. Occasional drops down to 1 fps, audio is not affected. Driver issue? Proton/wine implementation issue? It's not gamebreakingly bad though for me.

0f3b79350c99d on 17 Jul 2020

🎉1

I'm finding that the game tends to freeze when I start a new game and I'm prompted to change brightness settings.
error.log
steam-1190460.log
system specs.log

MilesRdz on 17 Jul 2020

Hello again,
I am getting a consistent crash on the same cutscene, regardless of DE used.
The cutscene shortly after the opening Title where Porter falls into a body of water crashes after exactly 3 seconds.
It ends up killing my Xorg and ending my user session.

No Idea if this is a game Issue or my drivers, but maybe someone else understands the logs better than me.

If I read this correctly, the game somehow causes my GPU (5700XT) to crash, my GPU tries to recover and kills Xorg in the process.

journal.log
steam-1190460.log
Xorg.0.log

0none on 17 Jul 2020

Hello after today's patch the game no longer starts.
it gives error.

Build : dso 102/1901735 22:46 - Thu Jul 16 2020

Internal system error occured.

An Access Violation (C0000005h) has occurred in thread 'Background 4' at instruction location 00000001416A1C35h

CallStack : 3932796059

  0. 0x00007BCDB36E    NtRaiseException
  1. 0x00007BCD458A    raise_func_trampoline
  2. 0x0001416A1C35    ds, 0x416A1C35
  3. 0x00014173DBE5    ds, 0x4173DBE5
  4. 0x000141700A65    ds, 0x41700A65
  5. 0x0001417525F1    ds, 0x417525F1
  6. 0x0001487537DF    ds, 0x487537DF
  7. 0x00014183F59C    ds, 0x4183F59C
  8. 0x00014183A45D    ds, 0x4183A45D
  9. 0x000141838E4C    ds, 0x41838E4C
 10. 0x0001417B0B74    ds, 0x417B0B74
 11. 0x0001417B0C6D    ds, 0x417B0C6D
 12. 0x0001417B1C9B    ds, 0x417B1C9B
 13. 0x0001417AD08D    ds, 0x417AD08D
 14. 0x00007BCD6BDD    DbgUserBreakPoint
 15. 0x000000000000    
 16. 0x0001417ACF80    ds, 0x417ACF80
 17. 0x0789E68125E0    
 18. 0x000000000000    


RAX = f1c30290 RBX = f1c30290 RCX = 4d0f4f8 RDX = 8f3fe720 RSI = 0 RDI = f1c50660
R8 = 0 R9 = 0 R10 = 550000 R11 = 0 R12 = f2450088 R13 = e69c4090
R14 = 0 R15 = 1 RIP = 416a1c35 RSP = 4d0f4d0 RBP = 4d0f5b9 EFL = 10206

Dx12-ErrorCode : 0x80004005
DeviceRemovedReason: 0x0
VMEM: Used 0.00 MB / Budget 8192.00 MB
VMEM: Video 8192.00 MB / Shared 8009.63 MB / System 0.00 MB
MEM: Used 4569.70 MB / Total 16019.25 MB


  0. 0x0001417C0068    ds, 0x417C0068
  1. 0x0001417C1F41    ds, 0x417C1F41
  2. 0x0001417C2256    ds, 0x417C2256
  3. 0x00007BC776AB    __wine_spec_unimplemented_stub
  4. 0x00007BCDAF72    RtlVirtualUnwind
  5. 0x00007BCDB36E    NtRaiseException
  6. 0x00007BCD458A    raise_func_trampoline
  7. 0x0001416A1C35    ds, 0x416A1C35
  8. 0x00014173DBE5    ds, 0x4173DBE5
  9. 0x000141700A65    ds, 0x41700A65
 10. 0x0001417525F1    ds, 0x417525F1
 11. 0x0001487537DF    ds, 0x487537DF
 12. 0x00014183F59C    ds, 0x4183F59C
 13. 0x00014183A45D    ds, 0x4183A45D
 14. 0x000141838E4C    ds, 0x41838E4C
 15. 0x0001417B0B74    ds, 0x417B0B74
 16. 0x0001417B0C6D    ds, 0x417B0C6D
 17. 0x0001417B1C9B    ds, 0x417B1C9B
 18. 0x0001417AD08D    ds, 0x417AD08D
 19. 0x00007BCD6BDD    DbgUserBreakPoint
 20. 0x000000000000    
 21. 0x0001417ACF80    ds, 0x417ACF80
 22. 0x0789E68125E0    
 23. 0x000000000000

steam-1190460.log

error.txt

Llorrin on 17 Jul 2020

😕3 👍3 👀1

Same issue, here's my proton error.log:
error.log
This is with RADV, Mesa 20.2.0-devel (git-c36aac5 2020-07-17 focal-oibaf-ppa).
Note the suspicious "movl $0xdeadca7,0x0000000000000000".

edit: It's probably 0x0deadca7 as in "dead cat". No idea what that means. I bet the devs know.

edit: I'd expect it always cuts off the front for an int literal. compare movl $0xf, bla.

FeepingCreature on 17 Jul 2020

0xdeadca7 looks like a 0xdeadbeef marker of something dead, but it's missing a character, it should always be only 8 characters of hex, something's missing after the 7 perhaps?

EDIT: Yeah 0x0deadca7 would make more sense, but generally hex digits are always specified in set of 2 for such things, so it would be weird to be cutting off the front as well?

OvermindDL1 on 17 Jul 2020

0xdeadca7 looks like a 0xdeadbeef marker of something dead, but it's missing a character, it should always be only 8 characters of hex, something's missing after the 7 perhaps?

EDIT: Yeah 0x0deadca7 would make more sense, but generally hex digits are always specified in set of 2 for such things, so it would be weird to be cutting off the front as well?

I believe their most recent patch was to fix the access violation message for windows users. Based off what I read on the steam discussions page....

lorddickfist on 17 Jul 2020

So the access violation is in the game itself?! How'd they mess up that pointer ownership.... >.>

Did they only fix the message, or fix the ownership violation in the code to fix the bug as well?

OvermindDL1 on 17 Jul 2020

i just tested on win10 on the same pc / dual boot there the game works just fine with latest AMD drivers. windows is not on the 2004 version though.
i have 5700xt & ryzen 3600x

Llorrin on 17 Jul 2020

So the access violation is in the game itself?! How'd they mess up that pointer ownership.... >.>

Did they only fix the message, or fix the ownership violation in the code to fix the bug as well?

unsure they just said this "I'm receiving an Access Violation or black screen crash when launching DEATH STRANDING.

Certain third-party antivirus software, ransomware/malware monitoring apps, streaming software, and other system/performance tools can result in Access Violation crashes. Please try disabling these applications one-by-one to see if you can pinpoint which, if any, programs are causing the error." then many people said that didn't fix anything. Then the update came and I cannot see any patch notes anywhere for that 5gb update.

lorddickfist on 17 Jul 2020

All the crashes I've seen under Windows had a different instruction pointer. I think this is a new one.

FeepingCreature on 17 Jul 2020

the 5gb patch addressed this
This post launch patch includes added AVX judgement to CPU check at startup, stability improvements and general bug fixes.

Llorrin on 17 Jul 2020

the 5gb patch addressed this
This post launch patch includes added AVX judgement to CPU check at startup, stability improvements and general bug fixes.

Yeah just found that^. People are saying the AVX was causing the accesss violations as i go through more of the discussion. Wondering if that can be related to our new found problem?

lorddickfist on 17 Jul 2020

I have AVX. Not the issue.
edit: Maybe Proton doesn't report it right? In any case, it shouldn't lead to a segfault.

FeepingCreature on 17 Jul 2020

Tried some of the solutions that windows users did y'know verify integ, add a dll file, use launch options. I even edited the cfg a bit. Still not result always get the same error with varying background numbers 1-6. Hope valve RC testing finds a fix or if the next patch changes anything.
error.txt

lorddickfist on 17 Jul 2020

Does someone wanna try downloading the original unpatched game? You can download it via steam console by getting the id from steamdb. Im not sure if it'll work because I am unsure if the game is 100% online required

lorddickfist on 18 Jul 2020

Yep, game definitely broken now, many can't start it even in Windows. Some people speculate that they implemented version check for gpu drivers/cpu and it somehow broke the game. There's no way to do a "diff" between old and new executable? I know it's encrypted, but still. Or maybe compare long logs with executed syscalls.

0f3b79350c99d on 18 Jul 2020

Screenshot from 2020-07-18 13-47-35
steam-1190460.log
error.txt

The game started crashing again :(

NTMan on 18 Jul 2020

👍2

Does someone wanna try downloading the original unpatched game?

Copy the following files from V1.0 depot:

ds.exe
nvngx_dlss.dll
oo2core_7_win64.dll
steam_api64.dll
dxcompiler.dll
bink2w64.dll
d3dcompiler_47.dll
data/7017f9bb9d52fc1c4433599203cc51b1.bin

Screenshot_2020-07-18-35_1920x1080

Please be aware that Denuvo might make this not viable for everybody.

FaithLV on 18 Jul 2020

❤2

I have copied the 8 files you listed over from the 1.0 depot, and the error is still observed. Are you sure you didn't copy any other files over as well?

I got it working. Though I witness the rocks in the sky corruption I didn't have before when initially playing on the V1.0.
Because the foliage is procedurally generated for gameplay reasons which I won't spoil, I believe this is all done in shaders and therefore might be a shader cache issue. But that's just a theory.

On the downgrade though, the dlls should have stayed the same according to SteamDB. Here's the hashes of the old and new files:
V1.0:

$ md5sum ds.exe data/7017f9bb9d52fc1c4433599203cc51b1.bin
f182885a0915a61fd7733d8b0b19af67  ds.exe
4359f55ba138b40342f57f7594fc0330  data/7017f9bb9d52fc1c4433599203cc51b1.bin

V1.01:

$ md5sum ds.exe data/7017f9bb9d52fc1c4433599203cc51b1.bin 
a5a4c499453bc96d9615e0380f608d28  ds.exe
e48b5ae1f23255499df04c62b0b6cb85  data/7017f9bb9d52fc1c4433599203cc51b1.bin

Edit:
First tried using the old executable on the most recent data there was a dx12 error code and then the crash everyone is having so far.
BUT then trying the other way around, it appears the most recent executable (_ds.exe_ v1.01) works reliably with the old data (_7017f9bb9d52fc1c4433599203cc51b1.bin_ v1.0). I'm still seeing the corruption though, I'll try clearing my cache and start a fresh game.

a0kami on 18 Jul 2020

Does someone wanna try downloading the original unpatched game?

Copy the following files from V1.0 depot:
ds.exe
nvngx_dlss.dll
oo2core_7_win64.dll
steam_api64.dll
dxcompiler.dll
bink2w64.dll
d3dcompiler_47.dll
data/7017f9bb9d52fc1c4433599203cc51b1.bin
Please be aware that Denuvo might make this not viable for everybody.

When I tried didnt work. Did you remove the new files and just paste the old ones? Because I replaced and merged and still got access violation

lorddickfist on 19 Jul 2020

When I tried didnt work. Did you remove the new files and just paste the old ones? Because I replaced and merged and still got access violation

I was able to get it running, still have the frequent freezing issues and such that I was having before, but at least it is getting past the error now.

Sil3ntPr0digy on 19 Jul 2020

When I tried didnt work. Did you remove the new files and just paste the old ones? Because I replaced and merged and still got access violation

I was able to get it running, still have the frequent freezing issues and such that I was having before, but at least it is getting past the error now.

May I ask how you got it working with the old depot? Id rather have it atleaat without the access violation because before the patch it was running smooth as butter except slight stutter in cutscenes for me.

lorddickfist on 19 Jul 2020

Confirm! With data/7017f9bb9d52fc1c4433599203cc51b1.bin from the 1.0 depot, the game runs again.

FeepingCreature on 19 Jul 2020

When I tried didnt work. Did you remove the new files and just paste the old ones? Because I replaced and merged and still got access violation

I was able to get it running, still have the frequent freezing issues and such that I was having before, but at least it is getting past the error now.

May I ask how you got it working with the old depot? Id rather have it atleaat without the access violation because before the patch it was running smooth as butter except slight stutter in cutscenes for me.

I used DepotDownloader via mono DepotDownloader.dll -app 1190460 -depot 1190461 -manifest 2484036362698851165 as well as using -filelist to only pull down data/7017f9bb9d52fc1c4433599203cc51b1.bin (You can do this by creating an empty text file and then putting only data/7017f9bb9d52fc1c4433599203cc51b1.bin inside the file and then putting the files name after the -filelist switch), I then backed up the v1.01 data/7017f9bb9d52fc1c4433599203cc51b1.bin and put in the one from the depot.

I apologize if the DepotDownloader instructions are not needed, but I know documentation on some of that can be difficult to locate. If you need more instruction, please do let me know.

Sil3ntPr0digy on 19 Jul 2020

❤2

When I tried didnt work. Did you remove the new files and just paste the old ones? Because I replaced and merged and still got access violation

I was able to get it running, still have the frequent freezing issues and such that I was having before, but at least it is getting past the error now.

May I ask how you got it working with the old depot? Id rather have it atleaat without the access violation because before the patch it was running smooth as butter except slight stutter in cutscenes for me.

I used DepotDownloader via mono DepotDownloader.dll -app 1190460 -depot 1190461 -manifest 2484036362698851165 as well as using -filelist to only pull down data/7017f9bb9d52fc1c4433599203cc51b1.bin (You can do this by creating an empty text file and then putting only data/7017f9bb9d52fc1c4433599203cc51b1.bin inside the file and then putting the files name after the -filelist switch), I then backed up the v1.01 data/7017f9bb9d52fc1c4433599203cc51b1.bin and put in the one from the depot.

I apologize if the DepotDownloader instructions are not needed, but I know documentation on some of that can be difficult to locate. If you need more instruction, please do let me know.

Ah I'll try that tonight, when I tried it basically downloaded the original game without the patch and then I copied those files and merged into the original game folder.

lorddickfist on 19 Jul 2020

I copied just 7017f9bb9d52fc1c4433599203cc51b1.bin from my backup and did not work.

New 5,3 GB (5.257.521.033 bytes)
Original 5,3 GB (5.257.135.152 bytes)

Also copying the other files after did not make it work again either

ds.exe
nvngx_dlss.dll
oo2core_7_win64.dll
steam_api64.dll
dxcompiler.dll
bink2w64.dll
d3dcompiler_47.dll

And previewing this before posting the comment I saw that for whatever reason the screen capture is dated from 2 days ago. Very odd, I made it just before writing this.
Captura de tela de 2020-07-18 19-52-19

msmafra on 19 Jul 2020

That error will always say jul 16th

On Sat, Jul 18, 2020, 16:25 Marcelo dos Santos Mafra <
[email protected]> wrote:

I copied just 7017f9bb9d52fc1c4433599203cc51b1.bin from my backup and did
not work.

New 5,3 GB (5.257.521.033 bytes)

Original 5,3 GB (5.257.135.152 bytes)

Also copying the other files after did not make it work again either

ds.exe

nvngx_dlss.dll

oo2core_7_win64.dll

steam_api64.dll

dxcompiler.dll

bink2w64.dll

d3dcompiler_47.dll

And previewing this before posting the comment I saw that for whatever
reason the screen capture is dated from 2 days ago. Very odd, I made it
just before writing this.
[image: Captura de tela de 2020-07-18 19-52-19]
https://user-images.githubusercontent.com/1005457/87863572-9eeb7400-c932-11ea-92fc-bf4c0bf9932a.png

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/4069#issuecomment-660556853,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFLFPNXVZGLO634QWSSHW7LR4IVMXANCNFSM4OZUFSMQ
.

lorddickfist on 19 Jul 2020

I copied just 7017f9bb9d52fc1c4433599203cc51b1.bin from my backup and did not work.

What is the md5sum of the 7017f9bb9d52fc1c4433599203cc51b1.bin that you are currently using?

v1.0 is 4359f55ba138b40342f57f7594fc0330
v1.01 is e48b5ae1f23255499df04c62b0b6cb85

Sil3ntPr0digy on 19 Jul 2020

I copied just 7017f9bb9d52fc1c4433599203cc51b1.bin from my backup and did not work.
New 5,3 GB (5.257.521.033 bytes)
Original 5,3 GB (5.257.135.152 bytes)
Also copying the other files after did not make it work again either
ds.exe
nvngx_dlss.dll
oo2core_7_win64.dll
steam_api64.dll
dxcompiler.dll
bink2w64.dll
d3dcompiler_47.dll
And previewing this before posting the comment I saw that for whatever reason the screen capture is dated from 2 days ago. Very odd, I made it just before writing this.

And after doing another test and thanks for MangoHUD, I saw that it's not starting DS with my GTX1050, despite other games working (tested with No Man's Sky and Metal Gear Solid V).

msmafra on 19 Jul 2020

I copied just 7017f9bb9d52fc1c4433599203cc51b1.bin from my backup and did not work.

What is the md5sum of the 7017f9bb9d52fc1c4433599203cc51b1.bin that you are currently using?

v1.0 is 4359f55ba138b40342f57f7594fc0330
v1.01 is e48b5ae1f23255499df04c62b0b6cb85

❯ md5sum /mnt/480GB/Games/steamapps/common/Death\ Stranding/data/7017f9bb9d52fc1c4433599203cc51b1.bin
e48b5ae1f23255499df04c62b0b6cb85  /mnt/480GB/Games/steamapps/common/Death Stranding/data/7017f9bb9d52fc1c4433599203cc51b1.bin

❯ md5sum /run/media/marcelo/THEGREY/SteamLibrary/Death\ Stranding/data/7017f9bb9d52fc1c4433599203cc51b1.bin
4359f55ba138b40342f57f7594fc0330  /run/media/marcelo/THEGREY/SteamLibrary/Death Stranding/data/7017f9bb9d52fc1c4433599203cc51b1.bin

msmafra on 19 Jul 2020

i can confirm that by just downloading the .bin file and replacing /delete the old one the game runs.

Llorrin on 19 Jul 2020

For people with Ryzen CPU and Navi GPU, which performance do you have ?

Odelpasso on 19 Jul 2020

For people with Ryzen CPU and Navi GPU, which performance do you have ?

i am getting about 55fps at 2440x1080 windowed mode max settings

here a short video

https://streamable.com/k14n4c

i use amdvlk cause with mesa the game freezes after a few seconds.

enabling CAS gives about 20 fps more but it has graphical bugs with amdvlk.

im in Manjaro with mesa 20.0.7

3600x RX5700XT

Llorrin on 19 Jul 2020

There does appear to be some crashing issues in chapter 4, I am using amdvlk atm, when it freezes up, the entire display stops responding and then blacks out and then I have to hard reset to get it back up.

Sil3ntPr0digy on 20 Jul 2020

There does appear to be some crashing issues in chapter 4, I am using amdvlk atm, when it freezes up, the entire display stops responding and then blacks out and then I have to hard reset to get it back up.

Well unfortunately not many people can try to reproduce this. Many such as myself aren't able to play the previous patch even after copying over the all the files from the manifest. Hopefully Valve fixes this with a proton update, or a 505 update reverts whatever they did.

lorddickfist on 20 Jul 2020

There does appear to be some crashing issues in chapter 4, I am using amdvlk atm, when it freezes up, the entire display stops responding and then blacks out and then I have to hard reset to get it back up.

Well unfortunately not many people can try to reproduce this. Many such as myself aren't able to play the previous patch even after copying over the all the files from the manifest. Hopefully Valve fixes this with a proton update, or a 505 update reverts whatever they did.

Same here, copying file over didn't help.
running Nvidia 440.82

Undeadhunter on 21 Jul 2020

When I tried didnt work. Did you remove the new files and just paste the old ones? Because I replaced and merged and still got access violation

I was able to get it running, still have the frequent freezing issues and such that I was having before, but at least it is getting past the error now.

May I ask how you got it working with the old depot? Id rather have it atleaat without the access violation because before the patch it was running smooth as butter except slight stutter in cutscenes for me.

I used DepotDownloader via mono DepotDownloader.dll -app 1190460 -depot 1190461 -manifest 2484036362698851165 as well as using -filelist to only pull down data/7017f9bb9d52fc1c4433599203cc51b1.bin (You can do this by creating an empty text file and then putting only data/7017f9bb9d52fc1c4433599203cc51b1.bin inside the file and then putting the files name after the -filelist switch), I then backed up the v1.01 data/7017f9bb9d52fc1c4433599203cc51b1.bin and put in the one from the depot.

I apologize if the DepotDownloader instructions are not needed, but I know documentation on some of that can be difficult to locate. If you need more instruction, please do let me know.

I downloaded only the .exe and the bin file copying either over didn't fix the issues even installed a protontricks denuvo dependency just in case. Is there something I am missing? I just wanna finish the game
I did this command instead since it got me the binfile still and the .exe "download_depot 1190460 1190461 -manifest 2484036362698851165" Running Arch nvidia 450

lorddickfist on 23 Jul 2020

When I tried didnt work. Did you remove the new files and just paste the old ones? Because I replaced and merged and still got access violation

I was able to get it running, still have the frequent freezing issues and such that I was having before, but at least it is getting past the error now.

May I ask how you got it working with the old depot? Id rather have it atleaat without the access violation because before the patch it was running smooth as butter except slight stutter in cutscenes for me.

I used DepotDownloader via mono DepotDownloader.dll -app 1190460 -depot 1190461 -manifest 2484036362698851165 as well as using -filelist to only pull down data/7017f9bb9d52fc1c4433599203cc51b1.bin (You can do this by creating an empty text file and then putting only data/7017f9bb9d52fc1c4433599203cc51b1.bin inside the file and then putting the files name after the -filelist switch), I then backed up the v1.01 data/7017f9bb9d52fc1c4433599203cc51b1.bin and put in the one from the depot.
I apologize if the DepotDownloader instructions are not needed, but I know documentation on some of that can be difficult to locate. If you need more instruction, please do let me know.

I downloaded only the .exe and the bin file copying either over didn't fix the issues even installed a protontricks denuvo dependency just in case. Is there something I am missing? I just wanna finish the game
I did this command instead since it got me the binfile still and the .exe "download_depot 1190460 1190461 -manifest 2484036362698851165" Running Arch nvidia 450

Did you check the MD5 to make sure they match what was listed earlier for v1.0? The .bin was the only thing I needed. I didn't need to make any other changes to my proton environment other than running the RC. I am running Arch on a RX5700XT using amdvlk primarily and sometimes using radv depending on if amdvlk is being too unstable. Aside from the random crashing sometimes causing the graphics to lock up and require a hard boot, and the relatively low performance, I haven't seen any other major issues getting it running.

Sil3ntPr0digy on 23 Jul 2020

When I tried didnt work. Did you remove the new files and just paste the old ones? Because I replaced and merged and still got access violation

I was able to get it running, still have the frequent freezing issues and such that I was having before, but at least it is getting past the error now.

May I ask how you got it working with the old depot? Id rather have it atleaat without the access violation because before the patch it was running smooth as butter except slight stutter in cutscenes for me.

I used DepotDownloader via mono DepotDownloader.dll -app 1190460 -depot 1190461 -manifest 2484036362698851165 as well as using -filelist to only pull down data/7017f9bb9d52fc1c4433599203cc51b1.bin (You can do this by creating an empty text file and then putting only data/7017f9bb9d52fc1c4433599203cc51b1.bin inside the file and then putting the files name after the -filelist switch), I then backed up the v1.01 data/7017f9bb9d52fc1c4433599203cc51b1.bin and put in the one from the depot.
I apologize if the DepotDownloader instructions are not needed, but I know documentation on some of that can be difficult to locate. If you need more instruction, please do let me know.

I downloaded only the .exe and the bin file copying either over didn't fix the issues even installed a protontricks denuvo dependency just in case. Is there something I am missing? I just wanna finish the game
I did this command instead since it got me the binfile still and the .exe "download_depot 1190460 1190461 -manifest 2484036362698851165" Running Arch nvidia 450

Did you check the MD5 to make sure they match what was listed earlier for v1.0? The .bin was the only thing I needed. I didn't need to make any other changes to my proton environment other than running the RC. I am running Arch on a RX5700XT using amdvlk primarily and sometimes using radv depending on if amdvlk is being too unstable. Aside from the random crashing sometimes causing the graphics to lock up and require a hard boot, and the relatively low performance, I haven't seen any other major issues getting it running.

Could you clarify what MD5 is? I am not sure what you mean by that (sorry new to steam proton)

lorddickfist on 23 Jul 2020

Could you clarify what MD5 is?

https://en.wikipedia.org/wiki/Md5sum

leinardi on 23 Jul 2020

When I tried didnt work. Did you remove the new files and just paste the old ones? Because I replaced and merged and still got access violation

I was able to get it running, still have the frequent freezing issues and such that I was having before, but at least it is getting past the error now.

May I ask how you got it working with the old depot? Id rather have it atleaat without the access violation because before the patch it was running smooth as butter except slight stutter in cutscenes for me.

I used DepotDownloader via mono DepotDownloader.dll -app 1190460 -depot 1190461 -manifest 2484036362698851165 as well as using -filelist to only pull down data/7017f9bb9d52fc1c4433599203cc51b1.bin (You can do this by creating an empty text file and then putting only data/7017f9bb9d52fc1c4433599203cc51b1.bin inside the file and then putting the files name after the -filelist switch), I then backed up the v1.01 data/7017f9bb9d52fc1c4433599203cc51b1.bin and put in the one from the depot.
I apologize if the DepotDownloader instructions are not needed, but I know documentation on some of that can be difficult to locate. If you need more instruction, please do let me know.

I downloaded only the .exe and the bin file copying either over didn't fix the issues even installed a protontricks denuvo dependency just in case. Is there something I am missing? I just wanna finish the game
I did this command instead since it got me the binfile still and the .exe "download_depot 1190460 1190461 -manifest 2484036362698851165" Running Arch nvidia 450

Did you check the MD5 to make sure they match what was listed earlier for v1.0? The .bin was the only thing I needed. I didn't need to make any other changes to my proton environment other than running the RC. I am running Arch on a RX5700XT using amdvlk primarily and sometimes using radv depending on if amdvlk is being too unstable. Aside from the random crashing sometimes causing the graphics to lock up and require a hard boot, and the relatively low performance, I haven't seen any other major issues getting it running.

Could you clarify what MD5 is? I am not sure what you mean by that (sorry new to steam proton)

In the Death Standing game directory run this md5sum ds.exe data/7017f9bb9d52fc1c4433599203cc51b1.bin

the output should be f182885a0915a61fd7733d8b0b19af67 ds.exe 4359f55ba138b40342f57f7594fc0330 data/7017f9bb9d52fc1c4433599203cc51b1.bin if you have the v1.0 files.

Sil3ntPr0digy on 23 Jul 2020

Hello everybody, friendly note that using a third party depot downloader, older versions of the game, and the troubleshooting involved in using that tool is off topic here, however, given the current state of the game I'm not going to step in right now.

Just be aware that the troubleshooting should probably be done on some other medium and the entirety of the current digression will be hidden as off-topic if/when the situation improves.

kisak-valve on 23 Jul 2020

👍5

I have the bin starting with 7017 but I do not Have f18 or 435 here is my output "a5a4c499453bc96d9615e0380f608d28 ds.exe
e48b5ae1f23255499df04c62b0b6cb85 data/7017f9bb9d52fc1c4433599203cc51b1.bin" Since thread is going to be off-topic would you mind helping over discord or steam prodigy?

When I tried didnt work. Did you remove the new files and just paste the old ones? Because I replaced and merged and still got access violation

I was able to get it running, still have the frequent freezing issues and such that I was having before, but at least it is getting past the error now.

May I ask how you got it working with the old depot? Id rather have it atleaat without the access violation because before the patch it was running smooth as butter except slight stutter in cutscenes for me.

I used DepotDownloader via mono DepotDownloader.dll -app 1190460 -depot 1190461 -manifest 2484036362698851165 as well as using -filelist to only pull down data/7017f9bb9d52fc1c4433599203cc51b1.bin (You can do this by creating an empty text file and then putting only data/7017f9bb9d52fc1c4433599203cc51b1.bin inside the file and then putting the files name after the -filelist switch), I then backed up the v1.01 data/7017f9bb9d52fc1c4433599203cc51b1.bin and put in the one from the depot.
I apologize if the DepotDownloader instructions are not needed, but I know documentation on some of that can be difficult to locate. If you need more instruction, please do let me know.

I downloaded only the .exe and the bin file copying either over didn't fix the issues even installed a protontricks denuvo dependency just in case. Is there something I am missing? I just wanna finish the game
I did this command instead since it got me the binfile still and the .exe "download_depot 1190460 1190461 -manifest 2484036362698851165" Running Arch nvidia 450

Did you check the MD5 to make sure they match what was listed earlier for v1.0? The .bin was the only thing I needed. I didn't need to make any other changes to my proton environment other than running the RC. I am running Arch on a RX5700XT using amdvlk primarily and sometimes using radv depending on if amdvlk is being too unstable. Aside from the random crashing sometimes causing the graphics to lock up and require a hard boot, and the relatively low performance, I haven't seen any other major issues getting it running.

Could you clarify what MD5 is? I am not sure what you mean by that (sorry new to steam proton)

In the Death Standing game directory run this md5sum ds.exe data/7017f9bb9d52fc1c4433599203cc51b1.bin

the output should be f182885a0915a61fd7733d8b0b19af67 ds.exe 4359f55ba138b40342f57f7594fc0330 data/7017f9bb9d52fc1c4433599203cc51b1.bin if you have the v1.0 files.

I have the bin starting with 7017 but I do not Have f18 or 435 here is my output "a5a4c499453bc96d9615e0380f608d28 ds.exe
e48b5ae1f23255499df04c62b0b6cb85 data/7017f9bb9d52fc1c4433599203cc51b1.bin" Since thread is going to be off-topic would you mind helping over discord or steam prodigy?

lorddickfist on 23 Jul 2020

Was able to get it working with the correct bin file. I had to use a third party software on github depotdownloader at: https://github.com/SteamRE/DepotDownloader
Then I had to extract it and download only the one bin file by setting up a text file instructions given by sil3ntprodigy above.
don't use steam console like I did at first, use depotdownloader. Haven't noticed any performance degradation.

lorddickfist on 23 Jul 2020

@kisak-valve do you know if fixes here are being actively worked on?

whyrusleeping on 24 Jul 2020

wine devs made a sticky saying they were interested in getting this game working. Yes they're working on it. Lots of moving parts right now, I would be patient for a good month or so.

minionprocyk on 24 Jul 2020

After a hard crash where I had to reset my computer, I encountered floating textures. This can be fixed by deleting the shader cache in the steamapps folder. Just make sure you're deleting the one with the same app ID as Death Stranding.

lorddickfist on 24 Jul 2020

V1.0.1 works on Proton 5.0.10-rc3

brainrom on 24 Jul 2020

V1.0.1 works on Proton 5.0.10-rc3

How is the performance? Any noticeable differences?

UPDATE: Can confirm that the new proton update allows v1.0.1 to work without any tinkering. After moving back the v1.0.1 7017f9bb9d52fc1c4433599203cc51b1.bin it launches without issue. In fact, performance seems to have improved slightly. I will do some additional testing to confirm if this is in fact the case.

Sil3ntPr0digy on 24 Jul 2020

👍2

Anyway game crashes very often. Gamepad disabled. Using amdvlk.

brainrom on 24 Jul 2020

V1.0.1 works on Proton 5.0.10-rc3

How is the performance? Any noticeable differences?

UPDATE: Can confirm that the new proton update allows v1.0.1 to work without any tinkering. After moving back the v1.0.1 7017f9bb9d52fc1c4433599203cc51b1.bin it launches without issue. In fact, performance seems to have improved slightly. I will do some additional testing to confirm if this is in fact the case.

Can you tell me, how did you download 7017f9bb9d52fc1c443359999203cc51b1.bin? Encountered error downloading manifest for depot 1190461 2484036362698851165: An error occurred while sending the request. I have this error.

Asketi4 on 24 Jul 2020

Can you tell me, how did you download
7017f9bb9d52fc1c443359999203cc51b1.bin?

You don't need to download it already. v1.0.1 works now.

brainrom on 24 Jul 2020

👍1

Black screen, v1.01

Asketi4 on 24 Jul 2020

Black screen, v1.01

Were you ever able to get the game to launch with v1.0?

What is your GPU/Drivers?
What FPS counter are you using?
What are your launch commands?

Sil3ntPr0digy on 25 Jul 2020

Black screen, v1.01

where you ever able to get the game to launch with v1.0?

What is your GPU/Drivers?
What FPS counter are you using?
What are your launch commands?

GTX 1060, 440.100, Xeon E5 2689, Without launch commands

Asketi4 on 25 Jul 2020

GTX 1060, 440.100, Xeon E5 2689, Without launch commands

Do you have any time in game yet? Meaning were you able to play the game at all before V1.0.1?

Sil3ntPr0digy on 25 Jul 2020

GTX 1060, 440.100, Xeon E5 2689, Without launch commands

Do you have any time in game yet? Meaning were you able to play the game at all before V1.0.1?

Yes, I played for 7 hours

Asketi4 on 25 Jul 2020

What can be done to beat often crashes? I tried to use lightweight DE, as mentioned before, no luck.

brainrom on 25 Jul 2020

Hello @brainrom, the AMD note in https://github.com/ValveSoftware/Proton/issues/4070#issuecomment-663693971 applies to your system.

kisak-valve on 25 Jul 2020

I'm using AMDVLK 2.0.152 and it seems so far to be more stable with better performance.

Sil3ntPr0digy on 25 Jul 2020

Wow! New Proton update makes it work again. I'm going to test more. Used to get floating rocks and stuff, but that looks to have gone away. FPS is much better sitting at around 35ish as opposed to 20-25 on average. Early reporting, but I thought it was interesting. Cloud saves still don't work, so I just copy them over manually.

EDIT: Just ran into floating rocks again after loading a windows save file, so I deleted my shader cache and it went away. Now I get major stutters, but I guess that'll go away after using it for some time.

WaywardPooch on 25 Jul 2020

So far these are my findings:

radv/mesa: crash before game loads
amdvlk: crash on cutscene (when you climb into the vehicle containing the body)
amdgpu-pro: crash on cutscene (when you climb into the vehicle containing the body)

Really excited to try this game, I just can't get past that cutscene (had the same issue with v1.00 on the last update). Also I don't think amdvlk has better performance for me, I think it's slightly worse.

Mind you, I'm using KDE, not a lightweight DM.

TheDiscordian on 25 Jul 2020

Can someone with NVIDIA confirm whether they're also affected by the crash in the vehicle cutscene after the prologue?

Plagman on 25 Jul 2020

I don't think it's anything specific to the cutscene. If you skip ahead (press escape) it'll get stuck in another sequence. I've also observed that the time to crash is variable, both when measured from game launch and cutscene start. Lastly, I've seen a steady increase of allocated system memory - about 4-6 megabytes per second as measured by htop. That is not the case with video RAM which fluctuated around the 4 gigabytes mark.

Herbstein on 25 Jul 2020

Really excited to try this game, I just can't get past that cutscene (had the same issue with v1.00 on the last update).

Are you using the default graphics settings? I found changing them made cutscenes more unstable and more prone to crashes and freezes.

Sil3ntPr0digy on 25 Jul 2020

1060 on 440.100, no launch commands, newest proton release and newest DS patch: Almost seems like it's going to launch, then tells me that Windows 10 Version 1809 is required. Saw this mentioned earlier but no solution.

On the previous DS patch it didn't even get that far before crashing silently, so it's progress!

isengard on 25 Jul 2020

@isengard are you on Proton 5.0-10 RC? "newest" is not helpful.

@Sil3ntPr0digy I'm on pretty high settings, I'll try turning them down. Thanks!

Edit: No difference on AMDVLK, haven't tested AMDGPU-PRO yet.

@Herbstein Thanks! I'll see if it's possible for me to watch the cutscenes on YouTube or something. I like testing the game, but I also want to learn the story. I've also found crashes to be variable.

Edit: After skipping 2 cutscenes in a row, crash on AMDVLK, haven't tested AMDGPU-PRO yet.

TheDiscordian on 25 Jul 2020

Снимок экрана от 2020-07-25 02-58-52
30 FPS, many drops and stutters, flying grass and rocks

Asketi4 on 25 Jul 2020

<Reply to one comment ago>

try deleting your shadercache in steamapps make sure you select the folder the same as the appid of DS

lorddickfist on 25 Jul 2020

<Reply to one comment ago>

Thanks, it helped with flying grass and rocks, but not with stutters and drops, also the game often does not respond to mouse clicks. But the game works nice with gamepad

Asketi4 on 25 Jul 2020

Hello @brainrom, the AMD note in #4070 (comment) applies to your system.

So, just wait for an update or try to use AMDGPU-PRO?

brainrom on 25 Jul 2020

Upgraded to Proton 5.0.10-rc3 and it works fine for 1.01 games, but there are material bugs.

coxde on 25 Jul 2020

I can't press next button

Asketi4 on 25 Jul 2020

I can't press next button

try to delete the shadercache

/home/YOURNAME/.steam/steam/steamapps/shadercache/1190460

delete everything in that folder.

Llorrin on 25 Jul 2020

I can't press next button

try to delete the shadercache

/home/YOURNAME/.steam/steam/steamapps/shadercache/1190460

delete everything in that folder.

Actually check ${HOME}/.local/share/Steam/steamapps/shadercache/ if it's your only or main library or the other libraries if you have more than one. In my case /mnt/480GB/Games/steamapps/shadercache/

msmafra on 25 Jul 2020

Interestingly, I got the original DLL issue when running proton 5.0.9.

I tested 5.0-10 RC2 with downgraded bin and additionally RC3 today with the v1.0.1 bin, both show a different "Windows" error as seen below;

Screenshot from 2020-07-25 22-55-29

Full log;
steam-1190460.log.gz

System info;
sysinfo.txt

qlmwm on 26 Jul 2020

Interestingly, I got the original DLL issue when running proton 5.0.9.

I tested 5.0-10 RC2 with downgraded bin and additionally RC3 today with the v1.0.1 bin, both show a different "Windows" error as seen below;

What version is your nvidia driver?

Sil3ntPr0digy on 26 Jul 2020

Interestingly, I got the original DLL issue when running proton 5.0.9.
I tested 5.0-10 RC2 with downgraded bin and additionally RC3 today with the v1.0.1 bin, both show a different "Windows" error as seen below;

What version is your nvidia driver?

I just updated the sysinfo to the info steam provides, I'm running 440.100.

qlmwm on 26 Jul 2020

I've upgraded to proton-5.0-10-rc3 and game still crashes on startup with the same message as before. I'm using navi with Mesa 20.2.0.

steam-1190460.log

Yarwin on 26 Jul 2020

Mine worked with Intel Core i5-7300HQ, 16GB RAM, 5.0.9-next, NVIDIA drivers 450.57, kernel 5.7.8-fsync, mesa-dri-drivers 20.1.4. Just tested few minutes since it seems that my poor GTX1050 4GB mobile won't cut it.

msmafra on 26 Jul 2020

Have there been any tests using ACO as Vulkan renderer on Radeon cards?
Or maybe I should just buy the game and test myself.

jhaand on 26 Jul 2020

Have there been any tests using ACO as Vulkan renderer on Radeon cards?

Yes. ACO is broken. LLVM is broken. Mesa is just broken right now. It works if you use the 1.0 version of the bin, but it still crashes almost every cutscene and occasionally during regular gameplay.

FeepingCreature on 26 Jul 2020

I’m afraid for Horizon in 2 weeks 😂

Odelpasso on 26 Jul 2020

Have there been any tests using ACO as Vulkan renderer on Radeon cards?

Yes. ACO is broken. LLVM is broken. Mesa is just broken right now. It works if you use the 1.0 version of the bin, but it still crashes almost every cutscene and occasionally during regular gameplay.

Then I'll wait for next month. Also I hope that Debian packages mesa 20.1.4 by then.

jhaand on 26 Jul 2020

This probably needs to be copied here since many people seem very confused:

Plagman commented 2 days ago • 
The "next" branch has now been updated with a vkd3d fix for the new compute shaders in 1.01. It appears to work on NVIDIA, but currently crashes on radv+ACO, pending a driver fix. Will post more info when we have it, but in the meantime NVIDIA users should be able to play the game again after getting the Proton update on the "next" branch.

Update: It also works on AMDGPU-PRO 20.20 on AMD GPUs. The current radv crash is caused by remaining vkd3d issues and will need additional Proton updates, will post an update next week when we know more.

In short:
-AMDVLK works
-Nvida works
-RADV/ACO does not work, needs more work to be done
-You do not need to downgrade the game.

I've tested the build using AMDVLK on Fedora 32 and played 2 hours without issue.

GloriousEggroll on 26 Jul 2020

👍1

Is anyone NOT encountering a memory leak? Like after playing for 2 hours the game will use about 20gb of ram.

lorddickfist on 27 Jul 2020

Is anyone NOT encountering a memory leak? Like after playing for 2 hours the game will use about 20gb of ram.

yes i had this issue. after 2 hours the computer froze completely. first there was a massive fps drop from 60 - 70 to 1 -2 then everything was unresponsive. had to do hard reset.

Manjaro, amdvlk, 3600x 5700xt

Llorrin on 27 Jul 2020

Death Stranding works on my system, and I didn't get a crash during the motorbike scene at the beginning of the game.

I did encounter the game freezing a few times after going to the options menu. In the end I managed to change game options.

Unfortunately, I am affected by the floating rocks and grass bug as well. Deleting the shadercache folder or its contents didn't help.

Every time I launch the game, the files in that folder get recreated.

I use Nvidia, driver version: 450.56.02, vulkan-loader version installed on system 1.2.141

edit:
I've tried disabling shader caching in Steam options - it didn't help with the floating objects problem.

linuxiorr on 27 Jul 2020

Death Stranding works on my system, and I didn't get a crash during the motorbike scene at the beginning of the game.

I did encounter the game freezing a few times after going to the options menu. In the end I managed to change game options.

Unfortunately, I am affected by the floating rocks and grass bug as well. Deleting the shadercache folder or its contents didn't help.

Every time I launch the game, the files in that folder get recreated.

I use Nvidia, driver version: 450.56.02, vulkan-loader version installed on system 1.2.141

I am not sure if it's viable, but you can disable the shader cache on Steam Client. I am going to do it later to test it. Probably won't do any relevant improvement for me, because of my modest configuration, but I'll try it.

msmafra on 27 Jul 2020

Death Stranding works on my system, and I didn't get a crash during the motorbike scene at the beginning of the game.

I did encounter the game freezing a few times after going to the options menu. In the end I managed to change game options.

Unfortunately, I am affected by the floating rocks and grass bug as well. Deleting the shadercache folder or its contents didn't help.

Every time I launch the game, the files in that folder get recreated.

I use Nvidia, driver version: 450.56.02, vulkan-loader version installed on system 1.2.141

edit:
I've tried disabling shader caching in Steam options - it didn't help with the floating objects problem.

It is supposed to be recreated. I have constant recreation of the floating rocks, I first, try to clear cache. If that doesn't work I make sure my system is up to date. Finally I try to exit steam and reenter I actually just had that glitch and it was fixed by exiting steam and relaunching it.

lorddickfist on 27 Jul 2020

Death Stranding gets past the launch crash on 1.01 with the 27-July update of proton 5 next on Mesa RADV/ACO.

edit: Got maybe 30 seconds in and the UI hangs. So that's still a thing.
edit: Turn ACO off and the game hangs outside after a few steps.

FeepingCreature on 27 Jul 2020

👍1

Since the July 27th update I can now load in again using Mesa/RADV, with more stability. Specifically, I can skip cutscenes, and play the game (with intermittent freezes/crashes). The game seems to play the same as my report here.

Video Card:
    Driver:  X.Org AMD Radeon (TM) RX 480 Graphics (POLARIS10, DRM 3.36.0, 5.6.19-2-MANJARO, LLVM 10.0.0)
    Driver Version:  4.6 (Compatibility Profile) Mesa 20.1.3
    OpenGL Version: 4.6
    Desktop Color Depth: 24 bits per pixel
    Monitor Refresh Rate: 59 Hz
    VendorID:  0x1002
    DeviceID:  0x67df

TheDiscordian on 28 Jul 2020

👍3

Since the July 27th update I can now load in again using Mesa/RADV, with more stability. Specifically, I can skip cutscenes, and play the game (with intermittent freezes/crashes). The game seems to play the same as my report here.
Video Card:
    Driver:  X.Org AMD Radeon (TM) RX 480 Graphics (POLARIS10, DRM 3.36.0, 5.6.19-2-MANJARO, LLVM 10.0.0)
    Driver Version:  4.6 (Compatibility Profile) Mesa 20.1.3
    OpenGL Version: 4.6
    Desktop Color Depth: 24 bits per pixel
    Monitor Refresh Rate: 59 Hz
    VendorID:  0x1002
    DeviceID:  0x67df

the same does not work for me however.
same gpu
ryzen 7
popOS

nimatel on 28 Jul 2020

I'm getting consistent hard locks during the loading of a cutscene following completing Episode 9, it happens so quickly I don't even get a chance to skip. After the loading screen, clicking continue leads to an instant crash. Using AMDVLK 2.0.152.

Update 1: I was able to get past the hard lock point by switching to RADV 20.1.4.

Update 2: I'm getting consistent crashes every time I try to use AMDVLK in Episode 10. I have gone into different zones, saved, restarted the game using AMDVLK instead of RADV, and it will hard lock. RADV will load, but is not very stable and is still prone to random freezes that require the game to be closed.

Update 3: It appears that AMDVLK (currently using 2.0.152) is causing crashes that result in hard locks after Episode 9, I've been using RADV to finish things up, but I am having issues with the credits in Episode 14, as it isn't skippable and the game is freezing before it completes.

Update 4: I was able to get past the Episode 14 credits and into Episode 15 by just trying enough times that it eventually managed to get through all of the credits without crashing. Took a while, but it is possible.

Update 5: AMDVLK appears to no longer cause crashes once Episode 15 has started. So the issue is just during Episodes 10-14.

Sil3ntPr0digy on 28 Jul 2020

👍2

After proton update I was able to start and play the game. Initially I was unable to get pass the first cutscene, but after setting max FPS to 60 and turning off vsync I get it to work.
Game by itself appears to run smoothly, although it crashed at the end of the "trailer" move sequence.

Yarwin on 29 Jul 2020

The game hangs on my system with the latest Proton next (rc4). I can get to the start menu and select a new game.
The game hangs somewhere between 42% of the first loading screen and I've gotten as far as the first cut scene with the skeleton guy on the moon for about a second. But that took a lot of retries.
htop (1) shows that as soon as the game hangs, that 1 cores goes to 100% CPU load. The rest have no load.

I use the default start option and settings.

Summary system info:
Kernel version: SMP Debian 5.7.6-1 (2020-06-24)
Driver: X.Org AMD Radeon RX 5700 XT (NAVI10, DRM 3.37.0, 5.7.0-1-amd64, LLVM 10.0.1)
Distribution: Debian Bullseye (Testing)
Mesa: 20.1.4 (from Unstable)
Renderer: "AMD RADV NAVI10 (LLVM 10.0.1)"
Proton: 1595878477 proton-5.0-10-rc4
Desktop environment: KDE Plasma 5.17

More specific information here:
steam_system_info.txt

If people want more information, I can provide that.

jhaand on 30 Jul 2020

The game seems to run fine with shader caching disabled (still had the floating rocks occur once, though). Unfortunately the memory leaking means I have to reset the game every hour or so. Using Proton 5.0-next
https://gist.github.com/jclc/b21a9bd7d8e7f198385e298bf8e1663c
After playing a bit more, disabling shader cache really doesn't fix the floating rocks issue, just makes it a little less frequent. Haven't had any crashes besides running out of memory either way.

jclc on 30 Jul 2020

Disabling the Shader Caching doesn't help in my case. I still can't play the game.
The issue remains the same. https://github.com/ValveSoftware/Proton/issues/4069#issuecomment-666202990

jhaand on 31 Jul 2020

Disabling the Shader Caching doesn't help in my case. I still can't play the game.
The issue remains the same. #4069 (comment)

RADV is for me also a no go, sometimes it will load into the game but it will freeze after 30 secs or so.

only AMDVLK works for me but it has memory leak,

im on Manjaro testing

3600x RX5700xt.

Llorrin on 31 Jul 2020

😕1

Disabling the Shader Caching doesn't help in my case. I still can't play the game.
The issue remains the same. #4069 (comment)

Are you running default graphics settings? I had a lot of issues with crashes when using non default graphics settings. Also try out AMDVLK, it seems to be far more stable except during specific episodes.

Sil3ntPr0digy on 1 Aug 2020

Are you running default graphics settings? I had a lot of issues with crashes when using non default graphics settings. Also try out AMDVLK, it seems to be far more stable except during specific episodes.
I run the default graphic settings.
Compiling and trying out AMDVLK did the trick. I can now run the game. But due to the memory leak I need to restart every 45 minutes.
I now have everything setup that my other games use the RADV / Mesa Vulkan driver and only Death Stranding uses AMDVLK.
The shell variable VK_ICD_FILENAMES really helps in this case. As you can see in this posting. https://www.reddit.com/r/linux_gaming/comments/h8b7zv/amd_gpu_vulkan_driver_how_to_easily_switch/furvsmr/

jhaand on 2 Aug 2020

Even with shaders cache disable I've had the floating rocks, however re-enabling share cache and deleting the cache every time I play seems to work the best.

Undeadhunter on 2 Aug 2020

@Llorrin wrote:

only AMDVLK works for me but it has memory leak,

im on Manjaro testing

Is there an issue in the AMDVLK repository, or should I write one?

jhaand on 2 Aug 2020

I've got it working perfectly on Manjaro, Kernel 5.4.52-1 with Nvidia 440 drivers. I was getting very little lag and had no issues with the floating rocks or foliage.

However today I upgraded to kernel 5.7 because I heard it had FSync support built in for proton which was supposed to improve performance. I booted up Death Stranding and got the floating rocks and bad stuttering in the city. I then tried deleting my shader cache and still had the floating rocks and stuttering. Deleting shader cache and also restarting steam showed no difference. I then restarted back into the LTS kernel 5.4 that I had been using and the floating rock issue disappeared, along with my stuttering issues. Could there be a correlation between FSync or the kernel version and the floating rocks?

SpamHamwich on 2 Aug 2020

I've got it working perfectly on Manjaro, Kernel 5.4.52-1 with Nvidia 440 drivers. I was getting very little lag and had no issues with the floating rocks or foliage.

However today I upgraded to kernel 5.7 because I heard it had FSync support built in for proton which was supposed to improve performance. I booted up Death Stranding and got the floating rocks and bad stuttering in the city. I then tried deleting my shader cache and still had the floating rocks and stuttering. Deleting shader cache and also restarting steam showed no difference. I then restarted back into the LTS kernel 5.4 that I had been using and the floating rock issue disappeared, along with my stuttering issues. Could there be a correlation between FSync or the kernel version and the floating rocks?

I'm running 5.7.10-arch-1 and never encountered floating rocks or artifacts of any kind on my RX 5700XT using either RADV or AMDVLK.

Sil3ntPr0digy on 2 Aug 2020

❤1

Hello @SpamHamwich, you should be able to test that by adding PROTON_NO_FSYNC=1 %command% to the game's launch options. This should block Proton from using futex wait multiple on kernels that have a patch set to support it.

kisak-valve on 3 Aug 2020

❤2

@kisak-valve I loaded back into 5.7 and pulled up the affected save file and the issue wasn't present any longer. I also loaded up the last save file i made in 5.4 and it was unaffected, which means the kernel version switch must have been coincidental. Based on what I saw, the issue could be either coincidental or based on some sort of cached elements outside of shader cache, considering the restart might have been instrumental to the fix.

I should also mention that after I restarted and was playing successfully in 5.4 for a while, I found one area outside of Capitol Knot City where the rocks and foliage were floating, but upon walking away from that area I found that all of the rocks are in the correct position everywhere else. When I returned some time later (after reaching the first western outpost), I found that the rocks in the affected area had been fixed.

I should also mention that the rocks are physical objects, not just floating textures that you can walk through. You can actually climb onto them. It could be possible that shader cache isn't the location that needs to be cleared in order to fix the issue, although I would need to encounter the issue another time to tell for sure. I'll also test the PROTON_NO_FSYNC command next time I see it.

SpamHamwich on 3 Aug 2020

I should also mention that the rocks are physical objects, not just floating textures that you can walk through. You can actually climb onto them.

This has been confirmed by other users, the floating rocks aren't just a floating texture, they are actually solid. I believe some people encountered situations where that made it near impossible to progress due to how bad it can be sometimes.

Sil3ntPr0digy on 3 Aug 2020

@Llorrin wrote:

only AMDVLK works for me but it has memory leak,
im on Manjaro testing

Is there an issue in the AMDVLK repository, or should I write one?

Memory leak occurs with Nvidia as well.

jclc on 3 Aug 2020

👍1

My memory seems to fill up extremely quickly (90% of RAM used within 3 minutes of gameplay causing freezes and crashes) when playing Death Stranding on Linux 5.6.19-2-MANJARO with AMDVLK 2020.Q3.1-1 and proton-5.0-10-rc4. System was so starved for memory I could barely quit the app by switching to another TTY; even the login to the CLI was slow!

On Mesa/RADV 20.1.3-1 I get the "July 16" DX12 crash others have reported

mrredcon on 3 Aug 2020

My memory seems to fill up extremely quickly (90% of RAM used within 3 minutes of gameplay causing freezes and crashes) when playing Death Stranding on Linux 5.6.19-2-MANJARO with AMDVLK 2020.Q3.1-1 and proton-5.0-10-rc4. System was so starved for memory I could barely quit the app by switching to another TTY; even the login to the CLI was slow!

On Mesa/RADV 20.1.3-1 I get the "July 16" DX12 crash others have reported

The game has, at least on my pc, a memory leak ratio of 2,5MB sec, it reaches 7GB used ram very fast, so if your system has only 8gb RAM it will lock really fast.

Llorrin on 3 Aug 2020

I'm now able to play a little bit but with extreme artifacting...was I supposed to delete the shader cache switching from AMDVLK to RADV back to AMDVLK?
20200803102447_1
20200803102550_1

EDIT: Deleting shadercache seemed to get rid of the artifacts but as soon as I opened the 'Garage' menu I got the a crash (on AMDVLK)
error.txt
I'm noticing that there is 3. 0x00007BC776AB __wine_spec_unimplemented_stub in the error.txt...I think I will try to get a full log and figure out which function it is missing like what was done higher up in this thread.

EDIT 2: The full log swelled to 26GB just idling on the main menu which was running at 1 FPS on AMDVLK, will try again on RADV.

EDIT 3: Did the same thing on RADV, I can't get past the main menu. With logging disabled game behaves very similarly to AMDVLK-- I get 2-3 minutes of flawless gameplay and then artifacts show up and the game freezes. My memory didn't fill up though, I was just reading top incorrectly the first time. Also made rookie mistakes before by not putting %command% at the end of the Steam launch options but I am pretty confident I did it correctly this time.

mrredcon on 3 Aug 2020

I did an update of Debian testing today. It looks that with a new kernel 5.7.10 packaged with Debian that the memory leak is smaller. I will do some testing to see if this is the case.

Testing with Debian Testing, Mesa 20.1.4, AMDVLK, RAdeon 5700 XT.

jhaand on 3 Aug 2020

On Manjaro with a Vega 64 I was getting the same random freezing: screen stopping, but sound continuing. I switched to AMDVLK and I thought I had gotten the game to work fine . . . although I did have the stutters and the memory leak, I was able to play without the totally random game freezes. In fact, I was able to play from the beginning up to the start of Episode 3. Now I get total system lockup (requiring hard reboot) at EXACTLY the same point every time: at 43% of the loading screen right after the cutscene where Sam gets his dreamcatcher.

I have tried switching back to RadV--and get the same freeze. Without clearing shader cache--same issue. Clearing shader cache--same issue. Turning off shader caching totally--same issue. Fsync kernel--same issue, 5.7 kernel--same issue. 5.6 kernel--same issue. 5.4 kernel--same issue. Different savegame--same issue.

Always at 43% in that one loading screen at the beginning of Episode 3--hard system freeze requiring hardware reboot.

Obviously I have no idea if this is related to the original issue, but without the AMDVLK fix I wouldn't have gotten to this point in the game to find the issue.

EDIT: I upgraded to the testing branch which gave me kernel 5.7.12-1 and AMDVLK 2020.Q3.2-1
Same freezing problems occurs at 43% loading of the cutscene, leaving the game unplayable.

EDIT 2: [WORKAROUND] I got past the problem not by loading earlier and earlier saves, as @FaithLV suggested--no matter how far back I went, when I got back to episode 3, I would have the lockup. Instead, I booted into the hated Windows, downloaded the game there, played it past the intro to episode 3, and then saved the game. Next, I rebooted into linux, downloaded that save-game file from steam cloud, and put it in the right place for linux steam to find it. Then I just loaded the save and played on. This is not a fix, but a really crappy workaround. At least I don't have to use windows again until I hit another freeze point and have to do it all again. Hopefully the problem will be fixed in the next release of proton.

DrPhreek on 3 Aug 2020

I have a GTX 1070 and I found that with driver version 450.57, the floating rocks and grass workaround works (when I disable the shader precaching and delete the shadercache folder contents), however oftentimes the objects start floating again after playing for a bit.

On the Nvidia beta developer driver (version 450.56.02), the workaround doesn't work at all.

linuxiorr on 4 Aug 2020

On Manjaro with a Vega 64 I was getting the same random freezing: screen stopping, but sound continuing. I switched to AMDVLK and I thought I had gotten the game to work fine . . . although I did have the stutters and the memory leak, I was able to play without the totally random game freezes. In fact, I was able to play from the beginning up to the start of Episode 3. Now I get total system lockup (requiring hard reboot) at EXACTLY the same point every time: at 43% of the loading screen right after the cutscene where Sam gets his dreamcatcher.

I now have the same problem. After the animation where Sam receives his dreamcatcher, while loading Episode 3 "Fragile", the system totally locks up. Although the progress bar can reach to 99%. But then it's game over for my machine.

Even the reset button doesn't work in some cases.
Running Debian Testing with kernel 5.7.10
AMDVLK from August 1.
GFX driver: Mesa 20.1.4.
Card: AMD Radeon RX5700 XT

The game never has run using libvulkan_radeon.so shipped with Mesa 20.1.4
So, I'm stuck here.

jhaand on 6 Aug 2020

Same freezing problems occurs at 43% loading of the cutscene, leaving the game unplayable.

I've had similar issues, seems like the save game gets corrupted, try loading from an earlier save.

Edit: I've also noticed that cloud saves do not work properly on Proton, probably for the better.

FaithLV on 7 Aug 2020

I recently switched my desktop over to Linux (KDE Neon) from Windows 10, and noticed that my Steam Cloud saves for Death Stranding did not transfer over. I then tried to troubleshoot the issue by installing Death Stranding on my Windows 10 laptop, and lo and behold my saves transferred over to that computer just fine.

coolitic on 7 Aug 2020

Hello @SpamHamwich, you should be able to test that by adding PROTON_NO_FSYNC=1 %command% to the game's launch options. This should block Proton from using futex wait multiple on kernels that have a patch set to support it.

I can confirm that it eliminates all these issues related to random stuff appearing on restarts and FPS is also more consistent without FSYNC right now.

UPD: oh, well, displaced foliage can still appear with fsync disabled, but it anyway is a much rarer thing to occur.

BlokenClockCrisps on 7 Aug 2020

I recently switched my desktop over to Linux (KDE Neon) from Windows 10, and noticed that my Steam Cloud saves for Death Stranding did not transfer over. I then tried to troubleshoot the issue by installing Death Stranding on my Windows 10 laptop, and lo and behold my saves transferred over to that computer just fine.

You can download the save files directly from steam website, and copy it into the save folder. That's how I "fixed" that issue.
Steam doesn't officially support this, so files aren't shared between Linux and Windows yet.
Might come in a future update

Undeadhunter on 10 Aug 2020

So is it still happening this error code or did we find a workaround? It's still happening to me with 1.0.2
and 440.100 under fedora 32 with 5.7.12 kernel
Or is it related to the version driver also as I've seen on some posts here

boistordu on 11 Aug 2020

So is it still happening this error code or did we find a workaround? It's still happening to me with 1.0.2
and 440.100 under fedora 32 with 5.7.12 kernel
Or is it related to the version driver also as I've seen on some posts here

I changed to Negativo17 (450.57) on Fedora 32 with 5.7.xx and it's working with Fedora's kernel and with GloriousEggRoll's one. I did not try to return to RPMFusion's one (440.100)

msmafra on 11 Aug 2020

So for those who need cuda and so the rpmfusion we are screwed 😁

boistordu on 12 Aug 2020

So for those who need cuda and so the rpmfusion we are screwed

There are CUDS packages in Netgativo17's repo:

❯ doas dnf repoquery --repo fedora-nvidia
Last metadata expiration check: 0:53:16 ago on Wed Aug 12 09:49:05 2020.
akmod-nvidia-3:450.57-1.fc32.x86_64
compat-nvidia-repo-3:450.57-1.fc32.noarch
cuda-1:10.2.89-2.fc32.x86_64
cuda-cli-tools-1:10.2.89-2.fc32.x86_64
cuda-cublas-1:10.2.89-2.fc32.x86_64
cuda-cublas-devel-1:10.2.89-2.fc32.x86_64
cuda-cudart-1:10.2.89-2.fc32.x86_64
cuda-cudart-devel-1:10.2.89-2.fc32.x86_64
cuda-cudnn-1:7.6.5.32-1.fc32.x86_64
cuda-cudnn-devel-1:7.6.5.32-1.fc32.x86_64
cuda-cudnn-samples-1:7.6.5.32-1.fc32.x86_64
cuda-cufft-1:10.2.89-2.fc32.x86_64
cuda-cufft-devel-1:10.2.89-2.fc32.x86_64
cuda-cupti-1:10.2.89-2.fc32.x86_64
cuda-cupti-devel-1:10.2.89-2.fc32.x86_64
cuda-curand-1:10.2.89-2.fc32.x86_64
cuda-curand-devel-1:10.2.89-2.fc32.x86_64
cuda-cusolver-1:10.2.89-2.fc32.x86_64
cuda-cusolver-devel-1:10.2.89-2.fc32.x86_64
cuda-cusparse-1:10.2.89-2.fc32.x86_64
cuda-cusparse-devel-1:10.2.89-2.fc32.x86_64
cuda-devel-1:10.2.89-2.fc32.x86_64
cuda-docs-1:10.2.89-2.fc32.noarch
cuda-extra-libs-1:10.2.89-2.fc32.x86_64
cuda-gcc-0:8.3.0-1.fc32.x86_64
cuda-gcc-c++-0:8.3.0-1.fc32.x86_64
cuda-gcc-gfortran-0:8.3.0-1.fc32.x86_64
cuda-libs-1:10.2.89-2.fc32.x86_64
cuda-npp-1:10.2.89-2.fc32.x86_64
cuda-npp-devel-1:10.2.89-2.fc32.x86_64
cuda-nsight-1:10.2.89-2.fc32.x86_64
cuda-nsight-compute-1:10.2.89-2.fc32.x86_64
cuda-nsight-systems-1:10.2.89-2.fc32.x86_64
cuda-nvgraph-1:10.2.89-2.fc32.x86_64
cuda-nvgraph-devel-1:10.2.89-2.fc32.x86_64
cuda-nvjpeg-1:10.2.89-2.fc32.x86_64
cuda-nvjpeg-devel-1:10.2.89-2.fc32.x86_64
cuda-nvml-devel-1:10.2.89-2.fc32.x86_64
cuda-nvrtc-1:10.2.89-2.fc32.x86_64
cuda-nvrtc-devel-1:10.2.89-2.fc32.x86_64
cuda-nvtx-1:10.2.89-2.fc32.x86_64
cuda-nvtx-devel-1:10.2.89-2.fc32.x86_64
cuda-nvvp-1:10.2.89-2.fc32.x86_64
cuda-samples-1:10.2.89-2.fc32.x86_64
dkms-nvidia-3:450.57-1.fc32.x86_64
kmod-nvidia-3:450.57-1.fc32.x86_64
nvenc-1:10.0.26-1.fc32.noarch
nvenc-samples-1:10.0.26-1.fc32.noarch
nvidia-driver-3:450.57-1.fc32.x86_64
nvidia-driver-NVML-3:450.57-1.fc32.i686
nvidia-driver-NVML-3:450.57-1.fc32.x86_64
nvidia-driver-NvFBCOpenGL-3:450.57-1.fc32.i686
nvidia-driver-NvFBCOpenGL-3:450.57-1.fc32.x86_64
nvidia-driver-cuda-3:450.57-1.fc32.x86_64
nvidia-driver-cuda-libs-3:450.57-1.fc32.i686
nvidia-driver-cuda-libs-3:450.57-1.fc32.x86_64
nvidia-driver-devel-3:450.57-1.fc32.i686
nvidia-driver-devel-3:450.57-1.fc32.x86_64
nvidia-driver-libs-3:450.57-1.fc32.i686
nvidia-driver-libs-3:450.57-1.fc32.x86_64
nvidia-kmod-common-3:450.57-1.fc32.noarch
nvidia-libXNVCtrl-3:450.57-1.fc32.x86_64
nvidia-libXNVCtrl-devel-3:450.57-1.fc32.x86_64
nvidia-modprobe-3:450.57-1.fc32.x86_64
nvidia-persistenced-3:450.57-1.fc32.x86_64
nvidia-settings-3:450.57-1.fc32.x86_64
nvidia-xconfig-3:450.57-1.fc32.x86_64

msmafra on 12 Aug 2020

There is massive artifacting in Death Stranding like rocks spawning in the air and such, though I don't get this issue. I already mentioned this issue here, but I will also post here just in case if other people don't see my other comment. I am also running the "next" build to even get Death Stranding running.

Some images of the artifacting:

Screenshot from 2020-08-14 19-27-08

I would also like to point out that if I launch Death Stranding via big picture mode, the artifacting issue almost completely fixes its self. From time to time it would artifact again, but that is easily solvable by restarting the game via big picture.

Video of the artifacting: https://youtu.be/UPjAUvgXQco?t=459

Dreamurrrr on 15 Aug 2020

👍3 👎1

It's made for Windows 10.....
Working on an emulator cuz I won't leave 7....
It came with my 2070 Super from New Egg

MrBiggreg on 15 Aug 2020

😕3

It's made for Windows 10.....
Working on an emulator cuz I won't leave 7....
It came with my 2070 Super from New Egg

Interesting.

jclc on 17 Aug 2020

It's made for Windows 10.....
Working on an emulator cuz I won't leave 7....
It came with my 2070 Super from New Egg

Try Linux if you are gonna stick to 7. You can run a Windows 10 bare-metal VM using KVM/QEMU via VFIO passthrough. A Windows 10 KVM preforms way better than your run-of-the-mill Windows 10 VM like Virtual Box or VMware,
(If you actually are going to try Linux, I can link you to a couple of great distros) @MrBiggreg.

Dreamurrrr on 17 Aug 2020

🚀1

https://www.youtube.com/watch?v=mi4B_nRHhSc Test on GTX 750 Ti

Asketi4 on 18 Aug 2020

👍1

https://www.youtube.com/watch?v=mi4B_nRHhSc Test on GTX 750 Ti

I am running on a GTX 1080 and I am running the same drivers as you though (standard not server). Are you running the "server" drivers or just the standard drivers, @Asketi4? Did you launch into big picture or no?

Dreamurrrr on 25 Aug 2020

https://www.youtube.com/watch?v=mi4B_nRHhSc Test on GTX 750 Ti

I am running on a GTX 1080 and I am running the same drivers as you though (standard not server). Are you running the "server" drivers or just the standard drivers, @Asketi4? Did you launch into big picture or no?

Standard drivers, installed in Linux Mint distribution. I launched the game without big picture

Asketi4 on 26 Aug 2020

Huh that's weird. I am running the same distro too...
I will post gameplay and log files for both when I launch the game regularly and in big picture.

Dreamurrrr on 26 Aug 2020

Are you running 7 or 10
On Tuesday, August 25, 2020, 03:08:51 PM EDT, David notifications@github.com wrote:

https://www.youtube.com/watch?v=mi4B_nRHhSc Test on GTX 750 Ti

I am running on a GTX 1080. I have the same drivers as you though. Are you running the "server" drivers or just the standard drivers, @Asketi4?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

MrBiggreg on 27 Aug 2020

😕1

OK I uploaded a video with both big picture and with a regular launch: https://youtu.be/UPjAUvgXQco?t=459

Start at the beginning for the big picture game play.

Dreamurrrr on 28 Aug 2020

Thanks man.....I always get this message can't load some .dll.....
I'll re download the game. I'm running a 2070 K) and 32 gigs of ram I read they required Winders 10 which I won't upgrade to period. I can control 7 but you loose all your rights and privacy with 10....New monitor....
Have a great Friday

MrBiggreg on 28 Aug 2020

Hello @MrBiggreg, friendly note that Proton is a compatibility layer which lets users run Windows games on Linux.

You're looking for help running this game with a system that doesn't meet the minimum requirements on a Windows system and that's out-of-scope for this project and issue tracker.

kisak-valve on 28 Aug 2020

❤5

With 5.10 next branch proton of steam it works. But very low FPS level. Like 20 outside with a 1080 Ti. How many god do you have ?

boistordu on 31 Aug 2020

@boistordu I get around 40 FPS with a 1080 on default settings @ 2.5k res. Check the video above that I posted for my gameplay.

Dreamurrrr on 1 Sep 2020

Well I don't know why I m so low then

boistordu on 2 Sep 2020

The game doesn't work for me. I tried 5.0.10rc4 and the latest gloriouseggroll proton. I'm using nvidia with the latest drivers, amd cpu, 16gb ram. The same log gets repeated infinitely: https://pastebin.com/PGpS6RjN only one CPU core is used at 100%. I'm also using the flatpak steam version.

ghost on 7 Sep 2020

Dont use the flatpak version maybe for a try

boistordu on 7 Sep 2020

The same thing happens on ubuntu 20.04, even with the previous driver.

ghost on 7 Sep 2020

The only way i can launch the game is with this custom build of proton using https://github.com/Frogging-Family/wine-tkg-git/tree/master/proton-tkg
(proton-tkg-git-5.16.r10.g0505562a)

First launch OK
freeze before the first cinematic
second launch ok
first cinematic loaded successfully
play mode after the cinecmatic ok
first delivery done
second cinematic when Sam meet BB. After a few second cinematic freeze and i cant load the auto-saved game anymore

Video Card:
    Driver:  X.Org AMD Radeon RX 5700 (NAVI10, DRM 3.37.0, 5.7.17-2-MANJARO, LLVM 10.0.1)
    Driver Version:  4.6 (Compatibility Profile) Mesa 20.1.6
    OpenGL Version: 4.6
    Desktop Color Depth: 24 bits per pixel
    Monitor Refresh Rate: 60 Hz

avenda on 7 Sep 2020

Using Proton next branch with latest AMDVLK makes the game playable for a few minutes then I get:
error.txt
Those crashes repeat randomly.
System info gist

lavadrop on 16 Sep 2020

The only way i can launch the game is with this custom build of proton using https://github.com/Frogging-Family/wine-tkg-git/tree/master/proton-tkg
(proton-tkg-git-5.16.r10.g0505562a)

* First launch OK

* freeze before the first cinematic

* second launch ok

* first cinematic loaded successfully

* play mode after the cinecmatic ok

* first delivery done

* second cinematic when Sam meet BB. After a few second cinematic freeze and i cant load the auto-saved game anymore

Video Card:
    Driver:  X.Org AMD Radeon RX 5700 (NAVI10, DRM 3.37.0, 5.7.17-2-MANJARO, LLVM 10.0.1)
    Driver Version:  4.6 (Compatibility Profile) Mesa 20.1.6
    OpenGL Version: 4.6
    Desktop Color Depth: 24 bits per pixel
    Monitor Refresh Rate: 60 Hz

Same exact issue with latest Glorious eggroll version of proton. Random freezes either in loading screens or cinematics. Sound remains in the background. as well.

OpenGL renderer string: AMD Radeon RX 5700 XT (NAVI10, DRM 3.35.0, 5.4.0-7642-generic, LLVM 10.0.1)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.2.0-rc3

turin331 on 20 Sep 2020

I updated my system with Debian Testing last week and tested Death Stranding again. The problem has lessened somewhat.

The game runs fine during normal gameplay except for the memory leak.
It still crashes when leaving Port Knot City towards Episode 3. Instead of crashing during the loading of the 4th animation (at the dock), it now crashes while playing the animation. Also the sound continues for a while. It looks like my system is still running instead of hanging. But I still performs a reboot afterwards to know for sure.

I run:
distribution: Debian Testing
mesa 20.1.7
Vulkan: AMDVLK: v-2020.Q3.5
Kernel: 5.8.7
Xorg: 7.7

jhaand on 22 Sep 2020

The only way i can launch the game is with this custom build of proton using https://github.com/Frogging-Family/wine-tkg-git/tree/master/proton-tkg
(proton-tkg-git-5.16.r10.g0505562a)
* First launch OK

* freeze before the first cinematic

* second launch ok

* first cinematic loaded successfully

* play mode after the cinecmatic ok

* first delivery done

* second cinematic when Sam meet BB. After a few second cinematic freeze and i cant load the auto-saved game anymore
Video Card:
    Driver:  X.Org AMD Radeon RX 5700 (NAVI10, DRM 3.37.0, 5.7.17-2-MANJARO, LLVM 10.0.1)
    Driver Version:  4.6 (Compatibility Profile) Mesa 20.1.6
    OpenGL Version: 4.6
    Desktop Color Depth: 24 bits per pixel
    Monitor Refresh Rate: 60 Hz
Same exact issue with latest Glorious eggroll version of proton. Random freezes either in loading screens or cinematics. Sound remains in the background. as well.
OpenGL renderer string: AMD Radeon RX 5700 XT (NAVI10, DRM 3.35.0, 5.4.0-7642-generic, LLVM 10.0.1)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.2.0-rc3

So For those interested after updating to the mainline 5.8.11 kernel and using the latest Glorious Eggroll proton version the crashes have stopped ann the game is not only playable but really smooth as well (on Pop 20.04). Just make sure you keep the "FidelityFX CAS" option off. It crashes the GPU completely after 10-20 seconds or so.

turin331 on 29 Sep 2020

So For those interested after updating to the mainline 5.8.11 kernel and using the latest Glorious Eggroll proton version the crashes have stopped ann the game is not only playable but really smooth as well (on Pop 20.04). Just make sure you keep the "FidelityFX CAS" option off. It crashes the GPU completely after 10-20 seconds or so.

Have you experienced the memory leak using this setup?

jclc on 1 Oct 2020

👍2

Hi,

Same kind of freeze as reported above. The game runs for a few minutes and then freezes.

My setup :
Debian stable with NVidia blob 450.66 (Kernel 4.19.146)
KDE
LOCALE FR
GeForce 2070 SUPER

Proton 5.13-1

jaubin on 18 Oct 2020

👍1

Same freeze for me with Nvidia 455.28 on kernel 5.9.1.

The log right after it freezes shows:

248:warn:vkd3d_create_vk_buffer_view: Failed to create Vulkan buffer view, vr -2.
248:warn:vkd3d_create_vk_buffer_view: Failed to create Vulkan buffer view, vr -2.
248:warn:vkd3d_create_vk_buffer_view: Failed to create Vulkan buffer view, vr -2.
248:warn:vkd3d_create_vk_buffer_view: Failed to create Vulkan buffer view, vr -2.
248:warn:vkd3d_create_vk_buffer_view: Failed to create Vulkan buffer view, vr -2.

EDIT: After reading vkd3d/libs/vkd3d/resource.c, it appears a call to vkCreateBufferView() is failing with code -2, which translates to VK_ERROR_OUT_OF_DEVICE_MEMORY according to include/vulkan/vulkan_core.h:111.

jakogut on 21 Oct 2020

👍2

https://github.com/HansKristian-Work/vkd3d-proton/pull/349 should fix this issue on NV. Same issue as Horizon Zero Dawn.

HansKristian-Work on 30 Oct 2020

👍5 ❤1

Hi,
I just faced another freeze with latest Proton release, 5.13-1 with latest dxvk.
Sadly did not have the logs. :-(
Using Debian 10 w/ NVidia blob 450.80
Le vendredi 6 novembre 2020 à 18:24:25 UTC+1, Jacob Millner notifications@github.com a écrit :

Just kidding, found the answer to my dumb question by reading the latest proton release: Updated to latest vkd3d-proton..

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

jaubin on 6 Nov 2020

Steam is targeting the wrong directory for cloud saves. According to cloud_logs.txt it's looking in
pfx/drive_c/users/steamuser/Local Settings/Application Data/KojimaProductions/DeathStranding/32457855
however the saves are actually located at pfx/drive_c/users/steamuser/AppData/Local/KojimaProductions/DeathStranding/32457855.

This does not appear to affect Windows. My saves from Windows were correctly uploaded to the cloud, they're just downloaded to the incorrect location in Proton/Linux.

(forgive my ignorance; is a comment the right place to put this or should I create a new issue?)

dwarfdigdeep on 11 Nov 2020

(forgive my ignorance; is a comment the right place to put this or should I create a new issue?)

I believe if it's game-specific, it's preferred to consolidate issues from 1 game into a singular location.

TheDiscordian on 11 Nov 2020

Is this a Proton/Steam problem or am I not allowed to use my game anymore?

Captura de tela de 2020-11-13 14-42-54

msmafra on 13 Nov 2020

Hi,
Same kind of error there after latest Proton update, 5.13-2 (my GPU is a RTX 2070 SUPER) :

jaubin on 13 Nov 2020

Hello @msmafra, @jaubin, can one of you please add PROTON_LOG=1 %command% to the game's launch options and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.) Also, please confirm what the newest Proton version that worked fine with the game and for @msmafra, that you're seeing a regression with Proton 5.13-2.

kisak-valve on 13 Nov 2020

My logs. I noticed this exception :
Unhandled exception: page fault on read access to 0x00000068 in 64-bit code (0x00007f13be3a3815).
Register dump:
rip:00007f13be3a3815 rsp:000000000051dde0 rbp:000000000051dfc0 eflags:00010246 ( R- -- I Z- -P- )
rax:0000000000000000 rbx:0000000000000001 rcx:0000000000000000 rdx:0000000000000000
rsi:0000000000000000 rdi:000000000007ffb4 r8:0000000000000000 r9:000000007f0e8f30 r10:0000000000000000
r11:00000000ffffffff r12:0000000000000000 r13:000000000001ffed r14:000000000051dfc0 r15:000000000051dfc0
Stack dump:
0x000000000051dde0: 0000000000000000 000000000051dfe0
0x000000000051ddf0: 0000000000000001 0000000000000000
0x000000000051de00: 0000000000000000 0000000000000001
0x000000000051de10: 000000000051dfe0 0000000000000000
0x000000000051de20: 0000000000000000 00007f13be3cdab3
0x000000000051de30: 0000000000000000 0000000001c3b4d0
0x000000000051de40: 000000000051df50 00007f13bc8d5946
0x000000000051de50: 00000000080cfcd0 0000000000000000
0x000000000051de60: 0000000000000000 0000000000000000
0x000000000051de70: 0000000000000000 0000000000000000
0x000000000051de80: 0000000000000000 0000000000000000
0x000000000051de90: 0000000000000000 0000000000000000

Note that with 5.13-1 I faced many freezes (about one every 10 minutes) but at least the game started. However the crash rate was far too high to make it playable.

PS : if this can help you can already rule out Vulkan. I tried with both WINED3D and Vulkan and the result is the same.

jaubin on 13 Nov 2020