New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide additional information when LoadLibrary/dlopen fails #2086

SamVanheer opened this Issue Jan 8, 2019 · 2 comments


None yet
2 participants
Copy link

SamVanheer commented Jan 8, 2019

A common problem when trying a new mod is that the mod's client dll has missing dependencies.
Unfortunately there is no easy way to test for this, and the only information that the game provides is a Could not load library <name> error.

The cause of the problem should be logged to the debug log so this can be more easily resolved.

On Windows, GetLastError can be used to get the error code for a failed LoadLibraryA call. See the documentation for LoadLibrary for more information:

On Linux, the function dlerror will return the cause of the last failed dlopen call. See the documentation for more information:

Note that the error should be logged before the Sys_Error call, since that function calls exit and does not return.

Also note that the client dll may be loaded in 2 different places, so both should log the error. The server dll load failure code already logs the error code (Windows) or the error message (Linux) so the same code can probably be reused.


This comment has been minimized.

Copy link

tschumann commented Jan 9, 2019

Ah, this would be a huge help. From time to time I get this error reported with my mod and have never realised it could be a dependency issue.
On Linux I guess ldd can be used to diagnose it and I guess on Windows Dependency Walker is the best solution? Seems like Windows doesn't have anything built in.


This comment has been minimized.

Copy link

SamVanheer commented Jan 9, 2019

Dependency Walker can do it, though it failed to resolve the SDL2 library because checking dependencies for a dll uses its directory as the working directory, instead of using the engine executables' directory.

It also isn't obvious when a dependency is missing unless you run the tool on the user's computer. I ended up using Process Monitor to see which dll load attempts failed. It turned out that the client dll was a debug build, and had the debug version of the VS 2017 runtime as a dependency, which isn't part of the redistributable.

The error given when a library fails to load for this reason is code 126, which can mean anything since it doesn't specify which module fails to load. Still, if it were an other error you could tell much faster.

To find the error code i made a small tool that does exactly what i proposed here. Such a tool needs to be in the same directory as the engine executable to handle search order correctly so that it can find the SDL2 library. You can get it here:

Uses Dot Net Framework and WPF, so make sure that's installed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment