Bug 108662 - [DXVK] Elite Dangerous crash when loading shaders
Summary: [DXVK] Elite Dangerous crash when loading shaders
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/intel (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2018-11-05 13:00 UTC by leozinho29_eu
Modified: 2019-01-16 16:01 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

launching_regular_game (3.13 MB, text/plain)
2018-11-23 17:04 UTC, Denis
launching_demo_game (2.16 MB, text/plain)
2018-11-23 17:05 UTC, Denis
wine_output_last_100000_lines_before_crash (8.05 MB, text/plain)
2019-01-13 18:48 UTC, Dmitry

Note You need to log in before you can comment on or make changes to this bug.
Description leozinho29_eu 2018-11-05 13:00:04 UTC
Elite Dangerous using Steam Play crashes when the shaders are loading. Normally it crashes when still showing 0, but it can reach up to 10. On Windows 10 the shader loading takes 1 or 2 seconds so maybe it's too fast to notice if it goes further than 10. If using DXVK, in the moment it crashes the following can be read from Steam logs:

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

If using 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.

Be aware Elite Dangerous requires some steps until it is possible to open it using Steam Play. The message https://github.com/ValveSoftware/Proton/issues/150#issuecomment-433656318 has the required steps.

I am not 100% sure this is a Intel Mesa issue, the crash is happening both with and without DXVK and the addresses shown in the error messages are very close, tried with the Transform Feedback patches applied and no success. There is no GPU hang happening in this case.

System specifications:

Processor: Intel Core i3-6100U;
Video: Intel HD Graphics 520;
Architecture: amd64;
Mesa: 18.3.0-devel (git-cbd4468695);
Kernel version: 4.17.19;
Distribution: Xubuntu 18.04.1 amd64.
Comment 1 Denis 2018-11-22 17:35:54 UTC
hi. What HW do you have?
Also, according to manual in the provided link, I should install wine to the PC despite that one in proton?

I installed winehq-development (3.20) and got this error:

den@den-HP-ZBook-14u-G4:~/.steam/steam/steamapps/common/Proton 3.16/dist/bin$ WINEPREFIX=/home/den/.steam/steam/steamapps/compatdata/359320/pfx winetricks corefonts dotnet40 vcrun2012 quartz
wine cmd.exe /c echo '%ProgramFiles%' returned empty string, error message 'wine: '/home/den/.steam/steam/steamapps/compatdata/359320/pfx' is a 64-bit installation, it cannot be used with a 32-bit wineserver.'

That's a bit strange error, because before installing I removed all wine versions installed.

Execution of this only "winetricks corefonts dotnet40 vcrun2012 quartz" installed/downloaded these files.
Comment 2 leozinho29_eu 2018-11-22 18:12:56 UTC
Your problem seems to be that the 64-bit wine executable is not available, which is a bit strange, as it should properly use the 64-bit version when the WINEPREFIX is 64-bit. I am using Proton 3.16-4 and have Wine Staging installed.

One approach to check the prefix is by opening winetricks using a terminal. It shows in the terminal:

Using winetricks 20180815-next - sha256sum: 881435cf77fcff625f492b32f08d01585f9ac4e6e541c988d500c3eac3561be4 with wine-3.20 (Staging) and WINEARCH=win32

Notice WINEARCH, it shows if the prefix arch is 32 or 64-bit. If not setting the WINEPREFIX made it work, check if the prefix in the default prefix (the one used without setting it) is 32 or 64-bit. Maybe your installation has only the 32-bit programs?

About my hardware:

glxinfo -B
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2)  (0x1916)
    Version: 19.0.0
    Accelerated: yes
    Video memory: 3072MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2) 
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.0.0-devel (git-19af208c7d)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 19.0.0-devel (git-19af208c7d)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.0.0-devel (git-19af208c7d)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20


        apiVersion     = 0x40105a  (1.1.90)
        driverVersion  = 75903075 (0x4863063)
        vendorID       = 0x8086
        deviceID       = 0x1916
        deviceType     = INTEGRATED_GPU
        deviceName     = Intel(R) HD Graphics 520 (Skylake GT2)
Comment 3 Denis 2018-11-23 11:01:23 UTC
ok, thanks for the help. Sorted out issue with x32 wine - looks like I didn't clean system well.
Check please below questions/notes:

1. Final result after first command (I also tried to launch downloaded dotNetFx40_Full_x86_x64.exe manually - it said that my installed version is higher then current one)

WINEPREFIX=/home/den/.steam/steam/steamapps/compatdata/359320/pfx winetricks corefonts dotnet40 vcrun2012 quartz
You are using a 64-bit WINEPREFIX. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
Executing w_do_call corefonts
corefonts already installed, skipping
Executing w_do_call dotnet40
Executing load_dotnet40
This package does not work on a 64-bit installation

running this command separately allowed me to install dotnet40

>winetricks dotnet40

2. It is a bit not clear, what keys exactly need to move:
In the /Cryptography folder there was only 1 file with a name MachineGuid and Value. So I copy/pasted exactly value. Is it correct?
WINEPREFIX=/home/den/.steam/steam/steamapps/compatdata/359320/pfx regedit

