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.

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

vulkaninfo:

        apiVersion     = 0x40105a  (1.1.90)
        driverVersion  = 75903075 (0x4863063)
        vendorID       = 0x8086
        deviceID       = 0x1916
        deviceType     = INTEGRATED_GPU
        deviceName     = Intel(R) HD Graphics 520 (Skylake GT2)

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

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

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.

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

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)

So, what I got:

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

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

Created attachment 142596 [details]
launching_regular_game

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.

Created attachment 142597 [details]
launching_demo_game

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.

>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

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

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

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

Checking

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?

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

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

Hi Vasily, did you write this to wine developers somewhere? If yes, provide please a link to discussion, for traceability

By now I reported it to only to debian since the upstream binaries are working fine for me.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917307

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.

Created attachment 143090 [details]
wine_output_last_100000_lines_before_crash

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.

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?

Created attachment 144766 [details]
Relevant logs

An update to this bug report: since Steam Play 4.2-5, the base game is working. The shader compilation stage is taking around 35 minutes, but then it only needs to compile again if some change is made to the drivers or Steam updates.

From what I tested so far, using Mesa 19.0.2 with the patch available in the bug 110295 page makes the game run error-free, near flawlessly. The only graphical bug I can see is the character photos not loading properly.

Now I got Elite Dangerous: Horizons. It crashes at 19% of the shader compilation. Sometimes it crashes after 1 minute at 19%, sometimes it crashes after 16 hours at 19%. Supposedly, it's some extremely complex shader. Even when using Windows 10 on the same computer Elite Dangerous: Horizons crashes sometimes at 19%.

The attached file has some relevant logs. Updated system specifications, as now it has much more memory, but also lower bandwidth by 2 GB/s, which is causing a 25% performance loss on DiRT Rally:

Processor: Intel Core i3-6100U;
Video: Intel HD Graphics 520;
Architecture: amd64;
RAM memory: 20 GB;
Mesa: 19.2.0-devel (git-2614319259);
Kernel version: 4.19.58-041958-lowlatency;
Distribution: Xubuntu 18.04.2 amd64.

Created attachment 144831 [details]
Logs and apitrace

Now that the bug 111152 was fixed, Elite Dangerous on Intel HD Graphics 520 seem to have only three problems currently: a strange effect with dust particles (which happens on Windows too, apitrace coming on a new report), some blinking elements from bug 110295 and this crash on shader compilation when opening Horizons. The base game is working.

The attached file contains the relevant logs and the apitrace of the game loading. Replaying the apitrace, the shader loading seems to work as it would work in-game, including the crash at 19% from the planet generation system. On my computer with Mesa 19.2.0-devel (git-d31d25f634), the shader loading takes around 20 minutes.

Is there some additional file/log I could obtain to help identifying the problem?

