Trying to load a DLL - GetDllHandle fails

Development Programming & Scripting C++
1

I created a DLL using this tutorial: Here

I followed it exactly, with the only difference being this line:


FString filePath = FPaths::Combine(*FPaths::GameDir(), TEXT("Binaries/Win64/"), TEXT("UnrealScreenshotDLL.dll"));

When debugging I can see that the path is correct, but the code fails on this line:


DLLHandle = FPlatformProcess::GetDllHandle(*filePath);

I’ve tried both 32 and 64 bit files but still no joy. For some reason I am unable to step through the code as the breakpoints in ‘GetDllHandle’ are not triggered.

Would appreciate any help with this as I have been stuck on it for hours now. Is there anything else I could be missing?

Thanks,

Jamie

1 Like
2

Linking the same dll every time a blueprint node is called is kinda stupid practice imo.
Would be better use LoadLibrary() at plugin startup and unload it when module shutdown.

3

Hi BrUnO,

Yep, that is what I intend to do. But I can’t go that far at the moment until I can get Unreal to load the DLL in the first place.

4

hi jamiewhite your dll path is right? check with FPaths::FileExists(), anyway you can move your dll inside the binary folder “64 or 86” what ever you need, so the name can be found by this approach:



FString dllName = "whatever.dll";
void* dllhandle = FPlatformProcess::GetDLLHandle(*dllName);

this even works within a plugin, if you paste your dll file inside the binaries folder

5

Hey,

Yes, the file is definitely in the right place and is being found. If I remove the file, the FPaths::FileExists() flag fails. At the moment I am sending in the full path into “GetDLLHandle.” Based on your reply, can I just send in the filename instead minus the path?

6

You could try finding out what “FPlatformProcess::GetDLLHandle(*dllName);” actually calls and then look up the function.

The parameter might require an absolute path to the DLL, AFAIK Win32 LoadLibrary does not require absolute paths.

HTH

7

UE4 will setup the PATH environment variable to find the dll, so if it’s in your game binaries Win64 folder, you should be okay with just the filename. That said, I would expect a full path to work too. It’s kind of hard to help though when you don’t explain what you mean by ‘the code fails’.

If you’re invoking GetDllHandle directly yourself, and it’s not actually crashing at that point (I don’t see anything that it could crash on), you could follow it with a call to ::GetLastError, which should give info on why LoadLibrary failed, if that is in fact what is happening.

8

This is my code:



void *DLLHandle;
DLLHandle = FPlatformProcess::GetDllHandle(*_dll); // Retrieve the DLL.
		
if (DLLHandle != NULL)
{
     // Do stuff
}
else 
{
     // Error Message
}

First, there is a check to see if the file exists which passes fine. The issue is the GetDllHandle part. I have set the “_dll” variable as both the file on its own and the full file path. At the moment, it is failing at the != NULL part. When stepping through, I am unable to see what’s happening because function is always skipped over (the breakpoints aren’t firing).

“GetLastError” isn’t a part of the FPlatformProcess class - where is it called from?

9

GetLastError is a Windows API function. If you’re working on Windows, you should just be able to call it directly.

That explains how to format the result into a meaningful error message.

To be able to step through engine code properly, you need to be using a source build of the engine from Github, and build it in the ‘Debug Editor’ configuration.

10

I am by no means an expert at this but I managed to fumble my way through it. What worked for me was putting the DLL into my plugin’s Binaries directory, adding the header files to the project and including the lib at build time with the following in my Build.cs file:


PublicAdditionalLibraries.Add(Path.Combine(LibraryPath, "Win64", "mylib.lib"));

After this the DLL pretty much worked automatically, there was no need to call GetDLLHandle(). This was for an editor plugin though, so I’m not sure if a compiled game would need a different approach.

Also, you don’t necessarily need to build your own copy of the engine, just check the source out and add it to your project instead of the default UE4 project. Don’t build it, just let the normal processes run and leave it there for reference. The caveat is that while you can step through the code it’s executing, the breakpoint has to be triggered from within your own code.