Nathan Wild

Indeed.. I was delighted to find a post about this, but even with the PE version set to 5.0, I am still getting "Not a valid Win32 application" on Windows 2000. Is there anything else that might cause this?

In case it is helpful, the system where this manifested for us was a Windows 2019 "essentials" server. The KB patch was not available for this OS, but I no longer care as the IPWorks component works fine 😉

In case anyone is curious... I moved over to using the N*Software TipwREST component for this and the issue does not manifest.

Does anyone know if KB5020435 fixes this issue on Windows Server 2019? Or is this a Win-10 specific thing? We are having no issues at all on Win11 and Windows Server 2022.

I DID remove this iCLS DLL, and I have confirmed that my application is loading and running without accessing it anything other than the two OpenSSL DLLs that come with the ICS distro. The same application works properly on another computer on the same network. Still perplexed 🙂

Thank you very much. This insight helps. It looks like I am grabbing C:\Program Files (x86)\Intel\iCLS Client\libeay32.dll along with libssl-1_1.dll and libcrypto-1_1.dll from my application directory. I have renamed this file and when I execute my application it no longer hooks that DLL, nor does it find any other SSL-looking DLLs other than the two in my application folder, which are the ones that ship with ICS. Application still fails to connect as before... 😞

Thanks again... I am on 10.1 Berlin, which must be old enough that GetIT is out of date. No worries there as installing it from the Overbyte site worked fine. I am using the two OpenSSL DLLs that ship with 8.67 (in the OpenSSL-Win32 folder). I have deleted all other DLLs in my application folder. I am running the following code: GSSL_DLL_DIR := ExtractFilePath(Application.EXEName); LoadSsl(); DebugLn('SSL/TLS "' + GLIBEAY_DLL_FileName + ' Version: ' + OpenSslVersion); Which reports: SSL/TLS "C:\WebExport\libcrypto-1_1.dll Version: OpenSSL 1.0.0k 5 Feb 2013 Is there any way it could be sucking in the wrong DLL from somewhere even though I am explicitly setting the path?

DLLs were distributed in same folder as my EXE, but I am not setting GSSL_DLL_DIR to same, just to be safe. I downloaded the latest version of the OpenSSL stuff from the Overbyte site, and updated to ICS v8.67 while I was at it. Prior, I was using the 8.62 version that was in GetIT (serves me right for trusting that abominable package manager!?)... Now SSL version reports as libcrypto-3.dll Version: OpenSSL 1.0.0k 5 Feb 2013 Detailed FTP log is still giving me the same thing though: 2021/11/03 11:07:48 AM: FTP Session Connected OK to: [mysite]:21 2021/11/03 11:07:48 AM: > HOST [mysite] 2021/11/03 11:07:48 AM: < 530 Please login with USER and PASS. 2021/11/03 11:07:48 AM: > AUTH SSL 2021/11/03 11:08:03 AM: FTP Session Closed 2021/11/03 11:08:03 AM: Failed to Connect to FTP Server: 426 Timeout

Thanks again... It reports as: SSL/TLS DLL: C:\WebExport\libcrypto-1_1.dll, Version: OpenSSL 1.0.2k 26 Jan 2017

Indeed... I'm pretty new to OpenSSL, so I just grabbed the required DLLs from another installation.DLLs... That's why I was wondering how to get the application to report what version of SSL *IT* sees? I have: libcrypto-1_1.dll v1.1.0.5 libeay32.dll v1.0.2.11 libssl-1_1.dll v1.1.0.5 ssleay32.dll v1.0.2.11

Thank you again for your assistance... I had FtpSslCliSecurity set to sslCliSecTls1. Setting it to sslCliSecIgnore had no effect. ftpMultiClient.FtpType := FtpTypeAuthSslBoth; ftpMultiClient.FtpSslVerMethod := ftpSslVerNone; ftpMultiClient.FtpSslCliSecurity := sslCliSecIgnore; // Have also tried sslCliSecTls1 ftpMultiClient.SslType := sslTypeImplicit; // Have also tried sslTypeNone, sslTypeAuthTls ftpMultiClient.FtpType := FtpTypeAuthSslBoth; ftpMultiClient.FtpSslVerMethod := ftpSslVerNone; ftpMultiClient.FtpSslCliSecurity := sslCliSecIgnore; // Have also tried sslCliSecTls1 ftpMultiClient.SslType := sslTypeImplicit; // Have also tried sslTypeNone, sslTypeAuthTls Other clients, including this same application with the same setting from another computer on the network in the same location are working fine. How can I determine the SSL version? I have the same version of the OpenSSL DLL's deployed with the application in all instances.

It does timeout after a bit. In my original code, I had the timeout set extremely high... 2021/10/29 10:28:56 PM: > AUTH SSL 2021/10/29 10:29:11 PM: FTP Session Closed 2021/10/29 10:29:11 PM: Failed to Connect to FTP Server: 426 Timeout 2021/10/29 10:28:56 PM: > AUTH SSL 2021/10/29 10:29:11 PM: FTP Session Closed 2021/10/29 10:29:11 PM: Failed to Connect to FTP Server: 426 Timeout

Nice, thanks... This is what it logs: Connect/Logon to FTP Server: [server redacted]:21 < 220 (vsFTPd 3.0.3) FTP Session Connected OK to: [ip redacted]:21 > HOST [server redacted] < 530 Please login with USER and PASS. > AUTH TLS

Thanks. I was not aware that icsLogger was for this purpose... Are there any other relevant events that I should be capturing log info from, or the CopyEvent?

Thanks very much to everyone that has responded so far... I have ensured that the firewall is completely off, and I did set up an icsLogger to see what was going on, and this is what if gives me: 08:41:36:067 ! HighLevelAsync 0 08:41:36:115 Control DNS Lookup Done - 35.167.253.97 08:41:36:115 03746150 Socket handle created handle=1488 08:41:36:137 TWSocket will connect to 35.167.253.97:21 08:41:36:169 Control Socket Connect, error=0 to 35.167.253.97:21 08:41:36:169 03746150 TryToSend handle=1488 08:41:36:170 03746150 TriggerDataSent handle=1488 08:41:36:197 >|220 (vsFTPd 3.0.3)| 08:41:36:197 ! HighLevelAsync 0 08:41:36:197 Start command, Req=HostAsync - HOST ftp1.shophero.com 08:41:36:197 03746150 PutDataInSendBuffer handle=1488 len 24 [1] 08:41:36:197 03746150 TryToSend handle=1488 08:41:36:198 03746150 TryToSend handle=1488 08:41:36:198 03746150 TriggerDataSent handle=1488 08:41:36:219 >|530 Please login with USER and PASS.| 08:41:36:219 ! HighLevelAsync 0 08:41:36:219 Start command, Req=AuthAsync - AUTH TLS 08:41:36:219 03746150 PutDataInSendBuffer handle=1488 len 10 [2] 08:41:36:219 03746150 TryToSend handle=1488 08:41:36:219 03746150 TryToSend handle=1488 08:41:36:219 03746150 TriggerDataSent handle=1488 Angus: I would love to see that. Please do post it if you have a chance.