Skip to content

Elite Dangerous (359320) #150

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
KewaiiGamer opened this issue Aug 22, 2018 · 620 comments
Open

Elite Dangerous (359320) #150

KewaiiGamer opened this issue Aug 22, 2018 · 620 comments
Labels
AMD RADV Possible driver issues with RADV Game compatibility - Unofficial Games not expected to work without issues Mesa drivers Possibly involves an issue with a Mesa video driver .NET Uses the .NET framework NVIDIA drivers Possibly involves an issue with the NVIDIA proprietary driver Regression Confirmed working on an older version of Proton

Comments

@KewaiiGamer
Copy link

KewaiiGamer commented Aug 22, 2018

I've just tried starting Elite Dangerous and it seems to not even display the game at all. It just starts and 1 second later it shuts down

I don't know how would I debug it so I would be glad if someone could instruct me on how to enable verbose for Proton Games

OS: Ubuntu 18.04
CPU: AMD Ryzen 5 1600X
GPU: Nvidia GeForce 1050 Ti 3GB
Driver Version: Nvidia Driver 396

@kisak-valve kisak-valve added the Game compatibility - Unofficial Games not expected to work without issues label Aug 22, 2018
@simon50keda
Copy link

simon50keda commented Aug 22, 2018

  1. Navigate to <steam>/steamapps/common/Proton 3.7
  2. Rename user_settings.sample.py to user_settings.py and try to run the game again.
  3. Now go to your home directory and you will find steam-<appid>.log file in there.

@bakcxoj
Copy link

bakcxoj commented Aug 22, 2018

At the bottom of the log, I get this:

pid 30513 != 30512, skipping destruction (fork without exec?)

I think the terminal is asking a question and expecting a response. I tried running Steam in a terminal, but it didn't render this. I'm also not sure how to directly run the game itself in a terminal.

Somehow, I think I just need to answer this question. Adding -y to the launch options doesn't help.

@kisak-valve kisak-valve changed the title [BUG] Elite Dangerous doesn't start [BUG] Elite Dangerous doesn't start (359320) Aug 23, 2018
@Faeranne
Copy link

Faeranne commented Aug 24, 2018

This simply means that the game didn't fork, spawn a new process to continue, so wine/steam didn't need to kill the child process. This almost always shows up once a game using proton closes, successful or not. A sort of rhetorical question for anyone reading the logs.

@Faeranne
Copy link

also, Elite: Dangerous still doesn't correctly run inside wine environments. It's mostly there, but so-far only one of the tutorials has actually been run using wine. Unfortunately, it appears that the launcher for Elite is still not successfully running, which is what is crashing. In general, if a game doesn't launch with Steam Play enabled, there is a good chance it just doesn't work in a wine environment yet.

@diraven
Copy link

diraven commented Aug 25, 2018

I tried it with proton and lots of standalone wine setups with and without dxvk. None have worked, sadly... Hopefully, this will change some day.

@mirh
Copy link

mirh commented Aug 28, 2018

@unlimitedbacon
Copy link

Here is a complete log file.
steam-359320.log

Running Proton 3.7-5 Beta.
Steam System Info

@physios
Copy link

physios commented Sep 1, 2018

Probably the most important part of that log, idk just trying to be useful

`15872.052:0008:0009:trace:module:load_dll Loaded module L"Z:\home\neo\.local\share\Steam\SteamApps\common\Elite Dangerous\EDLaunch.exe" (native) at 0x400000

15872.052:0008:0009:err:module:LdrInitializeThunk Main exe initialization for L"Z:\home\neo\.local\share\Steam\SteamApps\common\Elite Dangerous\EDLaunch.exe" failed, status c0000017

15872.054:000c:0026:trace:module:MODULE_InitDLL (0x7feca1c40000 L"rpcrt4.dll",THREAD_ATTACH,(nil)) - CALL

15872.054:000c:0026:trace:module:MODULE_InitDLL (0x7feca1c40000,THREAD_ATTACH,(nil)) - RETURN 1

15872.054:000c:0027:trace:module:MODULE_InitDLL (0x7feca1c40000 L"rpcrt4.dll",THREAD_ATTACH,(nil)) - CALL

15872.054:000c:0027:trace:module:MODULE_InitDLL (0x7feca1c40000,THREAD_ATTACH,(nil)) - RETURN 1

15872.071:000c:0025:trace:module:MODULE_InitDLL (0x7feca1c40000 L"rpcrt4.dll",THREAD_ATTACH,(nil)) - CALL

15872.071:000c:0025:trace:module:MODULE_InitDLL (0x7feca1c40000,THREAD_ATTACH,(nil)) - RETURN 1

15872.072:000c:0028:trace:module:MODULE_InitDLL (0x7feca1c40000 L"rpcrt4.dll",THREAD_ATTACH,(nil)) - CALL

15872.072:000c:0028:trace:module:MODULE_InitDLL (0x7feca1c40000,THREAD_ATTACH,(nil)) - RETURN 1

15872.072:0018:001c:trace:module:LdrShutdownThread ()`

@ghost ghost mentioned this issue Sep 26, 2018
@fls2018
Copy link

fls2018 commented Oct 19, 2018

I'd like to add some update on this, with latest Proton versions dotnet installing is fixed so using winetricks/protontricks with a version of wine where dotnet40 doesn't fail (in my case I got 3.17 staging as my system wine) you can install dotnet40 into the Proton prefix.

i.e.
1/ cd to the 359320 compatdata folder

2/ WINEPREFIX=$PWD/pfx winetricks corefonts dotnet40 vcrun2012 quartz

