Failed to load mumble_ol.dll in 248-g640b532 snapshot on Windows

[bill-long]

After updating to the 248-g640b532 snapshot, I'm getting the error indicating that mumble_ol.dll couldn't load:

Process Monitor shows that it does open the mumble_ol.dll, but after that it starts looking for mumble_ol.dll.dll for some reason (notice the extra .dll).

This behavior does not occur if I uninstall the snapshot and run 1.2.5 - neither the error dialog, nor the looking for mumble_ol.dll.dll is observed in that version.

I'm not entirely sure what build this started with, as I hadn't updated my snapshot in some time.

[Tarun80]

I can confirm this on different machines. It happened on the laptop I have at build 227.

I very recently (Start of February) did a clean install on my primary computer and experienced the same error dialog.

I was able to stop this message from occurring when I:

• Installed 1.2.4 (before 1.2.5 was out)
• Ran Mumble
• Started up any game that used the overlay

After that I went to the latest snapshot at the time (227) and I have never had that error occur since.

I also tried Compatibility mode using several different OS versions on the laptop and nothing changed.

Laptop and primary computer are both Windows 7 x64.

[hacst]

Interesting. A few questions to try to narrow this down:

• Did you install mumble into a non-standard directory?
• I assume the file is actually present next to the .exe?
• Did the installation warn about not being able to close some applications? If so did you ignore it when updating?
• @Tarun80 So this occurred without any previous Mumble installation on the system?

The behavior @bill-long mentions (.dll.dll) is consistent with what is documented QLibrary would do if it isn't able to load the file with the explicit name we give it (mumble_ol.dll).

"If the file cannot be found, QLibrary tries the name with different platform-specific
file suffixes, like ".so" on Unix, ".dylib" on the Mac, or ".dll" on Windows and Symbian."
-- http://qt-project.org/doc/qt-4.8/qlibrary.html

I guess binary incompatibility or permission problems would be two possible candidates.

[bill-long]

Oddly, Process Monitor does show it successfully opening the DLL. It's definitely not something with the folder, because I can fix it by just uninstalling the snapshot and installing 1.2.5. Then I can reproduce the problem by uninstalling 1.2.5 and installing the snapshot again.

Here's a video where I start with a working install of 1.2.5, uninstall, install the snapshot, get the error, uninstall it, install 1.2.5 again, and it works:

Video

You can see that literally all I'm doing is removing one version and putting the other on. Same folder, same everything, but the snapshot says it can't find the DLL, which is right there in the folder.

BTW if the video looks fuzzy just click the Download link at the top left. It'll probably look better if you play it back locally.

[Tarun80]

@DD0t: Correct. A completely clean install, went to install the snapshot and received the error. I use the snapshots for the overlay in games such as Guild Wars 2.

It was installed into the default directory, nothing was changed, only the client was installed.

[fang64]

Hello Everyone,

I'd like to confirm this issue as well, I am installing to the default location as well, and this is Windows 7 64-bit. I did attempt to uninstall the snapshot and go to the 1.2.5 stable and then go back to the snapshot. I can confirm that the mumble_ol.dll from the 1.2.5 stable does work if that is a good starting point.

[clucky]

I am too experiencing this issue. Using Windows 8 (overlay library didn't work on version 1.3.x). The overlay doesn't work, as well as the error message occurring.

[hacst]

Also occurs with Windows 10. Pretty sure it's the same issue.
Checking the DLL with depends32 shows that on Windows 10 we lack D3DCOMPILER_43.DLL which the overlay statically depends on. Hence it won't load.

Apparently it would be our task to ship that dll (http://msdn.microsoft.com/en-us/library/windows/desktop/ee663275.aspx << search for D3DCOMPILER_xx). Installing a legacy DX would very likely resolve this issue too. Not sure how this works licensing wise...

On most gamer/older systems it is very likely the old directx versions have been installed by another application/game which would explain why we don't see this issue very often.

Maybe newer windows ships with a more recent version we could use (delayload). Might not be the best idea if they keep revving versions in the future.

[mkrautz]

I've landed a fix for x64:
a88b316

We can't ship D3DCompiler_43.dll ourselves, as it's not exposed on the filesystem in the D3D9 SDK...

We should investigate delayload for x86.

[mkrautz]

I have a patch that delayloads for x86.

See mkrautz@2f86ebd

@hacst @Kissaki thoughts?

I haven't run-tested this yet, but it's a start...

[hacst]

Definitely better than popping up an error. However I'm not sure sure what you mean with we can't ship the compiler dll from DX9 because it's not in the filesystem. Doesn't sound like a big barrier to me. Firefox also ships with D3DCompiler_43.dll and d3dcompiler_46.dll . I'd imagine if you install the legacy runtime on the builder it should be available in the systems directories.

[mkrautz]

I just checked whether it was present in the DX SDK dir, and it was not. I expected it to be in a CAB file or something.

We should investigate this closer, then. You're right, it's probably in a system dir. If nothing else, we can extract it from from the cab files in the DX SDK dir in the build env setup...

[mkrautz]

Gotcha.

‪C:\Windows\System32\D3DCompiler_43.dll for x64
C:\Windows\SysWOW64\d3compiler_43.dll for x86

[mkrautz]

Landed 29525cb for d3dcompiler_43.dll on x86.

[mkrautz]

I have yet to test this on fresh machines. I will leave it open until we have confirmation...

[hacst]

Awesome. Looks good to me.

[hacst]

Tested on a clean system. Seems to work.