EDLaunch_d3d9.log
this is newest I can see >:

That's all for launcher. There is bigger one for game itself, but game runs ok.
...I think I installed 4.7 .net there somewhen before ... and now each time installer does wineboot it shows me 2 errors, something cannot be registered in registry ... could it be problem?

Use the flag /steam it should fix the launcher weirdness.

Here are the logs from just opening and closing the launcher. This was with Proton 5.
dxdiag_d3d9.log
EDLaunch_d3d9.log
steam-359320.log
There is also an empty dxdiag_dxvk_config.log file.
I hope this helps a bit.

Use the flag /steam it should fix the launcher weirdness.

Nope, didn't do. However I use separated installation. Not from Steam. Because at the day I bought it updaters were fighting each other - steam updates, then launcher updates, then steam updates back etc :D

Use the flag /steam it should fix the launcher weirdness.

Nope, didn't do. However I use separated installation. Not from Steam. Because at the day I bought it updaters were fighting each other - steam updates, then launcher updates, then steam updates back etc :D

What I mean is use /steam as a launch argument (works with non steam version).

If you use Lutris add the /steam to the argument section in game options or if using command line or bash script use WINEPREFIX='/path/to/pfx' wine64 '/path/to/EDLaunch.exe' /steam

Use the flag /steam it should fix the launcher weirdness.

Nope, didn't do. However I use separated installation. Not from Steam. Because at the day I bought it updaters were fighting each other - steam updates, then launcher updates, then steam updates back etc :D

What I mean is use /steam as a launch argument (works with non steam version).

If you use Lutris add the /steam to the argument section in game options or if using command line or bash script use WINEPREFIX='/path/to/pfx' wine64 '/path/to/EDLaunch.exe' /steam

Nope

Use the flag /steam it should fix the launcher weirdness.

Nope, didn't do. However I use separated installation. Not from Steam. Because at the day I bought it updaters were fighting each other - steam updates, then launcher updates, then steam updates back etc :D

What I mean is use /steam as a launch argument (works with non steam version).
If you use Lutris add the /steam to the argument section in game options or if using command line or bash script use WINEPREFIX='/path/to/pfx' wine64 '/path/to/EDLaunch.exe' /steam

Nope

I'm unfamiliar with PoL, can you try Lutris? This is what I pretty much have.

Thing is I can pretty much replicate the issue and resolve it by putting the launcher in it's steam mode, this is what it should show even on non steam install if done correctly:

Here is another Proton logfile from running the launcher with d3d9 from Wine with the d3d9 debug channel fully enabled. May be that reveals some something useful.
steam-359320.log

Actually - looks like @fls2018 is correct. The '/steam' option does resolve it.

But I needed an extra step. Because I have a iGPU and dedicated Nvidia GPU, I had to also use the following environment variable:
DXVK_FILTER_DEVICE_NAME=GTX

Without it, the iGPU was used:
Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)

