Search Unity

Question Application looks for plugins in "[ProjectName]_Data/Mono" or "[ProjectName]_Data/MonoBleedingEdge"

Discussion in 'Windows' started by mfs28112, Dec 22, 2022.

  1. mfs28112

    mfs28112

    Joined:
    Dec 23, 2021
    Posts:
    8
    When I build my project (Windows standalone) and run it on my PC, everything works fine. However, on some other PCs, a native plugin (which I wrote) used in the project fails to load with the message:

    Fallback handler could not load library [Path to build directory]/[ProjectName]_Data/Mono/[Plugin Name].dll​

    However, this "Mono" directory under the data folder doesn't exist, and the plugin and its dependencies are in the [Project Name]_Data/Plugins/x86_64 directory as always.

    I believe this issue is the same as described in https://forum.unity.com/threads/missing-mono-folder-in-build.923210/. I have already tried a clean checkout, rebuilding the library, and reinstalling Unity. It still works on some PCs but not others (and on PCs where it fails, it fails across all user accounts and it fails consistently every single time the application is run). This was with Unity 2020.3.23f1.

    I also tried upgrading the Unity version to 2021.3.16f1. The same problem occurs, except that instead of [ProjectName]_Data/Mono it looks for the plugin in [ProjectName]_Data/MonoBleedingEdge, which also does not exist.

    Has anyone experienced this problem before or know what causes it? Earlier versions of this project worked as expected on the PCs in question and it is unclear to me where to start looking for the change that broke it.
     
    mfs28112, Dec 22, 2022
    #1

  2. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,674
    It will look in those folders if loading the from the regular location fails. The fact that it works on your machine but not on some other machines suggests to me that your native plugin depends on another DLL (most likely dynamically linker Visual C++ runtime) that you didn't include with the plugin and it just happens to be installed on your system.

    You can check what other DLLs your plugin depends on with Dependencies: https://github.com/lucasg/Dependencies/releases
     
    Tautvydas-Zilys, Dec 22, 2022
    #2

  3. mfs28112

    mfs28112

    Joined:
    Dec 23, 2021
    Posts:
    8
    We already checked for missing dependencies--all clear. In addition, if we substitute the entire [Project Name]_Data folder from the non-working build into an older, working build located on the same PC, the application runs as expected (the dll loads correctly), so I don't think there is a dependency missing.
     
    mfs28112, Dec 22, 2022
    #3

  4. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,674
    Would you be able to share the [Project Name]_Data/Plugins folder of a non-working build?

    Do you have access to a computer where it doesn't work in order to do some debugging?
     
    Tautvydas-Zilys, Dec 23, 2022
    #4

  5. mfs28112

    mfs28112

    Joined:
    Dec 23, 2021
    Posts:
    8
    I cannot share the Plugins folder. I do have access to a computer where it doesn't work. For now, we were able to resolve the problem by removing a dependency of the native plugin, though it's unclear why that worked since the dependency is in the [Project Name]_Data/Plugins folder anyway.
     
    mfs28112, Dec 23, 2022
    #5

  6. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,674
    If you can reproduce it, you can enable "loader snaps", which is basically the Windows DLL loader dumping all diagnostics information into the debugger output:

    1. Install Windows SDK with "Debugging tools for Windows" component from https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/ on a computer where you cannot reproduce it (installing Windows SDK might change the reproducibility);
    2. Go toC:\Program Files (x86)\Windows Kits\10\Debuggers\x64, find gflags.exe and copy to a machine where the issue is reproducible;
    3. Open admin command prompt
    4. Type "gflags.exe -i <game_exe_name>.exe +sls". Note that "<game_exe_name>" is just the name, not the full path to the executable;
    5. Run the game under a debugger. Either a Visual Studio remote debugger or WinDbg downloaded from the Windows Store would do (do not install Visual Studio on the machine as it can also affect reproducibility).
    6. Look at the debugger output. It should tell you exactly why it cannot load the DLL.
    7. When done, disable loader snaps with "gflags.exe -i <game_exe_name>.exe -sls".
     
    Tautvydas-Zilys, Dec 23, 2022
    #6

  7. mgoemmel

    mgoemmel

    Joined:
    Sep 16, 2022
    Posts:
    10
    I've builded a Windows standalone version, trying to run it with gflags, which not immediately worked, but instead I mentioned that in the Player.log I find

    Fallback handler could not load library C:/Users/mgoemmel/Desktop/outWin/True Backgammon_Data/MonoBleedingEdge/bgblitz_win.dll
    ...
    Fallback handler could not load library C:/Users/mgoemmel/Desktop/outWin/True Backgammon_Data/MonoBleedingEdge/bgblitz_win.dll
    DllNotFoundException: bgblitz_win.dll assembly:<unknown assembly> type:<unknown type> member:(null)

    while in my project directory the dll is located at

    C:\Users\mgoemmel\Desktop\outWin\True Backgammon_Data\Plugins\x86_64\bgblitz_win.dll

    I guess this would be the reason that the dll could not be loaded. Any ideas what I'm doing wrong here?

    Thanks and regards

    Markus
     
    mgoemmel, Dec 28, 2022
    #7

  8. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,674
    You need to run under a debugger to see gflags output. It will not show up in the log.
     
    Tautvydas-Zilys, Dec 28, 2022
    #8