Player build: fmodstudioL.dll not found (in wrong folder)

Unity
#1

Hi,
We’re using Unity 2019.3.1f1 and FMOD plugin 2.00.07.
I’m not sure what’s made this problem begin - probably updating unity, but we were using the 2019.3 beta and didn’t have any trouble there.
When starting our game we get the following errors:

Fallback handler could not load library C:/isaac/mm-bitbucket/ce2/Tools/jenkins/output/CE2_Data/Mono/fmodstudioL
Fallback handler could not load library C:/isaac/mm-bitbucket/ce2/Tools/jenkins/output/CE2_Data/Mono/fmodstudioL.dll
Fallback handler could not load library C:/isaac/mm-bitbucket/ce2/Tools/jenkins/output/CE2_Data/Mono/fmodstudioL
Fallback handler could not load library C:/isaac/mm-bitbucket/ce2/Tools/jenkins/output/CE2_Data/Mono/libfmodstudioL
Fallback handler could not load library C:/isaac/mm-bitbucket/ce2/Tools/jenkins/output/CE2_Data/Mono/libfmodstudioL.dll
Fallback handler could not load library C:/isaac/mm-bitbucket/ce2/Tools/jenkins/output/CE2_Data/Mono/libfmodstudioL
Fallback handler could not load library C:/isaac/mm-bitbucket/ce2/Tools/jenkins/output/CE2_Data/Mono/fmodstudioL
Fallback handler could not load library C:/isaac/mm-bitbucket/ce2/Tools/jenkins/output/CE2_Data/Mono/fmodstudioL.dll
Fallback handler could not load library C:/isaac/mm-bitbucket/ce2/Tools/jenkins/output/CE2_Data/Mono/fmodstudioL
Fallback handler could not load library C:/isaac/mm-bitbucket/ce2/Tools/jenkins/output/CE2_Data/Mono/libfmodstudioL
Fallback handler could not load library C:/isaac/mm-bitbucket/ce2/Tools/jenkins/output/CE2_Data/Mono/libfmodstudioL.dll
Fallback handler could not load library C:/isaac/mm-bitbucket/ce2/Tools/jenkins/output/CE2_Data/Mono/libfmodstudioL
DllNotFoundException: fmodstudioL
  at (wrapper managed-to-native) FMOD.Memory.FMOD5_Memory_GetStats(int&,int&,bool)
  at FMOD.Memory.GetStats (System.Int32& currentalloced, System.Int32& maxalloced, System.Boolean blocking) [0x00001] in C:\isaac\mm-bitbucket\ce2\Assets\Plugins\FMOD\src\Runtime\wrapper\fmod.cs:788 
  at FMODUnity.RuntimeUtils.EnforceLibraryOrder () [0x00001] in C:\isaac\mm-bitbucket\ce2\Assets\Plugins\FMOD\src\Runtime\RuntimeUtils.cs:404 
  at FMODUnity.RuntimeManager.get_Instance () [0x00109] in C:\isaac\mm-bitbucket\ce2\Assets\Plugins\FMOD\src\Runtime\RuntimeManager.cs:103 
Rethrow as SystemNotInitializedException: [FMOD] Initialization failed
  at FMODUnity.RuntimeManager.get_Instance () [0x00148] in C:\isaac\mm-bitbucket\ce2\Assets\Plugins\FMOD\src\Runtime\RuntimeManager.cs:113 
  at FMODUnity.RuntimeManager.get_StudioSystem () [0x00001] in C:\isaac\mm-bitbucket\ce2\Assets\Plugins\FMOD\src\Runtime\RuntimeManager.cs:127 
  at FMODUnity.RuntimeManager.GetBus (System.String path) [0x00001] in C:\isaac\mm-bitbucket\ce2\Assets\Plugins\FMOD\src\Runtime\RuntimeManager.cs:1058

The dll is there in the player build at the path
CE2_Data/Plugins

But if I manually copy the dlls to
CE2_Data/Plugins/x86_64

Then the problem doesn’t happen.

#2

Having the same problem here. Except I’m on 2019.2.19f1 with FMOD 2.00.07.

I wasn’t having any problems with Unity 2017.4 and 2018.4, but 2019.2 doesn’t seem to load the fmod plugins at all. I would prefer not having to manually move .dll’s after a build.

Can also confirm moving them to x86_64 folder makes the plugins work.

Hoping we can get some help.

#3

Update: As a temporary fix, I’m using this script to move the .dll files automatically. The script is quick and dirty but I’m not too informed on what else there is to do in this situation.

https://www.paste.org/103088

using System.IO;
using UnityEngine;
using UnityEditor;
using UnityEditor.Callbacks;
 
public class fmod_dll_fix
{
 
    //Callback to the build path.
    [PostProcessBuildAttribute(999)]
    public static void OnPostprocessBuild(BuildTarget target, string pathToBuiltProject)
    {
        var fixedPath = pathToBuiltProject.Replace(".exe", "_Data/Plugins");
        var newDllPath = Path.Combine(fixedPath, "x86_64");
 
        string[] dllsToMove = new string[]
        {
            "fmodstudio.dll",
            "fmodstudiol.dll",
            "resonanceaudio.dll"
        };
 
        foreach (var dll in dllsToMove)
        {
            var oldPath = Path.Combine(fixedPath, dll);
            var newPath = Path.Combine(newDllPath, dll);
            File.Move(oldPath, newPath);
 
            Debug.Log(string.Format("Moved {0} from old path: {1} to new path: {2}", dll, oldPath, newPath));
        }
    }
}
2 Likes
#4

So it looks like this was actually caused by the Burst package, and they just released a fix:

https://docs.unity3d.com/Packages/com.unity.burst@1.2/changelog/CHANGELOG.html

1.2.3: Fix a regression that could break usage of native plugins.

1 Like
#5

I had this issue as well but I’m not using Burst, it did however crop up when I added a package from a git url, not sure how or why that is though.

The quick fix posted above worked for me (post-process copy to correct location) and I don’t have time to properly investigate right now.

#6

I’d also like to report that the same issue is happening to me.
Thanks to @nickstevens000 for that workaround. However, I actually had to keep resonanceaudio in the Plugins folder, strangely.

Currently using: Unity 2019.2.17f1, FMOD 2.01.01

For us, a bunch of Firebase dlls get automatically placed in the Plugins\x86_64 folder, so I’m wondering why that doesn’t also happen for the FMOD dlls.

#7

If you do not already have the FMOD Integration in your project, Assets/Plugins/FMOD is the base folder for the plugin and the dlls should be in Assets/Plugins/FMOD/lib. Otherwise if you are updating FMOD from a newer .unitypackage, it will find replace the files it finds (using the meta files data) without changing their current location.