3/ WINEPREFIX=$PWD/pfx winecfg - then set mode back to win7

After doing that launcher should open,but that's only the first half of the battle. There are a number of issues, first is openvr_api_dxvk.dll prevents the main game from displaying the splash screen. Second is a problem previously a roadblock in wine where the CRC check fails making the main game unplayable. Third is another new issue where even the previously playable combat demo would freeze despite working perfectly in standard wine.

@fls2018
Copy link

fls2018 commented Oct 22, 2018

Update: Game is now working in wine but not proton, here's my compatibility report.

Compatibility Report

  • Name of the game with compatibility issues: Elite Dangerous
  • Steam AppID of the game: 359320

System Information

  • GPU: GTX 1070
  • Driver/LLVM version: Nvidia 396.54.09
  • Kernel version: 4.18
  • Proton version: 3.16-3

steam-359320.log

Symptoms

Game now works in Wine staging 3.18 with DXVK using a simple registry fix listed here: https://forums.frontier.co.uk/showthread.php/366894-How-to-install-ED-on-Linux-using-Wine-EXPERIMENTAL-NOT-OFFICIALLY-SUPPORTED?p=7082698&viewfull=1#post7082698

However game still freezes in Proton even after applying the same fixes, the login issue has been resolved but something "Proton specific" causes the game to freeze a minute after starting up.

Here's it running under Wine staging: https://youtu.be/JcDY4WFENug

Reproduction

Similar to the steps in this video: https://youtu.be/jG7TUOXZhng

1/ winetricks corefonts dotnet40 vcrun2012 quartz into the 359320 pfx.

2/ regedit the 359320 pfx and do the following to match the machineGuid of both keys:

Navigate to HKLM/Software/Microsoft/Cryptography
Copy Value
Navigate to HKLM/Software/Wow6432Node/Microsoft/Cryptography
Paste Value

3/ winecfg and set mode to Win7

The above will make the launcher and game start in Steam/Proton and will also fix the authentication error, however game will freeze in about a minute (sometimes sooner). This doesn't happen under Wine staging therefore issue is to do with Proton.

Also @byte1024 post from other thread:

From the log

159005.320:0008:0034:trace:module:LdrUnloadDll (L"rsaenh.dll") - START
159005.320:0008:0034:trace:module:MODULE_DecRefCount (L"rsaenh.dll") ldr.LoadCount: 2
159005.320:0008:0034:trace:module:LdrUnloadDll END
159005.320:0008:0034:fixme:ole:Context_CC_ContextCallback (0x3aadd80/0x3aadd84)->(0x791c8272, 0x30ecc38, {d7174f82-36b8-4aa8-800a-e963ab2dfab9}, 2, (nil))
159005.320:0008:0034:fixme:ole:Context_CC_ContextCallback (0x3aadd80/0x3aadd84)->(0x791c8272, 0x30ecbc4, {d7174f82-36b8-4aa8-800a-e963ab2dfab9}, 2, (nil))
159005.320:0008:0034:fixme:ole:Context_CC_ContextCallback (0x3aadd80/0x3aadd84)->(0x791c8272, 0x30ecbc4, {d7174f82-36b8-4aa8-800a-e963ab2dfab9}, 2, (nil))
159005.320:0008:0034:trace:seh:raise_exception code=c0000005 flags=0 addr=0x15de5665 ip=15de5665 tid=0034
159005.320:0008:0034:trace:seh:raise_exception  info[0]=00000000
159005.320:0008:0034:trace:seh:raise_exception  info[1]=00000000
159005.320:0008:0034:trace:seh:raise_exception  eax=00000000 ebx=000000d5 ecx=030eca20 edx=1d4d94a0 esi=03eda098 edi=03ab3a1c
159005.320:0008:0034:trace:seh:raise_exception  ebp=030ecae8 esp=030eca80 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010206

rsaenh.dll is Microsoft Enhanced Cryptographic Provider. Must have to do with the registry change. Not sure why it works differently with Wine VS Proton though.

Wine 3.18 does have two changes however, so not sure if that makes a difference here:

  rsaenh: Move PKCS1 padding and unpadding functions.
  rsaenh: Implement RSA OAEP.

https://www.winehq.org/announce/3.18

Would have to see where the exception is going to.

Wonder if the dll provided with Wine would solve it with Proton?

I've tried this and it doesn't work, it seems Proton itself uses a builtin rsaenh library and doesn't launch when you try to use a native version.

Also I'm not sure Cryptography is the issue anymore as this freeze occurs even on the combat demo which was working perfectly fine in wine before the registry fix.

@fls2018
Copy link

fls2018 commented Oct 26, 2018

Another update: Thanks to RedMcG again on the frontier forums I have now got into the game in Steam Proton... BUT using anymore than one CPU core will freeze the game.

screenshot from 2018-10-26 13-35-38

Simply follow the winetricks, regedit & winecfg steps in the post above, to get into the game without it crashing "taskset -c 0 %command%" needs to be set in the launch options. Obviously not very playable but it works.

Bu the question is why using more than one thread cause issues with this game in Proton yet not with Wine Staging?

@mirh
Copy link

mirh commented Oct 26, 2018

The esync patch set is probably the first diff that comes to mind..

@fls2018
Copy link

fls2018 commented Oct 26, 2018

The esync patch set is probably the first diff that comes to mind..

I'be already tried PROTON_NO_ESYNC=1 %command% , tried older versions of Proton too no difference. Tried WineD3D instead of DXVK still freezes up.