3. Last step for me looks extra, because win7 already set by default
WINEPREFIX=/home/den/.steam/steam/steamapps/compatdata/359320/pfx winecfg

The last step is launching using "system" wine, not from steam, provides this error:

den@den-HP-ZBook-14u-G4:~/.steam/steam/steamapps/common/Elite Dangerous$ wine '/home/den/.steam/steam/steamapps/common/Elite Dangerous/EDLaunch.exe' 
0012:err:module:import_dll Library mscoree.dll (which is needed by L"C:\\windows\\Microsoft.NET\\Framework\\v4.0.30319\\mscorsvw.exe") not found
0012:err:module:attach_dlls Importing dlls for L"C:\\windows\\Microsoft.NET\\Framework\\v4.0.30319\\mscorsvw.exe" failed, status c0000135
000f:err:service:process_send_command service protocol error - failed to write pipe!
000f:fixme:service:scmdatabase_autostart_services Auto-start service L"clr_optimization_v4.0.30319_32" failed to start: 1053
0009:err:module:fixup_imports_ilonly mscoree.dll not found, IL-only binary L"EDLaunch.exe" cannot be loaded
0009:err:module:attach_dlls Importing dlls for L"Z:\\home\\den\\.steam\\steam\\steamapps\\common\\Elite Dangerous\\EDLaunch.exe" failed, status c0000135

>wine uninstaller
this command says, that I have 2 MC dotnet's installed (Client profile and Extended), both are 4.0.30319

Do you have any ideas how to fix these new issues?
Comment 4 leozinho29_eu 2018-11-23 11:09:27 UTC
If the WINEPREFIX got this bad, I suggest deleting the directory /home/den/.steam/steam/steamapps/compatdata/359320

After deleting that directory, try to open Elite Dangerous again on Steam. It should fail, but should create the WINEPREFIX.

Install the following winetricks only:

WINEPREFIX=/home/den/.steam/steam/steamapps/compatdata/359320 winetricks dotnet452 quartz

The CRC error is not really critical at this moment because the error would only happen after the successful shader loading and before joining the game.
Comment 5 Denis 2018-11-23 13:47:56 UTC
ok. Thanks again. My problem was in really old winetips (from 2014 year 8-/)

Launched the game on KBL, but it doesn't want to launch (I mean, process exists on System monitor, but nothing happens).
If I am selecting Combat Training - black window appears and that's all.

I will setup everything on another laptop, with HD520 (SKL).
Comment 6 Denis 2018-11-23 14:28:20 UTC
hm, finally (I didn't change anything) practice was started. And I got

[172527.413266] CIPCServer::Thr[19436]: segfault at 4668730c ip 00000000ee2d0624 sp 00000000ed4fee00 error 4 in steamclient.so[ee15c000+158d000]

continue checking  (it was on KBL)
Comment 7 Denis 2018-11-23 16:35:27 UTC
So, what I got:

1. Game can't be launched using .sh script in steam pre-load options (so I couldn't exchange library for it)
2. Game doesn't launch in any mode exept demo
3. In demo game freezes in the main menu or even earlier
upd - if I have 2 monitors (laptop+external) - game loads up to the main menu. If I turn off laptop monitor - game always freezing before main menu.
4. Game doesn't provide any useful logs about errors etc (only sometimes it may print sigfault in some process, like, gnome-system-monitor, or steam, as in prefious log)

1. Game doesn't launch in ANY of the game modes. Reboots and re-launches of steam didn't help at all.

I wouldn't say that it is possible to debug this somehow, so any ideas will be appreciated.

On KBL I have 16.04 ubuntu, on SKL - 18.04
Comment 8 Denis 2018-11-23 17:04:53 UTC
Created attachment 142596 [details]

And the last note from me. I activated "user_settings.py" this config in proton 3.16-4 (selected in steam) and uncommented this option

    #Use gl-based wined3d for d3d11 and d3d10 instead of vulkan-based dxvk
#    "PROTON_USE_WINED3D": "1",

This didn't change results of the game launching.

Adding 2 logs, generated after game launching:
launching_regular_game <= in this case game window even didn't open (process appeared in system monitor and that's all)
launching_demo_game <= in this case game window opened fullscreen, but was black and game was frozen.
Comment 9 Denis 2018-11-23 17:05:27 UTC
Created attachment 142597 [details]
Comment 10 leozinho29_eu 2018-11-23 18:55:28 UTC
Did you add: taskset -c 0 %command% in the launch settings of the game? Currently it seems to dislike more than one thread.

I can reach to the Combat Demo which runs at around 9 FPS due to CPU bottleneck (intel_gpu_top shows around 35% RC6 time).

However, the "main game" does not load, crashing with the buffer overflow/other error with address very close.

