Jump to content


Photo

SmartFtp Library causes Socket Notification Sink Error Being Generated By Windows


  • Please log in to reply
8 replies to this topic

#1 Pavel Bonev

Pavel Bonev
  • Members
  • 9 posts

Posted 01 October 2007 - 06:14 PM

We are using SmartFtp Lib in over 500 locations which are checking and downloading updates every 10 minutes. In many cases we have bad communication conditions - high latencies, wireless connection breaks or satellite connection lost.
The software retries every time there is a problem to destroy the ftp connection object and create a new one. In rare cases (we have 3-4 a week) we see an exception dialog box containing "Socket Notification Sink Error" and followed by other exception dialog which are not created by our software.

We found the following explanation of the problem if you are using CAsyncSocket class from MFC in SmartFtp lib:

Socket Notification Sink Error Being Generated By Windows

SYMPTOMS

Windows randomly generates a "Socket Notification Sink" error and aborts the program or waits to shutdown the computer.

CAUSE

There is not a lot of specific information available as to why Window's will sometimes generate this error so we will relate our personal experience concerning this event. Individuals finding additional information concerning this matter can forward the information to support@apteryx.com so that we can update this record.

In our experience, this error can be generated by utilizing sockets in secondary threads and is more commonly seen in threads invoked by applications running as Window's services. This error is typically generated by the secondary thread when creating or attaching socket handles to a socket class object while more than one process is engaging in network communications at the same time.

More specifically, the "Socket Notification Sink" error actually relates to a failed window creation for use by a MFC socket class object. Since the MFC socket classes actually create and utilize a window to control the MFC socket object, failure to generate this window results in a detrimental application error. This windows generation failure is more commonly seen in Window's services since they typically have restricted UI creation rights (even if the service has the "interact with desktop" attribute).

RESOLUTION: Programmers

To date, the only resolutions to this problem have been the following:

1. Rewrite the application/thread/service so that it only opens a socket at the beginning of execution. The more times you create or even bind a socket, the greater the chance you will have of generating this error.
2. Rewrite the application to utilize the socket layer directly and remove all instances of the MFC derived socket classes.
3. Recompile your application using VC.NET. Apteryx has received reports that recompiling the project under VC.NET has helped correct the problem with MFC derived socket classes (thanks Ramasubramanian J).

Does any SmartFtp Lib user experience similar errors?
SmartFtp developers team- does this error apply to SmartFtp Lib?

For screen shots of the error please email to: pbonev@optecdisplays.com

#2 mb

mb

    Developer

  • Administrators
  • 11520 posts
  • Gender:
    Male
  • Location:
    Worldwide

Posted 01 October 2007 - 07:16 PM

Hello ..

The FTP Library uses the CAsyncSocket class from MFC.
>1-2
Unfortunately it's not feasible to rewrite the FTP library to use another base socket class. Even if we would rewrite it a hidden window is usually created/used for asynchronous sockets. Also so far I don't have much evidence that this would "fix" the problem.
>3
We are already using VS.NET 2005 to compile all our applications.

Apteryx also lists resolutions for the end-user. Did you try all of them? Are you using the latest operating system (Windows 2003 / Windows Vista) on the machines where the problem occurs?

Regards,
Mat

#3 Pavel Bonev

Pavel Bonev
  • Members
  • 9 posts

Posted 01 October 2007 - 07:46 PM

Hi!
As far as resolutions for the end user - we are using embedded single board computer, not possible to change the NIC. OS is WIndows XP Embedded, proper and only the specific for the NIC drivers are installed.
The other resolutions are:
- to rewrite the application or recompile with newest VC. We are using Borland RAD Studio, Delphi 7, not using MFC in the application. The exception error comes from sfftplib.dll.
- to write the application to create the connection object once in the beginnig in order to minimize the number of calls to create method. We tried that but found a problem when the controll connection is lost (sometimes the control channel may be closed by the firewall because there will be no data activity on it whn downloading big files), the only way to recover is to re-initialize/create the connection object. In our case the embedded controller does this at least every 10 min 24 hours a day 7 days a week. The software also can re-boot the system if no successful connection attempt is made for a certain period of time. But the problem is that when this box is shown the application is stuck and it does not have the controll at all - it waits for user input. If the create method in sfftplib.dll is throwing an exception it will be handled by application properly, but it looks that it may not be handled by the dll.
Is it possible to check if that exception is handled in the dll?
Another question:
We are using sfftplib.dll v1.5.9.26 - was that library compiled with the VS 2005 as well?

Thanks for the prompt responce, we greatly appreciate your help!

Sincerely:
Senior Software Engineer
Optec Displays Inc.
530 S 6th Ave
City of Industry, CA 92870
800-876-1668 x.603

Edited by Pavel Bonev, 01 October 2007 - 07:50 PM.


#4 mb

mb

    Developer

  • Administrators
  • 11520 posts
  • Gender:
    Male
  • Location:
    Worldwide

Posted 02 October 2007 - 06:09 PM

Hello ..

We did already handle the CResourceExcpetion which is thrown in the Socket() call. There are 2 more places where it's thrown:
1. Attach() function.
The exception handler has been added now.

2. SOCKET_NOTIFY message
We cannot handle it there without patching the MFC source.

Please test it with the new version (.4). If it doesn't fix the problem we will investigate further.

BTW: Do you have a stack trace?

Regards,
Mat
SmartFTP

#5 Pavel Bonev

Pavel Bonev
  • Members
  • 9 posts

Posted 05 October 2007 - 08:27 PM

Hello ..

We did already handle the CResourceExcpetion which is thrown in the Socket() call. There are 2 more places where it's thrown:
1. Attach() function.
The exception handler has been added now.

2. SOCKET_NOTIFY message
We cannot handle it there without patching the MFC source.

Please test it with the new version (.4). If it doesn't fix the problem we will investigate further.

BTW: Do you have a stack trace?

Regards,
Mat
SmartFTP


I get Unknown error on Connect. ($19EB14)

#6 mb

mb

    Developer

  • Administrators
  • 11520 posts
  • Gender:
    Male
  • Location:
    Worldwide

Posted 06 October 2007 - 05:11 PM

Hello ..

Do you get the error everytime or instead of the exception dialog?
I couldn't find any (new) problems with version (.4).

Regards,
Mat

#7 Pavel Bonev

Pavel Bonev
  • Members
  • 9 posts

Posted 08 October 2007 - 04:18 PM

I cannot even connect with this library. Any method or property dispatch id changed?
NOTE: I did not re-import the activex in Delpi, just registered it and ran the same exe which was using version 1.5.9.26. I assumed that I may be able to upgrade by just changing and registering the dll.

#8 mb

mb

    Developer

  • Administrators
  • 11520 posts
  • Gender:
    Male
  • Location:
    Worldwide

Posted 08 October 2007 - 04:30 PM

Hello ..

Depending what version you are upgrading from you need to reimport the library. Please see the change log for all the changes.

Regards,
Mat

#9 Pavel Bonev

Pavel Bonev
  • Members
  • 9 posts

Posted 08 October 2007 - 08:42 PM

Hi, Mat!
I looked at the change log for sfftplib.dll and it looks like the change of the event sink dispatch interface is affecting us. I guess we will have to update both the exe and dll. I will test it at as many locations I can and will let you know the result.
Regards:
Pavel Bonev




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users