Compiled application does not run because of startup plugin libmwlmgrimpl.dll
62 visualizzazioni (ultimi 30 giorni)
Mostra commenti meno recenti
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?
2 Commenti
Walter Roberson
il 17 Dic 2017
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.
Risposte (1)
Ben Drebing
il 20 Dic 2017
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:
- 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
- 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.
4 Commenti
Tim Boxall
il 3 Mag 2019
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
il 3 Ott 2019
I had the same problem. Updating SSLEAY32.DLL and LIBEAY32.DLL in the system32 directory, my application makes it work. Thank you!
Vedere anche
Categorie
Scopri di più su Startup and Shutdown in Help Center e File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!