To me there is no difference regarding the final result between Wine OpenGL and DXVK: both crash at up to 10 of loading shaders.
Comment 11 Denis 2018-11-26 09:29:06 UTC
>Did you add: taskset -c 0 %command% in the launch settings of the game?
No I didn't. Tried only "run.sh %command%" with specifing in run.sh lib exports.
Will try this, maybe it will change my results
Comment 12 Denis 2018-11-26 14:30:21 UTC
on KBL with mentioned option I successfully launched demo with training missions.
On SKL nothing changed. So maybe it relates to SKL only. Will try to check more, to be sure in this
Comment 13 leozinho29_eu 2018-11-27 22:34:15 UTC
Good, if the Combat Demo is stable, then the prefix seems ready to test for this bug.

The option in the Launcher should be the "ELITE DANGEROUS (64-BIT)", which is the first option. It should behave as the Combat Demo until the shaders loading start. On this step, it is freezing at 0, 7 or 10 to me, then the crash reporter appears and the messages at the log can be seen informing about the overflow/invalid frame.

Not sure about how significant would be the differences between Skylake and Kaby Lake regarding the shader loading, but the Kaby Lake computer seems ready to test the main game.

PS.: Your Skylake machine needs some love :)
Comment 14 Denis 2018-11-28 08:39:54 UTC
>PS.: Your Skylake machine needs some love :)
I am trying, but not sure that I can produce SO MANY love for it((

BTW, according to your comment:
>It should behave as the Combat Demo until the shaders loading start. On this step, it is freezing at 0, 7 or 10 to me, then the crash reporter appears and the messages at the log can be seen informing about the overflow/invalid frame.

I can see crash reporter exactly on SKL, on KBL simply nothing happens. I didn't pay attention on it because supposed that you talked about loading the mission, not the main menu.

Comment 15 leozinho29_eu 2018-12-13 20:00:04 UTC
With Steam Play updated to 3.16-5 Beta and the game update, I am still facing this issue. Is there a way I could get some additional data that could help to debug this?
Comment 16 Vasily Galkin 2018-12-15 19:49:49 UTC
I have a similar error trying while launching WorldOfWarcaft with GeminiLake CPU with DRI Intel(R) UHD Graphics 600

I have exception 

> 0009:err:seh:setup_exception stack overflow 1760 bytes in thread 0009 eip 000000007bc9b6d9 esp 0000000000140f30 stack 0x140000-0x141000-0x240000

with any recent (3.18-4.0rc2) with all wine versions compiled by debian-based-distros with vkd3d, even if I start game in dx11 mode which doesn't use vkd3d.

However, while using any binary wine from https://wiki.winehq.org/Download it is working (slow, in dx11, since that binaries are without vkd3d, but at least working)

So I think you can try official wine binaries instead of the binaries provided by ubuntu/debian/ppa-s
Comment 17 Vasily Galkin 2018-12-20 23:01:31 UTC
I took wine-staging binaries 4.0rc1 and replaced its *d3d12* and *dxgi* with versions from ubuntu build of 4.0rc1.

The resulting mix has both dx11 and dx12 (via vkd3d) working.

But, using the same game, same system mesa/drm libraries, and same wine prefix wine builds packaged from ubuntu/debian do crash with 

> seh:setup_exception stack overflow 1760 bytes

while mixed binaries works fine in dx11 and dx12.

So it looks that the "seh:setup_exception stack overflow" problem in recent wines appears only on specific wine builds - caused by some difference in wine compile options or other build differences - compiler version/option, etc...
Comment 18 Denis 2018-12-25 11:09:05 UTC
Hi Vasily, did you write this to wine developers somewhere? If yes, provide please a link to discussion, for traceability
Comment 19 Vasily Galkin 2018-12-25 23:17:33 UTC
By now I reported it to only to debian since the upstream binaries are working fine for me.

Comment 20 Dmitry 2019-01-08 21:30:34 UTC
I have the same issue with ED. With wined3d it crashes like this:

0097:err:seh:call_stack_handlers invalid frame 588bb648 (0x588f2000-0x589f0000)
0097:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception.

Same thing with DXVK (v0.94):

006a:err:seh:call_stack_handlers invalid frame 58e29ec8 (0x58e52000-0x58f50000)
006a:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception.

Software: Ubuntu 18.10 with wine-staging 4.0-RC5(from wine's ppa) and Mesa 19.0 (from padooka ppa).
Hardware: Dell XPS 13 with Intel(R) UHD Graphics 620 (Kabylake GT2) GPU.

Apparently the game works fine with Nvidia GPU's, that's why I think it might be related to Intel and Mesa.
Comment 21 Dmitry 2019-01-13 18:48:41 UTC
Created attachment 143090 [details]

I attached wine's output just before the crash (with DXVK). Looks like vkCreateComputePipelines was called just before the crash. Crash seems to be a result of stack corrupton. Afaik ED is notorious for having huge shaders, so maybe this was the casue of the crash. My theory is that some shader was too big and buffer overflow happend.
Comment 22 Dmitry 2019-01-16 16:01:20 UTC
Something has changed after updating Mesa to: 1:19.0~git190115105000.7bef192~c~padoka0

Now the game does not crash immediately. It starts compiling those shaders and crashes after about an hour of compilation with stack corruption. It should not take that much time (it should be like 10 seconds or so).

I can try to dump those shaders, would that be useful for any developers?

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.