No announcement yet.

[Bug?] DLLBind binds fine on UnrealFrontend but fails when running the Engine

  • Filter
  • Time
  • Show
Clear All
new posts

    [Bug?] DLLBind binds fine on UnrealFrontend but fails when running the Engine

    So this is what happened. I have two DLLs:
    • one for DllBind which worked perfectly fine and has been used before, written by me (CustomDll);
    • another (not related with UDK) which exposes an API through dllexport to communicate with a glove device I have (GloveDll).

    Today I added some new calls to the GloveDll on my CustomDll and the VisualStudio compiler didn't complain. Then I copied the created dll to the Binaries\Win32\UserCode directory of UDK, made small changes in my UnrealScrips and recompiled everything with Unreal Frontend. Only one error stating the GloveDll was missing, which was fixed by also copying it to the UserCode directory. After recompiling, zero errors/warnings. So far it makes sense from a developer's perspective :P

    Then, when I started the engine and ran the game to see if everything was okay, the dll functionality wouldn't work at all (including those unrelated to the glove code). On the log console it also that DllBind failed.

    After spending a whole afternoon implementing explicit linking to the GloveDll inside my CustomDll and managing to put it to work, I also found out that only copying the GloveDll to the system32 directory fixes all these problems.

    In short:
    • copying the dll to the UserCode directory seemed okay on Unreal Frontend but when running the engine it didn't work and printed error messages - lack of coherency here :P
    • it's only solved by copying the dll to the system32 directory.

    That's probably not a bug, one of our DLL's requires some other DLL's to be in the system32 folder as well


      I'm not an expert on DLL linking, but when I used it on other test projects in Visual Studio it was only necessary to have the GloveDLL in the exe directory, without the need to copy it to the system32 folder nor using explicit linking (i.e. using GetProcAddress calls at runtime). Not having that dll on the UserCode directory shows the same error message as it would happen on any other executable (created with VS, or DevC++ or anything else) where the exe couldn't find the dll.

      What I'm arguing here as the 'bug' is the lack of coherency when running both Frontend and the Engine if that dll is in the UserCode folder. Since this is a "static" linking issue, it should show the same behaviour when running either Frontend and the Engine - i.e. show the same error messages. Or at least not failing silently, since the messages only show up on the log. Maybe it's something related to the "working directory" of the dlls? (wild guess)

      Again, I just posted this because I consider it a bug (or at least an unwanted feature :P) and it's something that I believe that could be improved on UDK. I'm also hoping it can be useful to anyone else going through similar issues.

      Keep up the good work.