Maybe some implementation Wine has which Proton's missing?

@LudusLight
Copy link

I'm having trouble with your solution. I feel like I could be missing something obvious, considering I'm new at troubleshooting Proton, but perhaps this may come in useful anyways.

I tried the following on two distributions (Solus 3.9 & Ubuntu 18.04):

  1. Run winetricks corefonts dotnet40 vcrun2012 quartz in the pfx
  2. regedit the pfx, copying the key from /HKEY_LOCAL_MACHINE/Software/Microsoft/Cryptography/ to /HKEY_LOCAL_MACHINE/Software/Wow6432Node/Microsoft/Cryptography
  3. Set the mode to Windows 7 in winecfg within the pfx
  4. Set the launch options to taskset -c 0 %command% (as well as trying without)

After doing that, launching the game has no effect. There is no launcher, and no game. Here are the log files:

steam-359320-ubuntu.log
steam-359320-solus.log

@ghost
Copy link

ghost commented Oct 27, 2018

I'm having trouble with your solution. I feel like I could be missing something obvious, considering I'm new at troubleshooting Proton, but perhaps this may come in useful anyways.

I tried the following on two distributions (Solus 3.9 & Ubuntu 18.04):

1. Run `winetricks corefonts dotnet40 vcrun2012 quartz` in the pfx

2. `regedit` the pfx, copying the key from `/HKEY_LOCAL_MACHINE/Software/Microsoft/Cryptography/` to `/HKEY_LOCAL_MACHINE/Software/Wow6432Node/Microsoft/Cryptography`

3. Set the mode to `Windows 7` in `winecfg` within the pfx

4. Set the launch options to `taskset -c 0 %command%` (as well as trying without)

After doing that, launching the game has no effect. There is no launcher, and no game. Here are the log files:

steam-359320-ubuntu.log
steam-359320-solus.log

At least with Ubuntu you're getting:
13053.551:0008:0009:err:module:LdrInitializeThunk Main exe initialization for L"Z:\\media\\bigboy\\SteamLibrary\\steamapps\\common\\Elite Dangerous\\EDLaunch.exe" failed, status c0000017

I'm not sure why though. The log doesn't have anything immediately noticeable to me. Comparing it to Solus is the only difference I notice:

"19373.147:0008:0009:trace:module:load_dll Loaded module L"Z:\\home\\light\\.local\\share\\Steam\\steamapps\\common\\Elite Dangerous\\EDLaunch.exe" (native) at 0x400000" ... continues on ...

Perhaps bad exe on Ubuntu or the storage location doesn't work well? If there's something else in the log, I don't feel like trying to find it =)

With Solus:
19373.233:0008:0009:err:mscoree:CLRRuntimeInfo_GetRuntimeHost Wine Mono is not installed
So that's self explanatory.

@fls2018
Copy link

fls2018 commented Oct 27, 2018

I'm having trouble with your solution. I feel like I could be missing something obvious, considering I'm new at troubleshooting Proton, but perhaps this may come in useful anyways.

I tried the following on two distributions (Solus 3.9 & Ubuntu 18.04):

  1. Run winetricks corefonts dotnet40 vcrun2012 quartz in the pfx
  2. regedit the pfx, copying the key from /HKEY_LOCAL_MACHINE/Software/Microsoft/Cryptography/ to /HKEY_LOCAL_MACHINE/Software/Wow6432Node/Microsoft/Cryptography
  3. Set the mode to Windows 7 in winecfg within the pfx
  4. Set the launch options to taskset -c 0 %command% (as well as trying without)

After doing that, launching the game has no effect. There is no launcher, and no game. Here are the log files:

steam-359320-ubuntu.log
steam-359320-solus.log

I should be clearer as you don't appear to have mscoree listed in your log.

First thing needed is having at least wine staging 3.17 or higher installed on your system to install dotnet40, along with installing winetricks.

Assuming you have steam installed in the default place open terminal and type (replacing yourusernamehere with yours):

WINEPREFIX=/home/yourusernamehere/.steam/steam/steamapps/compatdata/359320/pfx winetricks corefonts dotnet40 vcrun2012 quartz

Install those clicking on the accept when installers pop up then:

WINEPREFIX=/home/yourusernamehere/.steam/steam/steamapps/compatdata/359320/pfx regedit

Edit the keys as stated above then:

WINEPREFIX=/home/yourusernamehere/.steam/steam/steamapps/compatdata/359320/pfx winecfg

Change to win7.

All done the launcher should work, you might get rundll32.exe errors but just continue on.

@LudusLight
Copy link

I'm having trouble with your solution. I feel like I could be missing something obvious, considering I'm new at troubleshooting Proton, but perhaps this may come in useful anyways.
I tried the following on two distributions (Solus 3.9 & Ubuntu 18.04):

  1. Run winetricks corefonts dotnet40 vcrun2012 quartz in the pfx
  2. regedit the pfx, copying the key from /HKEY_LOCAL_MACHINE/Software/Microsoft/Cryptography/ to /HKEY_LOCAL_MACHINE/Software/Wow6432Node/Microsoft/Cryptography
  3. Set the mode to Windows 7 in winecfg within the pfx
  4. Set the launch options to taskset -c 0 %command% (as well as trying without)

After doing that, launching the game has no effect. There is no launcher, and no game. Here are the log files:
steam-359320-ubuntu.log
steam-359320-solus.log

I should be clearer as you don't appear to have mscoree listed in your log.

First thing needed is having at least wine staging 3.17 or higher installed on your system to install dotnet40, along with installing winetricks.

