DLL error

Jul 23, 2009 at 7:02 PM

I'm just getting started with VixCOM to evaluate it for our needs, so pardon me if this is an obvious noob question best answered somewhere else. If that's the case, please redirect me to somewhere suitable.

That said, I get an error as soon as VIX.VIXCOMWrapper.Instance.Connect executes. A dialogue tells me: "The ordinal 110 could not be located in the dynamic link library SSLEAY32.dll." I understand that this is the OpenSSL library which I take it that VIX uses. Any thoughts as to why the error? If it helps, I seem to have four copies of this DLL on the machine: one in VMWare's install proper, one in its remote console utility, one as part of a Cisco VPN client and one as part of the nmap (http://www.nmap.org) package. These seem to be of various versions (with different sizes) and so it seemed not implausible that somehow the wrong one is being used, whence the error. If that seems to be case to anyone, what ought I to do to force the use of the correct one?

Coordinator
Jul 24, 2009 at 12:04 PM

Hi!

I think that the error message you get isn't related to my wrapper library, it seems to be a problem in the VIX API itself.

I found a thread on the VMware forums that also deals with SSLEAY32.dll: http://communities.vmware.com/thread/121310

The solution was to remove an old version of the dll from the windows\system32 directory, so you might try if this helps you too.

Best regards,
Alex

Jul 24, 2009 at 1:22 PM

I have lots of copies of that DLL but not in that location - and I just checked with WMI Studio - none of them are being loaded at start up either. Curious. I also am hesitant about removing the one for the VPN; I suppose I could disable the nmap one for the time being ...

I notice that the one in the VIX folders is different sized from the one in the VMWare directory itself ...

Jul 24, 2009 at 1:35 PM

I think I figured it out. My dinky test-frame app I use to test snippets of new code prior to developing more concretely loads the Cisco AnyConnect API at its launch as that was one of the first things I tested with it. It turns out that too uses a version of that DLL. Looks like that Windows is seeing that "it" is already loaded and refusing to load the new one for use with VIX and hence failing to find the relevant function when VIX needs it. So, we've discovered something interesting which might affect me later on ...

Coordinator
Jul 24, 2009 at 1:49 PM

Hm, interesting.

Looks like you have to find a version of the DLL that both apps like :-D

Best regards,
Alex