and the '/steam' option made no difference (but I'm only running mesa driver version 19.2.8 - so that could be an issue upgrading to 19.3.3 made no difference).

But with the DXVK_FILTER_DEVICE_NAME environment variable set, the logs show the Nvidia GPU being used:
GeForce GTX 1050 Ti

and the launcher renders correctly.

But I need both set:

• the '/steam' parameter; and
• the DXVK_FILTER_DEVICE_NAME environment variable

So in Steam, I can solve the issue with the following Launch Option:

The '/steam' parameter use to be required for OpenGL too - but at some point that seemed to resolve itself.

I thought the Mesa driver might have been an issue, but using DXVK_FILTER_DEVICE_NAME=UHD and '/steam' also works. So there seems to be two issues:

1. Needing the '/steam' option (which use to also be required for OpenGL); and
2. Having multiple GPUs (which can be worked around with the DXVK_FILTER_DEVICE_NAME environment variable)

Edit: I've attached a couple of logs. I don't think they're detailed enough to provide any real insight, but I did notice that when I don't specify a GPU, both GPUs are listed and it goes in to some kind of loop.
gtx_only.log
multiple_devices.log

More logs. I found how to include an api dump:
gtx_only_apidump.log
gtx_only_no_steam_option_apidump.log
multiple_gpus_apidump.log

Note the:
wine: Read access denied for device L"\\??\\Z:\\", FS volume label and serial are not available.

line in the gtx_only logs. At this point, the launcher has finished loading. When using the '/steam' option, this is the last line in the log. But when not using the '/steam' option, interacting with the launcher using the mouse causes elements to disappear and a new set of api calls being logged (which seem to always end with vkWaitForFences).

I'm not sure if you're aware, but I believe the launcher can be accessed with just the demo of Elite Dangerous (and if you were aware, then these logs are probably not much help).

Yes, menus won't draw too. As I said it is happens then resolves, then happens again with different DXVK. I think smoothest one was latest in 1.3 branch. Before that menus was broken, since 1.4.4 (deepest I rollback to) I have what I have - no buttons draw. For example, somewhen in 1.3.x when you click menu - it was nothing, then you move mouse down and cursor draws menu items behind it.
/steam flag does not fix for me.

About the /steam argument, I guess it is only part of a solution. I'm using ED from Steam, the /steam parameter is automatically appended. I'm seeing it when looking with System Monitor or similar to the exact launch command. Even then the buttons are hidden (but usable) with DXVK's d3d9, but visible with Wine's d3d9 or disabled d3d9 like in the screenshots from the OP.

Just updated to latest 1.5.4 - still broken, and still same effect if allow run for long..
...if start launcher and left it for 5+ mins eventually crash window appear...
...i'm going to think, maybe they do checksum validations, but then why so long? >:
Game has some anticheat exe, some whatchguard64. Could it be that this guy fails, and launcher just awaits response prior show buttons?
...but then ..why it worked with some 1.3.x versions? >:

Ok, taking back my words, seems like crc check ..

Just tried 1.3.4 which worked for sure before.

@jp7677 @alexzk1 I looked at your logs and I saw that your devices are being listed twice. I believe it's because you both have OpenVR?

In my log I have:
OpenVR: Failed to locate module

But your logs don't have that. Instead you both have:
warn: 0034:warn:module:open_dll_file HACK: Accepting native steamclient module from L"\\??\\C:\\Program Files (x86)\\Steam\\steamclient64.dll", even though it's the wrong arch.).

So I think the common theme here is that if there are multiple devices listed (in my case it was because I have two GPUs) then the rendering issue occurs.

Scratch the bit about OpenVR.

I just noticed that the @alexzk1 log does have OpenVR: Failed to locate module.

And the @jp7677 log has warn: OpenVR: Failed to initialize OpenVR.

But I can see in both logs, your devices are listed twice during the initialisation (so I believe it is returning multiple adaptors in Direct3DCreate9Ex call).

@redmcg I have a simple Desktop machine with just a single GPU (GTX1080).

I have tried to replay the trace I took with both Wine and DXVK. I found it interesting that using DXVK a window appeared, but with Wine actually nothing visibly happens. Though I absolutely don't know what should have happened and what should have been the expected behavior nor whether this is relevant. I guess only a trace made on Windows could tell, unfortunately I'm Linux only.

I just created a quick gist:
https://gist.github.com/redmcg/5b11d2d18ff29da5d9d4886b2e1699a1

Compile with:
x86_64-w64-mingw32-g++ d3d9Test.cpp

Then run with:
wine a

This will dump information about the number of adapters D3D9 is reporting.

I got a hint from Discord (thanks there). It turns out that I have two vulkan icd files pointing to the same driver which resulted in vulkan thinking I got two GPU's, vulkaninfo indeed returns 2 identical adapters.

ls /usr/share/vulkan/icd.d/
intel_icd.i686.json  intel_icd.x86_64.json  nvidia_icd.i686.json  nvidia_icd.x86_64.json  radeon_icd.i686.json  radeon_icd.x86_64.json

Both nvidia files point to the same library. Once I restricted vulkan to just one icd file with VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.x86_64.json I'm seeing that vulkaninfo reports just one GPU. Same with @redmcg's adapter test, just one adapter left.

Regarding this issue, this turns out to be a packaging issue (well, for me). Putting VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.x86_64.json into the launch options of the ED launcher does indeed fixes this! Very cool, thanks a lot @redmcg

I'm using Fedora with drivers from Negativo17. I'm going to open an issue there.

Edit: Using the DXVK device filter would work in my case too, since according to https://github.com/doitsujin/dxvk#device-filter it will return only the first matching device.

I don't understand your words about crc checks etc and don't know how this is related to the appearance of the launcher. I guess this is an entirely different issue, probably not related to DXVK at all.

I had idea that they do check crc of dll files by hackers protection, and while they do that - buttons are disabled..

New packages for Fedora from negativo17 are available that fix the issue I had with having two Vulkan ICD files being installed.

This should be fixed now.