Assuming you have steam installed in the default place open terminal and type (replacing yourusernamehere with yours):

WINEPREFIX=/home/yourusernamehere/.steam/steam/steamapps/compatdata/359320/pfx winetricks corefonts dotnet40 vcrun2012 quartz

Install those clicking on the accept when installers pop up then:

WINEPREFIX=/home/yourusernamehere/.steam/steam/steamapps/compatdata/359320/pfx regedit

Edit the keys as stated above then:

WINEPREFIX=/home/yourusernamehere/.steam/steam/steamapps/compatdata/359320/pfx winecfg

Change to win7.

All done the launcher should work, you might get rundll32.exe errors but just continue on.

This was a full fix. Thank you.

@FurretUber
Copy link

After using all the winetricks and changing the values in regedit as proposed here, the game crashes in the shader loading stage. When I'm lucky I can see the shaders loading until 10% and then the game crashes. I tried both with DXVK and with Wine D3D11, tried setting video memory in regedit to 128 MB and to 2048 MB but had no luck.

The errors using DXVK and Wine D3D11 are different but seem related:

Wine D3D11:

2851.011:00ab:00c8:err:seh:call_stack_handlers invalid frame 58a3c478 (0x58b02000-0x58c00000)
2851.011:00ab:00c8:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception.

DXVK

2169.251:00aa:00d3:err:seh:setup_exception stack overflow 3760 bytes in thread 00d3 eip 00007f85128ef532 esp 0000000058ed0760 stack 0x58ed0000-0x58ed2000-0x58fd0000

The complete logs:

steam-359320-d3d11.log
steam-359320-dxvk.log

On Windows, both host and iGVT-g guest, shader loading takes 1 or 2 seconds.

System specifications.

@amalon
Copy link

amalon commented Nov 5, 2018

Wine D3D11:

2851.011:00ab:00c8:err:seh:call_stack_handlers invalid frame 58a3c478 (0x58b02000-0x58c00000)
2851.011:00ab:00c8:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception.

DXVK

2169.251:00aa:00d3:err:seh:setup_exception stack overflow 3760 bytes in thread 00d3 eip 00007f85128ef532 esp 0000000058ed0760 stack 0x58ed0000-0x58ed2000-0x58fd0000

I get the same thing with Haswell desktop integrated graphics:

cpuinfo:
model name : Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz

vulkaninfo:
apiVersion = 0x401050 (1.1.80)
driverVersion = 75505668 (0x4802004)
vendorID = 0x8086
deviceID = 0x0412
deviceType = INTEGRATED_GPU
deviceName = Intel(R) Haswell Desktop

glxinfo:
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) Haswell Desktop (0x412)
Version: 18.2.4

