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$ Apr 3, 2020 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, 2020 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, 2020 at 11:54
  • $\begingroup$ @Szabolcs Thanks for you reply, I have removed the tag and updated the question. $\endgroup$ Apr 3, 2020 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, 2020 at 4:36

2 Answers 2


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$ Apr 7, 2020 at 2:11
  • $\begingroup$ Thanks for the confirmation, I expanded the answer with some more details. $\endgroup$
    – ilian
    Apr 7, 2020 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$ Apr 3, 2020 at 18:12
  • 1
    $\begingroup$ @Pei-XinShen what does Cryptography`$LibraryVersion return in both your FE and kernel? $\endgroup$
    – ktm
    Apr 3, 2020 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$ Apr 3, 2020 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$ Apr 3, 2020 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, 2020 at 4:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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