(In reply to leozinho29_eu from comment #24)
> The attached file contains the relevant logs and the apitrace of the game
> loading. Replaying the apitrace, the shader loading seems to work as it
> would work in-game, including the crash at 19% from the planet generation
> system. On my computer with Mesa 19.2.0-devel (git-d31d25f634), the shader
> loading takes around 20 minutes.

I'm having trouble reproducing with the attached trace.  Everything goes fine for a while and then the window goes a cream color and it just sits there.  No crash.  Do I need to let it sit for a while or does that mean it's not crashing for me?

That apitrace should work as the following: a few seconds only with black screen, then the Frontier logo, then the Elite Dangerous logo, then the first shader loading. The first shader loading should take a long time, but it should end. The second shader loading is where it crashes at 19%.

The loadings here can easily take 20 minutes on this case, 40 minutes is possible. Maybe the window has to be focused because of so slow it is, and the screen get that strange color if not focused. DXVK reports 0.0 FPS while the shader loads: between the 0 to 2%, and 2 to 5 and other percentage changes, the window is completely frozen.

I let the trace play and it played all the way to the end without crashing.  Can you try with DXVK 1.3?  I'm using the latest stable release.

I installed the latest DXVK, which is 1.3.1 on the wineprefix, confirmed 1.3.1 was being used by DXVK_HUD, but still had the same outcome: the first shader loading finishes but the second loading, the planet generation system, crashes at 19%.

Did the planet generation system loading (the second load) reach 100% for you? Maybe this problem is Skylake specific, then.

I'm using Kaby Lake which is basically identical to Skylake so that's not the problem.  Is the game a 32-bit or 64-bit executable? Maybe it's a 32-bit issue? I'll try that.

Nope.  Runs to completion on 32-bit too.  Other possible differences include the fact that I'm on Fedora with probably a different Wine version.

I tried using Wine 4.12.1 with DXVK 1.3.1 instead of Steam Play 4.2-9 and it still didn't work, crashing at the same place.

There are a few messages that are noticeable on the logs, which may indicate the cause of this.

Using Steam Play 4.2-9:

11622.296:00ad:00d8:err:seh:call_stack_handlers invalid frame 593a5a30 (0x593c2000-0x594c0000)
11622.296:00ad:00d8:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception.

Using Wine 4.12.1 with DXVK 1.3.1:

0162:err:seh:call_stack_handlers invalid frame 59535a50 (0x59552000-0x59650000)
0162:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception.
0161:err:seh:setup_exception stack overflow 1552 bytes in thread 0161 eip 000000007bc8c104 esp 0000000059441000 stack

Notice these "invalid frame" values. They are the same. The DXVK versions are different and the Wine version are different but, still, the "invalid frame" is exactly the same.

On previous Steam Play versions, it printed similar messages with slightly smaller values (58a3c478). I don't know what this frame which is invalid is, but this was the only part of the (huge) logs which I could clearly see a problem exists.

This game has some memory management problems. I commented about it and one workaround in GitHub the issue, https://github.com/ValveSoftware/Proton/issues/150#issuecomment-512500740, there I explain the problem this game is having with memory management, where it crashes once it reaches high values and requires an workaround. 3755 MB and 3868 MB are values which can easily make the game crash saying it failed to allocate memory.

As the log messages with stack overflow show memory problems, maybe there is a general issue which Elite Dangerous that it can't use more than 4 GB of video memory, even if the computer has 20 GB available and DXVK says the heap value is 14 GB.

Are you testing with the game or with the trace?  d3dretrace shouldn't have the stack corruption issues.

That tests were using the game. I'm wondering if this apitrace ever recorded the moment of failure and is closing just before it, giving the impression it was successful.

I will try to record another apitrace.

Created attachment 144836 [details]
Logs and apitrace

I'm sorry.

That apitrace I sent before was problematic. This time I got a valid apitrace, which was made on Windows 10, tested on Windows 10 and tested on Xubuntu 18.04. The attached file contains the apitrace, one log generated with default Wine debug settings, another log with increased logging and two images: one showing where the Linux run ends and one showing where the Windows run ends.

It is noticeable that the stack overflow messages are appearing in the log file with increased logging even when just replaying the apitrace.

The Linux run results in a crash at that 19% part, while the Windows run reaches the main menu, showing the ship docked in the station.

I can't believe I didn't notice the previous apitrace itself was bad.

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1414

I tested the patch and it worked on my computer. The loading finished and Elite Dangerous: Horizons is working. Thank you.

I'm curious about one thing: did you use the apitrace sent on comment 34 to find this? Anyways, I'm sorry for sending a bad apitrace before.

(In reply to leozinho29_eu from comment #36)
> I'm curious about one thing: did you use the apitrace sent on comment 34 to
> find this? Anyways, I'm sorry for sending a bad apitrace before.

Yes.  Once I was able to reproduce reliably, figuring out the problem was pretty easy.

Fixed by the following commit in master:

commit fa63fad3332309afa14fea68c87cf6aa138fb45c
Author: Jason Ekstrand <jason@jlekstrand.net>
Date:   Mon Jul 22 00:28:27 2019 -0500

    intel/fs: Stop stack allocating large arrays
    
    Normally, we haven't worried too much about stack sizes as Linux tends
    to be fairly friendly towards large stacks.  However, when running DXVK
    apps under wine, we're suddenly subject to Windows' more stringent stack
    limitations and can run out of space more easily.  In particular, some
    of the shaders in Elite Dangerous: Horizons have quite a few registers
    and the arrays in split_virtual_grfs are large enough to blow a 1 MiB
    stack leading to crashes during shader compilation.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108662
    Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Reviewed-by: Matt Turner <mattst88@gmail.com>
    Cc: mesa-stable@lists.freedesktop.org