Bottles does not find .dll files even though they are present

[TheEvilSkeleton]

Whenever I try to launch a D3D11 game, like Jurassic World Evolution (JWE), Bottles outputs a couple of errors saying that some .dll files do not exist, even though they actually do. Keep in mind that I only tried with JWE.

When I execute the launch file (in my case JWE.exe), I get the following:

2021-05-23 15:22:26 INFO: Bottles Started!
2021-05-23 15:22:31 INFO: Running an executable on the wineprefix …
esync: up and running.
002c:err:winediag:WS_getaddrinfo Failed to resolve your host name IP
0090:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\wineusb": c0000142
0024:err:module:import_dll Library dxgi.dll (which is needed by L"C:\\windows\\system32\\d3d11.dll") not found
0024:err:module:import_dll Library d3d11.dll (which is needed by L"Z:\\run\\media\\TheEvilSkeleton\\HOME\\themainone\\bottles\\Games\\Jurassic World - Evolution\\JWE.exe") not found
0024:err:module:import_dll Library dxgi.dll (which is needed by L"Z:\\run\\media\\TheEvilSkeleton\\HOME\\themainone\\bottles\\Games\\Jurassic World - Evolution\\JWE.exe") not found
0024:err:module:LdrInitializeThunk Importing dlls for L"Z:\\run\\media\\TheEvilSkeleton\\HOME\\themainone\\bottles\\Games\\Jurassic World - Evolution\\JWE.exe" failed, status c0000135

The game does not launch at all.

When I search in the directories, those two files do exist:

$ pwd
/var/home/TheEvilSkeleton/.local/share/bottles/bottles/JWE
$ find . -name dxgi.dll && find . -name d3d11.dll
./drive_c/windows/system32/dxgi.dll
./drive_c/windows/syswow64/dxgi.dll
./drive_c/windows/system32/d3d11.dll
./drive_c/windows/syswow64/d3d11.dll

[mirkobrombin]

Try creating a bottle with a different runner like Lutris or Proton. Btw this is more a Wine related issue not Bottles.

[TheEvilSkeleton]

Same problem unfortunately. I tried using newer and older versions of Lutris and Proton runners, but no luck.

Should I open an issue in the WINE issue tracker or DXVK issue tracker?

[mirkobrombin]

Check this first https://github.com/doitsujin/dxvk/issues/1098

[TheEvilSkeleton]

For https://github.com/doitsujin/dxvk/issues/1098#issuecomment-503388801:

Copy the files manually to windows/system32 and change the extension from .dll.so to just .dll

The .dll files are already there, so I don't need to copy and rename anything.

then remove the D3D11 and DXGI DLL overrides entirely since wine considers winelib builds to be builtin.

I didn't override anything; I'm just using the default configurations of runners.

[mirkobrombin]

For doitsujin/dxvk#1098 (comment):

Copy the files manually to windows/system32 and change the extension from .dll.so to just .dll

The .dll files are already there, so I don't need to copy and rename anything.

then remove the D3D11 and DXGI DLL overrides entirely since wine considers winelib builds to be builtin.

I didn't override anything; I'm just using the default configurations of runners.

I don't know, I should try to reproduce the problem

[TheEvilSkeleton]

Should I close this issue then?

[mirkobrombin]

Should I close this issue then?

Unfortunately yes, because not having that title I cannot reproduce your problem. But I give you a way, try to download the latest version of Proton from the preferences and create a new bottle of type Custom (without dxvk), then read here: https://forums.lutris.net/t/jurassic-world-evolution/10002/

Idk if you are using the Steam or Epic Store version but in the second case you need these dependencies:

• vcredist2019
• dotnet40
• dotnet48
• corefonts

and should be launched with these arguments -opengl -SkipBuildPatchPrereq.

I'm sorry not to be able to give better support on this front but from Bottles v4 we will support the installers (e.g. https://github.com/bottlesdevs/programs/blob/main/Games/epicgamestore.json) and we will be able to give support for specific programs (or mark them as broken in case of incompatibility).

For now I close the issue, in case there is any update let us know.

[TheEvilSkeleton]

@mirkobrombin sorry for the ping. How do I launch with the arguments you have provided directly from Bottles? I am a bit confused with how this works.

[mirkobrombin]

@mirkobrombin sorry for the ping. How do I launch with the arguments you have provided directly from Bottles? I am a bit confused with how this works.

After installing it, it should appear in the program list of the bottle. From the context menu on the right you can add args.

[TheEvilSkeleton]

Doesn't seem to appear on my Programs list. Note that I installed the game via a setup.exe file, and not from Steam or Epic Games Store.

