Hello,

We are trying to use xceed FtpClient class to download files from one of our partners. Said partner is using somewhat unconventional setup with SSL encryption and "Clear Command Channel" command, xceed FtpClient class is one of the few components that can handle both of these requirements. It is also my understanding that said partner uses some sort of Sterling solution either on top of their FTP or as their FTP server. This system prevents us from downloading same file multiple times unless there has been an update to the file. This is important because some files are not updated every single day and when we try to download them with xceed FtpClient class we get FtpTimeoutException.

We would be fine with getting FtpTimeoutException when trying to download those files, however the problem we're having is that 5 out of 6 times FtpClient class will throw unhandled FtpTimeoutException inside our Windows Service despite having proper try-catch block around the relevant code. This unhandled exception causes general .net runtime 2.0 error and completely crashes the service. We have tried FTP 4.0 and FTP 4.1.9373.11490 versions and both exhibit the same behavior.




Here are last two messages from Windows Event Log before the service crashes:

1.

Source: .NET Runtime 2.0 Error
EventType clr20r3, P1 bwarservice.exe, P2 1.0.0.0, P3 4a8dac41, P4 xceed.ftp, P5 4.1.3524.17619, P6 4a940787, P7 7c, P8 41, P9 xceed.ftp.ftptimeoutexception, P10 NIL.

2.

Source: VsJITDebugger
An unhandled exception ('Xceed.Ftp.FtpTimeoutException') occurred in BWARService.exe [12988]. Just-In-Time debugging this exception failed with the following error: Debugger could not be started because no user is logged on.


Ignoring JIT debugger nature of the second message, it obvious that the error is coming from inside FtpClient instance. What's strange is that sometimes the service crashes while downloading files, and sometimes it crashes after file download is complete, after we already disconnected from the FTP server and after we are already processing files that we successfully downloaded.




The piece of code that downloads files is relatively simple and follows xceed help guide:

       public bool DownloadFilesUsingXCeedFTP()
        {
            bool _result = true;

            string _RemoteFilePath = "";
            string _LocalFilePath = "";

            try
            {
                //close previous connection if it is still open just in case
                if (m_ftpxceed != null && m_ftpxceed.Connected)
                {
                    m_ftpxceed.Disconnect();
                }

                foreach (FtpServer _FtpServer in m_Servers)
                {
                    m_ftpxceed = new Xceed.Ftp.FtpClient();
                    m_ftpxceed.Timeout = _FtpServer.TimeOut;
                    m_ftpxceed.KeepAliveInterval = 20;
                    m_ftpxceed.Connect(_FtpServer.Address, _FtpServer.Port);

                    if ( _FtpServer.ProtocolType == FTPProtocolType.FTPES )
                        m_ftpxceed.Authenticate(AuthenticationMethod.Ssl, VerificationFlags.AllFlags, null, DataChannelProtection.Private);

                    m_ftpxceed.Login(_FtpServer.Username,_FtpServer.Password);

                    if (_FtpServer.SendCCC)
                        m_ftpxceed.ClearCommandChannel();

                    foreach (FtpFile _FtpFile in _FtpServer.Files)
                    {
                        _RemoteFilePath = _FtpFile.RemoteDirectory + _FtpFile.RemoteFileName;
                        _LocalFilePath = _FtpFile.LocalDirectory + _FtpFile.LocalFileName;

                        //any given file may fail the download, we still want to download as many files as we can
                        try
                        {
                            //Download new file
                            m_ftpxceed.ReceiveFile(_RemoteFilePath, _LocalFilePath, false);
                            _FtpFile.Downloaded = true;
                        }
                        catch (Exception ex)
                        {
                            ExceptionHandler.ExceptionLog(ex, "Failed to download " + _LocalFilePath, clsParams.BWARFirmGuid);

                            if (!_FtpFile.IgnoreDownloadFailure)
                                _result = false;
                            _FtpFile.Downloaded = false;
                        }
                    }

                    if (m_ftpxceed.Connected)
                    {
                        m_ftpxceed.Disconnect();  //we downloaded all files from current server, close connection
                    }
                }
            }
            catch (Exception ex)
            {
                _result = false;
                ExceptionHandler.ExceptionLog(ex, "General download files error", clsParams.BWARFirmGuid);
            }
            finally
            {
                if (m_ftpxceed != null && m_ftpxceed.Connected)
                    m_ftpxceed.Disconnect();
            }

            return _result;
        }
        
        
There is try catch block around ReceiveFile call and there is try catch block around DownloadFilesUsingXCeedFTP() method call in the service, yet we still get unhandled FtpTimeoutException's that crash our service.



Our company has BluePrints subscription so we have access to source code and I believe I've found piece of code that throws FtpTimeoutException and crashes our service. I've commented out that particular line of code and deployed recompiled Xceed.Ftp.dll to our QA environment to test it. However, just commenting out code inside xceed FtpClient class is obviously not an ideal solution because I do not know if it will have any unintended consequences.



Can you please advise what I can do to fix this problem without compiling custom version of Xceed.Ftp.dll or if you will be able to fix this issue in the next release?





Thank you, Daniil

Hi Daniil,

Try to change the VerificationFlags.AllFlags to None and remove the KeepAliveInterval: two knowns bugs that will be fixed in the service release (next week).  There is a known bug with the KeepAlive that will prevent the NOOP command reply to be received while processing a data transfer command.

 

