SSL - Could not load SSL functions .. API Error = 126

[Stu]

Hi Folks,

First things.

http://www.nettalkcentral.com/index.php?option=com_smf&Itemid=36&topic=5696.0
http://www.nettalkcentral.com/index.php?option=com_smf&Itemid=36&topic=4406.0

Have gone over both of these.

Now, to the problem.

With tonight's build, the following error occurs:

Code: [Select]

[596] [NetDLL] [1] RunTimeLoadProcedures_SSL() : Warning. Could not load SSL functions (libeay32.dll, ssleay32.dll, libssl32.dll, msvcr90.dll). API Error = 126
Checks:

* All four files are there, and they are the same ones that were there previously today before I installed this latest build.
* The difference is I upgraded Nettalk to 8.55 - am not saying this is the cause, just that it's what changed.
* This does not happen on my dev machine, only on the live server. IMPORTANT

Screenshot of the debugview log attached.

* I've also tried removed the msvcr90.dll file and making sure of the 2008 runtime install. Neither things (or a combination of removing/having the dll in the folder) solved this issue.

Any ideas?

Stu

[attachment deleted by admin]

[Bruce]

Hi Stu,

there was an OpenSSL update with the 8.55 build, so you'll need to deploy the SSL DLL's, but I think you've done that.
On the server, where it's broken, right click on each of the 3 SSL DLL's (ie not the MS one), go to the details tab, and check the "version" there. It should be
1.0.2d
for all 3 of them.

>> All four files are there, and they are the same ones that were there previously today before I installed this latest build.

3 of them were updated with the latest build, so they shouldn't be the same as before.

Cheers
Bruce

[Bruce]

make sure when you copy the new DLL's over that they actually "write" - if the files are in use on the server side then the new versions won't write over.

Incidentally any version of the DLL's is fine, as long as they're all the same version - I think in your case maybe 1 file is updated but another is not.

cheers
Bruce

[Stu]

Hey Bruce,

Okay. Just checked. All 3 files are 1.0.2d.

Is there anything about the "api error = 126" that gives any indication of the issue?

It's probably a long shot, but I'm trying now with a rebuild using NT 8.54 (regress from 8.55).

Stu

[Stu]

Hey Bruce,

So.

NT 8.54 build, no worries. Live server has no problem loading the 1.0.2c ssl dlls (introduced in 8.52 the docs say).

Very strange.

Could it be something in the new ssl dlls that doesn't work on a particular windows? Am running win 2008 R2 64bit.

[Bruce]

Have you tried 8.55 (or 8.56) with the 2c Dlls?
That would at least narrow it down a bit

>> Could it be something in the new ssl dlls that doesn't work on a particular windows?

anything is possible - but I have (successfully) deployed at least 1 site with the 2d DLL's...

cheers
Bruce

[astahl]

Stu,

Did you try the ssl dll's 1.02c? did they work?


Ashley

[astahl]

Hi Bruce and Stu,

Bruce I tried the suggestion you had given to Stu on trying the 1.02c dll's and happy    to report the website now works in SSL mode.

Now my only question why don't the 10.2d OpenSSL dll's work? I also am running on a WIN 2008 R2 64bit server.


Ashley

[Stu]

Great news Ashley! Gives me confidence .. Will give it a try this week sometime hopefully.

[Stu]

Hi Folks,

Can confirm that with last night's build (upgraded to Nettalk 8.56 from 8.53 I think) on the win 2008 R2 64bit server with the 1.02c dlls the SSL webserver works fine.

Stu

[Bruce]

Turns out the "D" DLLs have changed the dependency from MSVCR90.DLL to MSVCR120.DLL. I've updated the install, and docs, for 8.57 to reflect this.

aside: MS recommended that the MSVCR90.DLL be installed using their redistributable installer. By contrast the MSVCR120 DLL should be installed with your app (which is what most folks did with the MSVCR90 DLL anyway.)

Cheers
Bruce

[Larry Sand]

MS can be so awesome in that respect.... L

[Bruce]

ha ha - not MS's fault in this case though. I didn't spot the OpenSSL change (which to be fair is not even an OpenSSL change, but a change by the person compiling it for windows.)

On the DLL distribution front MS seem to have recognized that saving disk space is no longer a goal - application reliability is.

cheers
Bruce

[astahl]

Thanks Bruce for the update and fix.


Ashley