Compiled application does not run because of startup plugin libmwlmgrimpl.dll

I compiled a very simple application (R2017b) but it will not run. When I start it from the DOS prompt, it will return this message: "Fatal Internal Error: std::exception: Bundle#4 start failed: Loading C:\Program Files\MATLAB\R2017b\bin\win64\matlab_startup_plugins\lmgrimpl\libmwlmgrimpl.dll failed with error: The operating system cannot execute %1."

Sometimes it is recommended to reinstall Matlab, which I did, but to no avail. I searched around for any other answers, but I didn't really find anything.

What comes to my mind: Why would a standalone executable with Matlab Runtime installed look for license dlls? In fact, "lmgrimpl" looks like something very license manager related to me, which clearly shouldn't happen on a deployed standalone application?

[Walter Roberson]

As I look around and put together hints, I suspect that when a program is compiled, that the license entitlements of the user are copied into the .exe, and then at runtime, the license checks are gone through. There are too many things I could not explain under the hypothesis that the compiler simply does not compile in license checks.

For example, the number of nodes and cores usable under Distributed Computing depends upon the license at compile time: I figure that rather than going through special purpose code to check just that factor, that instead they just use the existing license management routine, passing it the license entitlements that could be fetched at compile time.

[Stefan]

Sounds like it is the way you put it, but why would the standalone exe look for a license that won't be there anyways on a PC where Matlab is not installed?

Answer 1

[Ben Drebing]

I have found, oddly enough, that this error can happen if you have out-of-date libraries, specifically ssleay32.dll and libeay32.dll, in your Windows System32 directory. If this is the case, you have two options:

1. Place a copy of MATLAB's SSLEAY32.DLL and LIBEAY32.DLL (from the bin\win64 directory) next to your standalone executable. The directory from which the application loaded has a higher priority than system32, so this should allow the application to use the DLLs which it needs, or
2. Remove SSLEAY32.DLL and LIBEAY32.DLL from the system32 directory; the standalone can then use the one included with MATLAB. This may break other applications however which rely on the DLL being in system32. So, alternatively you may want to update SSLEAY32.DLL and LIBEAY32.DLL in the system32 directory, for example by replacing it with the copies included with MATLAB or perhaps you could update the application which installed this DLLs in the first place, if you know which application this was.

[Stefan]

Putting those two libraries in the same directory as the application makes it work, thank you!

[Mark Goldfarb]

Worked for us.

[Tim Boxall]

Hi Ben.

This worked for me - thanks. Do you know why these particular libraries are the problem? How did you work it out?

Thanks,

Tim

[Marica dicamillo]

I had the same problem. Updating SSLEAY32.DLL and LIBEAY32.DLL in the system32 directory, my application makes it work. Thank you!