Best regards,

---

Ghislain
Technical Support and software developer
Xceed Software Inc.
Knowledge Base : http://xceed.com/kb/
Update Center : http://xceed.com/updates/
Documentation Center : http://xceed.com/doc/
For everything else, there is Google

Hi, this is not fixed yet on release?

 Xceed Components

3.2.9616.13400

December 21, 2009

My log is full of errors like 

P4 xceed.ftp, P5 4.1.9616.13400, P6 4b2933da, P7 2a7, P8 41, P9 xceed.ftp.ftptimeoutexception, P10 NIL. 

 thanks

Hi,

yes, it is solved *except* if you're connecting to a Microsoft ftp server, in which case there is not much you can do.   (Or any ftp server that doesn't reply to a NOOP command.)

The Microsoft ftp server doesn't send any reply to the NOOPs that Xceed ftp clients are sending; this is causing the ftp timeout exceptions. 

This is explained by one property mainly: KeepAliveInterval

Ftp uses two connections : a command channel to send commands and receive replies, and a data channel to transfer data in both direction.

Some server have a timeout after which the command channel connection is closed. Which can be correct, but you will never be sure that the transfer was successful or not, since the client will never receive and/or process the final reply.

Our implementation matches the rfc959 and the command channel must stay alive all along the transfer. If a timeout occurs, we cancel the file transfer.

To allow the command channel to stay alive, a NOOP command must be sent to the server on the command channel in order to say to the server that the command channel is still required. The server must reply (according to rfc959). This is the way the component is actualy implemented.

The KeepAliveInterval should be kept inferior to the FTP server timeout value.  I.e.  if the FTP server has a timeout of 30 sec, the KeepAliveInterval setting should be lower than 30.

If this is not the cause of the timeout exceptions you're getting, disregard this message.

Best regards,

---

Ghislain
Technical Support and software developer
Xceed Software Inc.
Knowledge Base : http://xceed.com/kb/
Update Center : http://xceed.com/updates/
Documentation Center : http://xceed.com/doc/
For everything else, there is Google

Hi

I use firezilla server and I have proper error handling in my code but xceed crashes and I have my log full with

EventType clr20r3, P1 testing.exe, P2 1.1.0.0, P3 4b59e6e5, P4 xceed.ftp, P5 4.1.9616.13400, P6 4b2933da, P7 2a7, P8 41, P9 xceed.ftp.ftptimeoutexception, P10 NIL. 

this is how it looks from the filezzilla server window

000005) 22-01-2010 18:14:05 - john (x.x.x.x)> CWD /1097

(000005) 22-01-2010 18:14:05 - john (x.x.x.x)> 250 CWD successful. "/1097" is current directory.

(000005) 22-01-2010 18:14:35 - john (x.x.x.x)> CWD /1097

(000005) 22-01-2010 18:14:35 - john (x.x.x.x)> 250 CWD successful. "/1097" is current directory.

(000005) 22-01-2010 18:15:05 - john (x.x.x.x)> CWD /1097

(000005) 22-01-2010 18:15:05 - john (x.x.x.x)> 250 CWD successful. "/1097" is current directory.

 it seems that filezzilla server sends 250 CWD and xceeds do nothing... then it waits for 30 seconds and resends the samae CWD ....

 

well but the worst is that xceed just crashes... the component crashes... it's not a simple connection error because I cannot catch this in my error handle routine

Hi,

you can try to set Xceed ftpClient.KeepAliveInterval at 0. 

We have noticed one important thing: some FTP servers (such as Microsoft) do not return a REPLY to an Xceed ftp client when it sends a NOOP (no operation), even if they are supposed to.  ( Ref: the RFC959 official papers, which are defining the FTP protocol )

This is causing the ftp sessions to throw an exception timeout. Have you tried to catch the exception in a try-catch statement?  If this is not getting you any further, we would like to have a sample application that reproduces this 'crashing',   If possible, send your solution at support@xceed.com and mention "FTP crashing, thread 25523".  Thank you very much.

Best regards

---

Ghislain
Technical Support and software developer
Xceed Software Inc.
Knowledge Base : http://xceed.com/kb/
Update Center : http://xceed.com/updates/
Documentation Center : http://xceed.com/doc/
For everything else, there is Google

Thanks for the info Ghislain, it worked for me (set KeepAliveInterval to 0) for a similar timeout problem.

Hi,

i reopen this thread because since i migrate to the last version (i was previously on 3.3) my windows service crash when i had a FTPTimeout Exception.

I follow the recommandation and put Flags to None and KeepAliveInterval to 0 but it doesn't solve my problem.

The FTP servers which i'm connected are IIS 6 (can't upgrade for now).

The error is not my main problem, it the crash of windows service the real issue (i can't catch this exception).

There is the stacktrace of the error :

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: System.ObjectDisposedException

Stack:

   at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean ByRef)

   at Microsoft.Win32.Win32Native.SetEvent(Microsoft.Win32.SafeHandles.SafeWaitHandle)

   at System.Threading.EventWaitHandle.Set()

   at Xceed.Ftp.Engine.FtpDataConsumerCommand+<>c__DisplayClass8.<BeginProcessData>b__7(System.Object)

   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()

   at System.Threading.ThreadPoolWorkQueue.Dispatch()

   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

 

Thanks,