The list is empty:

[mirkobrombin]

Not all programs appear in that list, even when restarting bottles? You can add it manually from the bottle configuration file but I don't remember how at the moment and I'm not at the PC.

[TheEvilSkeleton]

Not all programs appear in that list, even when restarting bottles?

I restarted the app, rebooted and even reinstalled the game, and none of them worked.

You can add it manually from the bottle configuration file but I don't remember how at the moment and I'm not at the PC.

Alright. I can wait for the instructions.

[mirkobrombin]

Currently not all installed programs are detected by Bottles (https://github.com/bottlesdevs/Bottles/issues/141) will be solved with v4 with the our installers (https://github.com/bottlesdevs/Bottles/issues/55).

eg. Epic Games Launcher appear:

What you can do is add the executable to the bottle configuration file by your hand, eg. for ExecutableName.exe:

{
    "Name": ....
    ....
    "Programs": {
        "ExecutableName.exe": "-arg1 -arg2"
    }
}

so when you run that executable from the "Run .exe" function, Bottles will use the arguments you passed. (This will not add the program to the program list).

I know this is a bit tricky method and that it is certainly not the best user experience but it makes no sense to me to improve the process in v3 knowing that it is being rewritten in v4.

[TheEvilSkeleton]

I just tried doing it by hand, and now I get the following error:

2021-06-05 12:10:02 INFO: Running an executable on the wineprefix …
002c:err:winediag:WS_getaddrinfo Failed to resolve your host name IP
0024:err:module:LdrInitializeThunk "" failed to initialize, aborting
0024:err:module:LdrInitializeThunk Initializing dlls for L"Z:\\run\\media\\TheEvilSkeleton\\HOME\\themainone\\bottles\\Games\\Jurassic World - Evolution\\JWE.exe" failed, status c0000005

Here is how the bottle.json looks like (located at ~/.local/share/bottles/bottles/JWE---OpenGL):

{
    "Name": "JWE - OpenGL 2",
    "Runner": "chardonnay-6.8",
    "DXVK": "dxvk-1.8.1",
    "Path": "JWE---OpenGL-2",
    "Custom_Path": false,
    "Environment": "Custom",
    "Creation_Date": "2021-06-05 12:01:33.397528",
    "Update_Date": "2021-06-05 12:01:33.397554",
    "Versioning": false,
    "State": 0,
    "Parameters": {
        "dxvk": false,
        "dxvk_hud": false,
        "sync": "wine",
        "aco_compiler": false,
        "discrete_gpu": false,
        "virtual_desktop": false,
        "virtual_desktop_res": "1280x720",
        "pulseaudio_latency": false,
        "fixme_logs": false,
        "environment_variables": ""
    },
    "Installed_Dependencies": [],
    "DLL_Overrides": {},
    "Programs": {
        "JWE.exe": "-opengl -SkipBuildPatchPrereq"
    }
}

And that's the executable:

I tried Lutris, Shardonnay and Proton GE runners.

[mirkobrombin]

Can you try it via the AppImage? I would like to understand if it is a problem of the Flatpak version or actually incompatibility with Wine.

[TheEvilSkeleton]

I just used the AppImage. I get the same error. Only that it now outputs a file called GameOverlayRenderer.log: GameOverlayRenderer.log

[biggestsonicfan]

I've just recently found Bottles and felt it would help meet my needs for a specific Windows application, however I am getting similar DLL files not found errors as OP.

Apparently, Bottles is copying the executable to the systemd temporary user directory (e.g. /run/user/1000/doc/) and trying to run the exe there? I find that extremely bizarre behavior as if you could copy "Microsoft Word.exe" from one computer to another and expect it to run as a portable executable without any dependencies created at install time in the same directory as "Microsoft Word.exe".

My application isn't a portable one, nor does it require installation, but it does require the dll dependencies within the same subfolder, and that's just to get the executable running. I can only imagine without all the other files the application itself needs at runtime the program will just not work at all.

[Fredolx]

I have the same issue. It puts my .exe inside a /run/user/1000 thing (portal?) and then fails to find .dlls located within the .exe's folder. I tried setting a working directory which seemed to have fixed it, but now the game complains it has no write access? .

Is there a way to use the real working directory instead of those "virtual" folders? Sorry for my lack of vocabulary, this is my first time using bottles.

Error codes when not setting a working directory:

0024:err:module:import_dll Library steam_api64.dll (which is needed by L"Z:\\run\\user\\1000\\doc\\5af89eb4\\s1_sp64_ship.exe") not found
0024:err:module:import_dll Library bink2w64.dll (which is needed by L"Z:\\run\\user\\1000\\doc\\5af89eb4\\s1_sp64_ship.exe") not found
0024:err:module:LdrInitializeThunk Importing dlls for L"Z:\\run\\user\\1000\\doc\\5af89eb4\\s1_sp64_ship.exe" failed, status c0000135

[jul1u5]

I noticed the same problem, too. When you add an exe (which uses DLLs from its directory), Flatpak adds a portal to the selected exe only, and the DLLs don't get mounted. So, when you launch the program, it can't find any DLLs.

I found a fix by specifying the directory in Change Launch Options... > Working Directory (effectively, mounting the whole dir). Then I opened the bottle configuration in ~/.var/app/com.usebottles.bottles/data/bottles/bottles/<name-of-the-bottle>/bottle.yml and changed the value of External_Programs.<id>.path to the mounted dir (should be in /run/user/1000/doc) with the filename of the executable at the end.

This isn't user-friendly, and I think this issue should be reopened. I think the best solution would be to add a separate option in Bottles for adding portable programs where the file chooser would ask for a folder, and you would select an exe afterwards. It would also be nice to be able to change the executable path of an already added program in the UI.

What do you think, @mirkobrombin?

@Fredolx, I think this page answers your question: https://docs.usebottles.com/flatpak/expose-directories

[dronkit]

I vote for reopening this issue. It's not fixed. It's a major one, which prevents any windows program that has more than one executable file from running.

In my case, apparently the directory /run/user/1000/doc/59edc372 is created, with only the executable file, and the directory /run/user/1000/doc/792541a3 is created with the game folder inside, with all its files and subfolders. But Bottles runs the executable in the first directory, logically missing dlls and subfolders.

I tried messing with the working directory and the bottle.yml file but there's no use. Bottles seems to run the executable in /run/user/1000/doc/59edc372, which is alone, regardless of what it says in the bottle.yam.

Initially, it only says, in the external_programs section: path: /run/user/1000/doc/59edc372/Unusual Findings.exe

When I set the working directory, another line appears: folder: /run/user/1000/doc/792541a3/Unusual.Findings.v1.0.24 but the path remains the same: path: /run/user/1000/doc/59edc372/Unusual Findings.exe then apparently the program runs, but I get another error because it expects more subfolders: Application folder: Z:/run/user/1000/doc/59edc372 There should be 'Unusual Findings_Data' folder next to the executable

I can see that /run/user/1000/doc/59edc37 contains only the executable and /run/user/1000/doc/792541a3 contains the game directory with everything.

Then I manually change the path to path: /run/user/1000/doc/792541a3/Unusual Findings.exe and I get the same error

Bottles seems to run the executable that is alone in its own folder regardless of what bottle.yam says.

As other users proposed, this "bridging" should be more transparent so the program is run in its own folder, with all its files, or at least the select folder, then select file approach.

@jul1u5 did I get your workaround right? is what I described above what you did to make it work? Or am I doing something wrong? Thanks!

[dronkit]

I was able to run the game normally by copying the whole game folder into the bottle's drive C (~/.var/app/com.usebottles.bottles/data/bottles/bottles//drive_c/games), then creating a shortcut and browsing there. Evidently Bottles has access to that directory and doesn't need to do any "bridging"

[JohnTheCoolingFan]

Also encountered this issue trying to run Cyberpunk. I have a dedicated folder for game files so I don't want to copy/move that into the bottle (but it's on btrfs either way so no additional space would be required). I think this issue needs to be reopened.

[biggestsonicfan]

Is this really not possible to reproduce, @mirkobrombin?

[mikelpr]

I was able to reproduce with garn47 and worked around successfully as @dronkit did. I also tried by binding garn47's folder to a drive (A:) and adding a program shortcut (in Bottles) to ~/.var/app/com.usebottles.bottles/data/bottles/bottles/Garn47/dosdevices/a:/garn47.exe (dosdevices/a: already being a symlink to a sandboxed view of garn47's folder) but this resulted in it also creating a sandboxed view of only garn47.exe, whereas adding a program shortcut to ~/.var/app/com.usebottles.bottles/data/bottles/bottles/Garn47/drive_c/(garn47 dir copied here) works just fine

EDIT: just saw that the original report is not flatpak related, but the comment section went flatpak.

[foinf]

I was able to run the game normally by copying the whole game folder into the bottle's drive C (~/.var/app/com.usebottles.bottles/data/bottles/bottles//drive_c/games), then creating a shortcut and browsing there. Evidently Bottles has access to that directory and doesn't need to do any "bridging"

Thanks, this worked for me. I only had one game so it was easy to move. Just selecting drive_c as the working directory fixed it.