Update: Finally I found a clumsy way to solve this bug by myself: I created an alternate local kernel to run the code, and it surprisingly works out!

Alternating Local Kernel

It is ridiculous that two local kernels contain different features/bugs, I still cannot figure out the reason...

Recently when I evaluate


on Windows10 1909 with Mathematica 12.1 in the front-end, it warns me:

"12.1.0 for Microsoft Windows (64-bit) (March 14, 2020)"
Encrypt::libopenssl: Couldn't load OpenSSL library.

However, it works perfectly in the Wolfram Kernel 12.1 without errors. And everything is fine on a Linux machine of version 12.1, as well as the Windows in the front-end of version 12.0. Does anybody encounter the same problem with me?

I tried to dig more about the issue, the corresponding OpenSSL file lies in


or from the paclet


The warning comes from the command

checkedLibraryFunctionLoad[libraryPath, "scrypt", 
{{Integer, 1}, {Integer, 1}, Integer, Integer, Integer, Integer}, {Integer, 1}]


LibraryFunction::libload: The function scrypt was not loaded from the file $UserBasePacletsDirectory\Repository\Cryptography-12.2.0\Resources\Libraries\OpenSSLLink64.dll.

While the file OpenSSLLink64.dll already exists, I am not familiar with LibraryFunctionLoad, I hope someone can help me fix this problem.

Then I follow Szabolcs's suggestion to evaluate LibraryLink`$LibraryError and obtain the output: Library load error 127: 找不到指定的程序。 (The specified module could not be found). Although my Windows Language is Chinese, all the installed paths (including the user name) are in English.

Error Notifications

  • $\begingroup$ I installed 12.1 version of Mathematica on win10. I didn't get the error you said after running your code. $\endgroup$ – A little mouse on the pampas Apr 3 '20 at 3:03
  • $\begingroup$ Please do not use the bugs tag when posting new questions. Do add this tag to other people's questions when appropriate. Please see the tag description for more details. $\endgroup$ – Szabolcs Apr 3 '20 at 11:54
  • 1
    $\begingroup$ Can you reproduce this after restarting Mathematica? If yes, please evaluate LibraryLink`$LibraryError immediately after the error and add the result to the question. $\endgroup$ – Szabolcs Apr 3 '20 at 11:54
  • $\begingroup$ @Szabolcs Thanks for you reply, I have removed the tag and updated the question. $\endgroup$ – Pei-Xin Shen Apr 3 '20 at 13:30
  • 1
    $\begingroup$ See my comment under the other question. We should have a fix for this in the form of a paclet update soon. $\endgroup$ – ilian Apr 5 '20 at 4:36

A likely fix for this issue has been released with the CURLLink 12.1.1 paclet update.

This update will not be automatically installed, but can be acquired by evaluating

PacletSiteUpdate /@ PacletSites[];

and restarting Mathematica.

If anyone is curious, here are some comments on the symptoms being observed.

As mentioned in the question, there was an error in loading the library function scrypt:


The function scrypt was not loaded from the file ... OpenSSLLink64.dll.

There is nothing special about that symbol, it just happens to be the first one attempted.

Furthermore, it is not missing from OpenSSLLink64.dll and the latter library is not corrupt in any way, but it does fail to load, so none of its symbols can be found.

The problem is not with OpenSSLLink64.dll but with its main dependency, the OpenSSL library libcrypto-1_1-x64.dll.

Normally it would be dynamically loaded from the Mathematica layout, specifically from the SystemFiles\Libraries\Windows-x86-64 directory and everything would work correctly.

But under certain circumstances, another instance of the library present on the system (most likely installed in a system-wide location like C:\Windows\System32) can be found under the standard Windows DLL search order.

It is also likely to be incompatible with OpenSSLLink because it has been compiled with a different set of enabled features, which results in the error seen.

This will not be the case for most Windows installations (and clearly it was not the case for any of the systems used in release testing).

What is the relevance of CURLLink and how can updating that paclet fix the problem? It turns out that one of libcurl's several dependencies can indirectly load libcrypto-1_1-x64.dll by relying on the OS to locate it.

This happens early in the session, especially when the FE is used, for purposes such as checking for paclet updates or signing in to the cloud.

By the way, that also explains the differences seen in a standalone kernel, or in an alternative local kernel, which happen to be initialized in a slightly different way.

Fortunately, this problem is easy to fix by explicitly preloading the above dynamic dependency from its correct location instead of asking the OS for it.

  • $\begingroup$ Thanks a lot! I have checked this bug is perfectly fixed! $\endgroup$ – Pei-Xin Shen Apr 7 '20 at 2:11
  • $\begingroup$ Thanks for the confirmation, I expanded the answer with some more details. $\endgroup$ – ilian Apr 7 '20 at 2:57

The error message

LibraryFunction::libload: The function scrypt was not loaded from the file C:\Users\[MYNAME]\AppData\Roaming\Mathematica\Paclets\Repository\Cryptography-12.2.0\Resources\Libraries\OpenSSLLink64.dll.

suggests that the library downloaded to your $UserBasePacletsDirectory is corrupt in some manner.

I would recommend running SystemOpen@$UserBasePacletsDirectory, going to the /Repository/ subdirectory, and deleting all directories that start with Cryptography. Restart Mathematica, try the functionality again, and see what happens. Hopefully it will work.

I've checked the .dll within the same paclet installed on my Windows machine and it doesn't seem to have this issue the scrypt symbol is present.

If the above does not work, alternatively you can copy OpenSSLLink64.dll from $InstallationDirectory\SystemFiles\Components\Cryptography\Resources\Libraries to your C:\Users\[MYNAME]\AppData\Roaming\Mathematica\Paclets\Repository\Cryptography-12.2.0\Resources\Libraries\. Barring any sort of corruption, the .dll at both of these locations should be near identical in content.

  • $\begingroup$ Thanks for your answer :) The first suggestion does not work, and I have checked the two OpenSSLLink64.dll are exactly the same. Besides I tried to run GenerateAsymmetricKeyPair[] directly in the Kernel and found surprisingly no errors !!! While evaluating in the front-end fails, which makes me very puzzled. $\endgroup$ – Pei-Xin Shen Apr 3 '20 at 18:12
  • 1
    $\begingroup$ @Pei-XinShen what does Cryptography`$LibraryVersion return in both your FE and kernel? $\endgroup$ – ktm Apr 3 '20 at 18:58
  • $\begingroup$ The front-end still returns Encrypt::libopenssl: Couldn't load OpenSSL library. $Failed, while the kernel gives OpenSSL 1.1.1d 10 Sep 2019. I also try PacletObject["Cryptography"]["Version"], and they both returns 12.2.0. @ktm $\endgroup$ – Pei-Xin Shen Apr 3 '20 at 19:03
  • 2
    $\begingroup$ For the default local Kernel, it fails and returns Library load error 127, as illustrated in the question. But it is weird that when I create another local kernel, everything runs perfectly there (shown in my updated figure). $\endgroup$ – Pei-Xin Shen Apr 3 '20 at 20:23
  • 1
    $\begingroup$ The "missing procedure" that error 127 refers to is not scrypt but something else. And while OpenSSLLink64.dll fails to load, the problem isn't in the DLL itself. $\endgroup$ – ilian Apr 5 '20 at 4:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.