I had put it down to being Intel graphics specific (there's a warning about the vulkan driver being incomplete), which you also appear to be using.

@FurretUber
Copy link

I don't think it's Vulkan, more specifically Intel ANV, the problem. If it was, the bug that happened when using Wine D3D11 translation to OpenGL would be different. Notice how the addresses from the error messages are very close, it seems to be some common code between i965 and ANV or even the i915 kernel driver.

@redmcg
Copy link

redmcg commented Nov 5, 2018

But the question is why using more than one thread cause issues with this game in Proton yet not with Wine Staging?

I looked in to that and found the answer lies with a single patch in wine-staging:
https://github.com/wine-staging/wine-staging/blob/master/patches/ntdll-futex-condition-var/0001-ntdll-Add-a-futex-based-condition-variable-implement.patch

I patched Proton 3.16-4 Beta with this patch and now it runs fine without needing any tweaks to the launch options.

I just created a fork which, in addition to the above, fixes a few other things with ED in Proton 3.16:

  • key-bindings (and presets)
  • intro videos (winetricks quartz not needed)
  • CRC Error (no work-around required - it runs launcher with wine64)

I'm happy to share the binaries if anyone knows a decent place to upload them. I haven't tested them on another machine yet, but I compiled against the Steam Runtime - so I think they should work on distros other than Ubuntu 18.04 (on which I compiled).

@agates
Copy link

agates commented Nov 5, 2018

In case anyone comes here with "preparing planet generation system" issues on Horizons, there are some AMD-specific DXVK issues along with some work arounds. Check out doitsujin/dxvk#36.

@Rabcor
Copy link

Rabcor commented Nov 6, 2018

This game apparently can run pretty well but it requires wine 3.19 staging. Requires dotnet452 vcrun2012 to run correctly.

https://www.youtube.com/watch?v=XsirDkR6ZQw

@redmcg why don't you create a pull request for proton's wine with that patch?

@redmcg
Copy link

redmcg commented Nov 6, 2018

@redmcg why don't you create a pull request for proton's wine with that patch?

I have now (see ValveSoftware/wine#33) - but taking a look at the ones that are there I don't see much success (after all - these patches are for one game tested on a single machine).

But I do think Valve cherry-pick the ones that interest them from upstream - so this may bring the individual patches some attention.

@Rabcor
Copy link

Rabcor commented Nov 6, 2018

@redmcg why don't you create a pull request for proton's wine with that patch?

I have now (see ValveSoftware/wine#33) - but taking a look at the ones that are there I don't see much success (after all - these patches are for one game tested on a single machine).

But I do think Valve cherry-pick the ones that interest them from upstream - so this may bring the individual patches some attention.

This patch was upstream in wine staging right? They'll probably apply it then, if it was good enough for wine-staging, it's probably good enough for proton.

@redmcg
Copy link

redmcg commented Nov 7, 2018

I've created a Git 'release' that includes a tarball with the binaries from my fork. It's compiled on Ubuntu 18.04.1 but against the steam runtime - so I think it should be fine on other distros. I'd be interested to hear how it goes (on other machines and potentially with other games). You can find instructions and the release here:
https://github.com/redmcg/wine/releases/tag/ED_Proton_3.16-4_Beta

@alexytomi
Copy link

Check logs/Client.log, looks like it is the log of the launcher.

Here's the log. I didn't find anything of use. I edited it a bit for my own privacy. Client.log

I fixed my issue by installing arch linux EndeavorOS and using that instead. Oh my god is it so much easier.

@alexzk1
Copy link

alexzk1 commented Jan 13, 2025

Check logs/Client.log, looks like it is the log of the launcher.

Here's the log. I didn't find anything of use. I edited it a bit for my own privacy. Client.log

I fixed my issue by installing arch linux EndeavorOS and using that instead. Oh my god is it so much easier.

Welcome to the "Arch" club :D
P.S. I use pure Arch + LxQt, because this DE is binary compiled. I have 400Mb RAM used on boot, which is important for the gaming.

@Maelstromeous
Copy link

It doesn't happen on every launch, but happens fairly often, even in the same day when there were no game updates. It's annoying and tedious, and is presumably putting unnecessary wear on our SSDs.

@foresto It's highly recommended you turn off shader caching in the steam settings.

@foresto
Copy link

foresto commented Jan 15, 2025

@foresto It's highly recommended you turn off shader caching in the steam settings.

Do you mean shader pre-caching, in the global Downloads section?

Recommended by whom?

Thanks for the suggestion. I'll give it a try as a workaround, but I think this still ought to be fixed, since the problem is only affecting one game and it would be nice to take advantage of shader pre-caching in other games.

@Maelstromeous
Copy link

Maelstromeous commented Jan 15, 2025

Do you mean shader pre-caching, in the global Downloads section?

Yes.

It affects many games, not just Elite. I forgot who recommended it to me exactly, a YouTuber if memory serves, but modern hardware compiles the shaders so quickly pre-caching is just not needed, it uses a ton of space and it makes you wait to play the game.

@kakra
Copy link
Contributor

kakra commented Jan 15, 2025

but modern hardware compiles the shaders so quickly pre-caching is just not needed

I don't think this is true. But modern drivers provide a way to handle shaders differently for caching, so DXVK and vkd3d can more efficiently cache the shaders by themselves instead of relying on a collect/distribute/replay system like fossilize to pre-compile shaders. Pre-compiling is still able to prevent stutters happening the first time.

For me, ED does only precompile shaders if the drivers or the kernel changed. If it does it more often for you, and also creates more than twice the amount of shader cache than expected, your cache may be broken an you should delete it. Stop Steam completely, then:

rm -Rf ~/.steam/steam/steamapps/shadercache/359320 # <- this is the Steam ID of Elite Dangerous

Then start Steam again, check for game downloads, it should download the shader files, and re-compile those once when you start the game. It may do another round of pre-compiling after the next start of the game but then it should not happen again until you update your drivers or kernel.

For me, this directory holds 2.5GB of shader cache data:

# du -sh ~/.steam/steam/steamapps/shadercache/359320/*
20K     .steam/steam/steamapps/shadercache/359320/DXVK_state_cache
0       .steam/steam/steamapps/shadercache/359320/fozmediav1
1,3G    .steam/steam/steamapps/shadercache/359320/fozpipelinesv6
3,8M    .steam/steam/steamapps/shadercache/359320/mesa_shader_cache_sf
1,3G    .steam/steam/steamapps/shadercache/359320/nvidiav1
0       .steam/steam/steamapps/shadercache/359320/pipeline_cache
0       .steam/steam/steamapps/shadercache/359320/steam_shader_cache

fozpipelinesv6 is the source cache crowd-downloaded, nvidiav1 is the driver cache with the compiled shaders. Both directories should have about the same size. With an AMD GPU, you probably find the driver cache in one of the mesa* directories. If you turn off shader pre-compiling, you're most likely finding more data in DXVK_state_cache if I understand correctly.

You can purge old stale shader cache data with this command (not touched in the last 180 days):

find ~/.steam/steam/steamapps/shadercache/* -type f -mtime +180 -delete

If you want to preview the list first, drop -delete from the command. This probably also fixes some problems people have with this cache.

@kisak-valve
Copy link
Member

kisak-valve commented Jan 29, 2025

Elite Dangerous crashes (again) on Planetary Generation (359320)

Issue transferred from #8427.
@AZRAEL-III posted on 2025-01-29T20:30:21:

System Information

  • Operating System : Linux Mint 22.1 (Xia)
  • GPU: Acer Bifrost Intel Arc A750
  • Video driver version: Mesa 24.3.1 - kisak-mesa PPA
  • Kernel version: 6.12.11-x64v3-xanmod1
  • Link to full system information report as System Infos:
  • Proton version: Every version of Proton

I confirm:

  • that I have checked whether there are updates for my system available.

steam-359320.log.tar.gz

Symptoms

The game immediately freezes or crashes at the "Planetary Generation" screen.

Reproduction

link to the Steam system infos

  1. Launch the game
  2. In the dedicated Frontier launcher, launch the game
  3. After the "Elite Dangerous logo" and animation, the game will do the cache
  4. The game will attempt to do the "Planetary Generation System" screen and it will freeze or crash immediately (it's random, it freezes or crashes but the problem is the same, the game does not load)

I tested with Proton 6.x and older, the game WILL load but within 3 minutes into the game, it will freeze my entire X session, i need to switch tty to kill the process.
I already tried the Epic Games version (as i have a legacy version of elite dangerous that's obsolete since almost 3 years and it works)

@kisak-valve
Copy link
Member

Hello @AZRAEL-III, warn:seh:handle_syscall_fault backtrace: --- Exception 0xc0000005 at 0x7acb8663ccd9: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/vulkan/00/libvulkan_intel.so + 0x63ccd9 in your proton log hints towards a mesa/ANV driver issue. https://gitlab.freedesktop.org/mesa/mesa/-/issues/9489 looks like the same issue tracked on the video driver's side.

@AZRAEL-III
Copy link

AZRAEL-III commented Jan 29, 2025

Hello @AZRAEL-III, warn:seh:handle_syscall_fault backtrace: --- Exception 0xc0000005 at 0x7acb8663ccd9: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/vulkan/00/libvulkan_intel.so + 0x63ccd9 in your proton log hints towards a mesa/ANV driver issue. https://gitlab.freedesktop.org/mesa/mesa/-/issues/9489 looks like the same issue tracked on the video driver's side.

I know, but the issue is still here, i tried, i mean i TRIED very hard (for the last 3 months) to make the game works, and it doesn't.

So how can i solve this mesa issue, because this is the same issue for EVERY user on protondb who uses an Arc GPU on Elite Dangerous

@kakra
Copy link
Contributor

kakra commented May 4, 2025

With Proton 10 (and its experimental branch), my joysticks are no longer recognized. The games binding error log file states:

Failed to find GUID for device: 231D0200
Failed to find GUID for device: 231D0201

Switching back to Proton 9 fixes this.

I'm not sure if this is an artifact from earlier version of Proton which cached the joysticks as gamepad in system.reg but a switch to Proton 10 should clean that up as it works with Proton 9. I'm still seeing entries like this in system.reg which point to WINEXINPUT instead of WINEHID:

[System\\CurrentControlSet\\Enum\\WINEXINPUT\\VID_231D&PID_0201&IG_00\\273&03004FDD1D2300000102000011010000.0&0&0&1] 1746387592
#time=1dbbd2c4e2093d2
"Class"="HIDClass"
"ClassGUID"="{745A17A0-74D3-11D0-B6FE-00A0C90F57DA}"
"CompatibleIds"=str(7):"WINEBUS\\WINE_COMP_HID\0"
"ConfigFlags"=dword:00000000
"DeviceDesc"="Wine HID compatible device"
"Driver"="{745A17A0-74D3-11D0-B6FE-00A0C90F57DA}\\0011"
"HardwareID"=str(7):"WINEXINPUT\\VID_231D&PID_0201&IG_00\0"
"Service"="winehid"

[System\\CurrentControlSet\\Enum\\WINEXINPUT\\VID_231D&PID_0201&IG_00\\273&03004FDD1D2300000102000011010000.0&0&0&1\\Device Parameters] 1746387592
#time=1dbbd2c4e1fd4e2

[System\\CurrentControlSet\\Enum\\WINEXINPUT\\VID_231D&PID_0201&XI_00\\273&03004FDD1D2300000102000011010000.0&0&0&1] 1746387592
#time=1dbbd2c4e1da7ee
"Class"="HIDClass"
"ClassGUID"="{745A17A0-74D3-11D0-B6FE-00A0C90F57DA}"
"CompatibleIds"=str(7):"WINEBUS\\WINE_COMP_HID\0"
"ConfigFlags"=dword:00000000
"DeviceDesc"="Wine HID compatible device"
"Driver"="{745A17A0-74D3-11D0-B6FE-00A0C90F57DA}\\0009"
"HardwareID"=str(7):"WINEXINPUT\\VID_231D&PID_0201&XI_00\0"
"Service"="winehid"

[System\\CurrentControlSet\\Enum\\WINEXINPUT\\VID_231D&PID_0201&XI_00\\273&03004FDD1D2300000102000011010000.0&0&0&1\\Device Parameters] 1746387592
#time=1dbbd2c4e1cc82e

I've created a backup copy of system.reg and purged all sections which referenced VID_231D. Then I started the game with Proton 9 again, and the XINPUT references didn't show up again. Now, the game also properly detects the joysticks with Proton 10.

So there's clearly a problem with old stray xinput references in system.reg which now seem to be preferred with Proton 10.

I'm running with PROTON_ENABLE_HIDRAW=0x044F/0xB10A,0x044F/0xB687,0x231D/0x0200,0x231D/0x0201 to specifically enable the hidraw driver for these devices because with SDL, they would be detected as gamepads. I'm not sure if this is still needed, probably not...

The patch for properly handling those and similar joysticks has been added here:
ValveSoftware/wine#197

@rbernon Do you want to take a look if you are still working on that subsystem? I can send the backup copy of the "broken" system.reg.

According to ValveSoftware/wine@c5a726e, the proper checks are still in place.

Update: Cleaning system.reg is a one-time fix only. After starting the game again, the joysticks are not detected again - but the xinput references in system.reg didn't appear either. Something seems very broken here...

@kakra
Copy link
Contributor

kakra commented May 4, 2025

So how can i solve this mesa issue, because this is the same issue for EVERY user on protondb who uses an Arc GPU on Elite Dangerous

@AZRAEL-III From a friend, I know that the game also crashed on Arc with Windows. Lately, it seems to be fixed there (although, the performance is exceptionally bad sometimes, especially when entering the mail slot or during various effects while fighting).

Also, I've seen this game (and others) crash, if DXVK also sees the iGPU, so I'm using DXVK_FILTER_DEVICE_NAME="NVIDIA".

@kakra
Copy link
Contributor

kakra commented May 4, 2025

With Proton 10, mangohud is showing on the launcher while it initializes.

@rbernon
Copy link
Collaborator

rbernon commented May 5, 2025

@kakra Could you attach a log with PROTON_LOG=+hid,+setupapi,+plugplay log with Proton 10 with the old prefix where it doesn't work, and another one with Proton 9 with the same prefix where it works?

@kakra
Copy link
Contributor

kakra commented May 5, 2025

@rbernon Okay, now things become strange: it was hard to reproduce today. I've created a log at each testing step. In case order matters, I've prefixed each log file with a number. Here's what I did:

  1. It worked with Proton 9 yesterday, so I started the game to verify it is working: 00_steam-359320.proton-9.clean-systemreg.working.log.gz
  2. I switched to Proton 10 which reliably did not work yesterday, the HOTAS wasn't detected and showed the error "GUID not found" in the game binding logs, but it worked today: 01_steam-359320.proton-10.clean-systemreg.working.log.gz
  3. I now tried again with the backup copy of system.reg which still contains the xinput references, and - as expected - it works with Proton 9: 02_steam-359320.proton-9.xinput-systemreg.working.log.gz
  4. So now I switched to Proton 10 which originally caused the problems yesterday, and to my surprise, it just worked: 03_steam-359320.proton-10.xinput-systemreg.working.log.gz

The system hasn't been rebooted since yesterday. So I wondered what has been different yesterday. Actually, there's a difference: I'm playing Elite Dangerous with opentrack to track my head movement via webcam and reflect that into the game. That's immersive and a great enhancement, btw...

Opentrack works by detecting EDLauncher.exe running (so the prefix has been launched). It then prepares to call the proper Proton version (configured within opentrack which I did correctly), and injects a driver service into the running prefix by calling wine ... with a small PE helper binary, launching it as part of the same prefix (it sets up the environment and calls the wine binary of the corresponding Proton installation).

Now I can reproduce the problem!

  1. With opentrack running, it starts the tracker right after EDLauncher.exe started, my HOTAS does not work in the game: 04_steam-359320.proton-10.clean-systemreg.broken.with_opentrack.log.gz
  2. So I tried again, quit the game and launcher, opentrack automatically stopped. I tried again, without closing opentrack, nothing else changed, and now it does work again: 05_steam-359320.proton-10.clean-systemreg.working.with_opentrack.log.gz

I repeated step 6 a few times and can confirm it is now working.

Confused? Yes, me too. :-D

So this feels like a race condition. I'm not even sure if opentrack is causing this (as I'm not sure if it was started during all the tests yesterday). Maybe opentrack starts a bit too early and causes race conditions in wine booting? It watches PIDs and checks for the cmdline name EDLaunch.exe. So if that appears very early, it may start another wine process while Proton is still booting the prefix?

Maybe something is initializing/loading slower right after launching with another Proton version? Maybe that's causing a race?

Or has there been an update to Proton 10 Experimental since yesterday?

But this is pure speculation. Whatever it is, it worked reliably with Proton 9 throughout multiple minor versions...

I just tried again, my HOTAS still works, and I actually launched into a game session: head tracking is also working.

There was another issue yesterday: Sometimes, head tracking with Proton 10 would not work in the game (ignoring the HOTAS problem). But it reliably worked with Proton 9 (including my HOTAS). I did multiple rounds of testing yesterday, about 2 hours probably, switching back and forth different combinations of system.reg and Proton versions (9, 10, and 10 Experimental).

Thanks for investigating. I'll let you know if it happens again and stick to Proton 10 Experimental for now.

BTW: mangohud still shows its overlay with Proton 10 within the ED launcher while it initializes...

@kisak-valve
Copy link
Member

Proton Hotfix/Experimental suddenly doesn't work with VKB Gladiator NXT EVO R

Issue transferred from #8662.
@romner-set posted on 2025-05-06T19:30:40:

Compatibility Report

  • Name of the game with compatibility issues: Elite Dangerous (though I also tested another program within the same wine prefix and ran into the same problem, so it seems to be an issue with Proton itself)
  • Steam AppID of the game: 359320

System Information

  • GPU: RTX 3080 12GB
  • Video driver version: 4.6.0 NVIDIA 570.124.04
  • Kernel version: 6.12.19
  • Link to full system information report as Gist: here
  • Proton version: latest Hotfix and Experimental as of 2025-05-06

Symptoms

I use a VKB NXT EVO Omnithrottle L with an NXT EVO R (Premium version), and after updating Proton my right stick stopped working completely (anything inside the wine prefix was unable to receive any axis or button input from it, even if it was connected without the left stick). Reverting to Proton 9.0-4 fixed the issue.

I also checked the registry with protontricks 359320 regedit, and although both joysticks were identified and in their respective HKEY_LOCAL_MACHINE/System/CurrentControlSet/Enum/WINEBUS/VID_.../0&... both had Service correctly set to winehid, for some reason the right joystick's 0&... dir was named 0&0000&0&0&0. I also noticed that a new VID_... dir with the correct 0&... popped up after changing the Proton version to 9.0-4 or lower.

I also tried completely rm -rf-ing the wine prefix and reinstalling the game to no avail.

Reproduction

Attempt to use a VKB NXT EVO R Premium on the latest Proton Hotfix/Experimental version.

@kisak-valve
Copy link
Member

Hello @romner-set, can you see if you can gather a Proton log with the launch config requested at #150 (comment)?

@romner-set
Copy link

romner-set commented May 6, 2025

@kisak-valve Thanks for the quick response!

Clean prefix (rm -rf ~/.steam/steam/steamapps/compatdata/359320/) on Experimental: steam-359320.clean-experimental.log.gz

After switching to 9.0-4: steam-359320.9.0-4.log.gz

Both logs are of starting up the launcher and clicking a few buttons first on the left joystick (detected) and then on the right one (not detected on Experimental).

@kakra
Copy link
Contributor

kakra commented May 6, 2025

Clean prefix

@romner-set If you clean the prefix, all bindings in ED will be lost and you have to reassign the bindings to your NXT EVO. That's why I keep a backup (via snapper snapshots) of my wine prefixes, additionally I've copied the custom.X.Y.binds to VKB.X.Y.binds and renamed it inside the file using a text editor, too (those files are actually xml files). This way, your custom bindings never get overwritten or discard by the game, and it switches to this preset if it finds all the needed devices connected.

So if you start from a clean prefix, your joysticks would no longer work in ED until you reconfigure them in the game. Did you take that into account?

@romner-set
Copy link

romner-set commented May 6, 2025

@kakra I'm aware, I backed up the whole Bindings dir before deleting the prefix and tested the joysticks by trying to assign them to some controls in ED (+ opentrack in the same prefix, which resulted in the same behavior and pretty much confirms it's not a game issue).

@kakra
Copy link
Contributor

kakra commented May 6, 2025

opentrack in the same prefix, which resulted in the same behavior

@romner-set Ah okay, so you are using opentrack, too. But you couldn't confirm any correlation between using opentrack and the joysticks missing? I'm using the exact same joystick models you're using.

For me, it somehow started working during the tests I did. This looks like a race condition. Let me try again now to see if it still works for me.

@romner-set
Copy link

romner-set commented May 7, 2025

Ah okay, so you are using opentrack, too. But you couldn't confirm any correlation between using opentrack and the joysticks missing? I'm using the exact same joystick models you're using.

@kakra Nope, whether opentrack was running or not didn't change anything for me. It's weird how my omnithrottle worked fine even on Experimental though.

I also use the Windows version of opentrack inside Proton with opentrack-launch while (if I understand correctly) you're using the native version, so both of us using opentrack might just be a coincidence (especially since my problem occurs even with a clean, opentrack-less prefix).

I also checked the registry on my side and couldn't find any references to WINEXINPUT, so I'm not even sure we're facing the same problem.

@kakra
Copy link
Contributor

kakra commented May 7, 2025

@romner-set Yes, I'm using the native version which maps the TrackIR driver into the prefix. So I think we can rule out opentrack.

You could try unplugging both joysticks, then plug either of them back in first. This changes the order in which the game and/or wine see the joysticks, and see if this changes behavior... If it does, there's probably really some weird race condition going on. I don't think it's a problem with the game itself but rather something inside wine.

There's also an issue (already present in Proton 9) where all the new Ubisoft games won't detect my gamepad unless I disconnect and connect it again while the game is running. Some people fixed this by adding a second "fake" controller via software emulation. So that sounds strangely similar but it's probably unrelated because it was already present in Proton 9.

couldn't find any references to WINEXINPUT, so I'm not even sure we're facing the same problem

This is an artifact of an earlier bug in Proton 9 where VKB has been detected as a gamepad and wasn't preferred as a hidraw device inside wine. I actually created the patches which fix this, they have been squashed (along with patches for other joysticks) as a similar patch in Proton 10. After this recent incident, I cleaned the system.reg from all those artifacts. So we are now seeing the same issue. If you never ran ED with the affected Proton versions seeing the joysticks as gamepads, you won't have those artifacts in your prefix.

@romner-set
Copy link

You could try unplugging both joysticks, then plug either of them back in first. This changes the order in which the game and/or wine see the joysticks, and see if this changes behavior... If it does, there's probably really some weird race condition going on.

@kakra I tried that before reporting the issue, I also tried completely unplugging either the left or right stick, swapping the ports around, using motherboard ports instead of the front panel ones, pretty much everything I could think of, restarting the game every time... and nothing ever changed. Omnithrottle works fine on any version, right stick only works on 9.0-4 or lower.

Almost makes me think it's a hardware issue, but the sticks are practically identical and should be running pretty much the same firmware, so that feels unlikely. Both are also pretty much brand new (~1 month old) so I doubt it could be a malfunction.

@romner-set
Copy link

Almost makes me think it's a hardware issue, but the sticks are practically identical and should be running pretty much the same firmware, so that feels unlikely.

After saying that I decided to try and flash the firmware version made for the omnithrottle (_Gladiator_EVO_OTA_v2_19_6.vkb) to the right stick and voila, suddenly it works just fine. Flashing the right stick's firmware (_Gladiator_EVO_v2_19_6.vkb, note the missing _OTA) to the omnithrottle also caused it to stop working on Experimental, so I can confirm this is the problem. I still think whatever's causing this should be fixed in Proton though, since upgrading to Experimental is what broke things.

@kakra Try flashing both sticks with the latest omnithrottle firmware, might fix your problem as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
AMD RADV Possible driver issues with RADV Game compatibility - Unofficial Games not expected to work without issues Mesa drivers Possibly involves an issue with a Mesa video driver .NET Uses the .NET framework NVIDIA drivers Possibly involves an issue with the NVIDIA proprietary driver Regression Confirmed working on an older version of Proton
Projects
None yet
Development

No branches or pull requests