Winsock Errors

Ever since moving to Empower in 2008 we have been plagued with Winsock Errors for eSatin systems. Winsock errors #10055 would prematurely stop runs. Following a recomendation by Waters, we have upgraded the ICS software to 1.20.1018. This upgrade has fixed the 10055 Winsock error specifically, but we still get other Winsock errors (#0, 10038, 10053, 10057, 10060, and 10061). These usually occur upon a users initial connection to a system, before a run is started. The most common we have seen are 10038 and 10057. Has anyone else experience similar problems, or have any suggestions on isolating the issue? We are running Empower 2 (Build 2154), FR4, Service Pack C. Our Network structure is comprised of users connecting to the Empower Server through Empower Clients running on Terminal Servers. Our Instrument Lans are using the alternative IP addresses of 172.16.0.xxx. We are using LACE 32 acquisition servers with two dual network cards for the Instrument Lan.

Answers

  • Hello,

    We would like to offer suggestions but first need more information to help understand the issue. You mention the ICS software was updated on the LAC/E32 servers. Was the ICS updated on the CITRIX server as well? Have you tried connecting to the system using a fully configured Empower client? If so, do the Winsock errors occur upon the initial connect to the system?

    Thank you

    Dot

  • We are not running a Citrix server. Our Empower Server is running on Windoss Server 2003. The Winsocks do occur every time someone connects to a system and we have yet to determine common conditions that cause the Winsock errors. We have failed to produce one at will. I have to ask however, what exactly do you mean by "fully configured Empower client"? Waters has suggested that these errors occur because of some kind of breakdown in the communication between the Lace(s) and the eSatin(s). The errors have happened on Waters supplied crossover cables as well as others, so we have ruled out inferior cabling. It seems to be something on the Lace(s) that occasionally fails to recieve the expected response(s) from the eSatins. If I didn't know better, I would say that the Instrument LAN NICs were too busy to handle new requests at the time or the eSatins are too slow to respond (like they were in a Not-Ready state or asleep).
  • Hi MB,

    We moved to Empower 2, FR3 in 2007 and we have lots of e-Sat/Ins attached to instruments. We also experience numerous winsock errors - mainly 10038, 10057 and 10060. ICOP 1.04 resolved some of these but we have been recommended by Waters to upgrade our WICS to version 1.. from 1.0. I'm not sure if this will resolve the issue and we have not made this change yet to our LAC/Es or clients. I think alot of these errors are down to the sat/in losing connectivity with the LAC/E but resolving and troubleshooting the issue is proving difficult. I would be interested in hearing any advice also from other people on this issue.

  • Thanks Aquaregina. It is nice to know that we are not alone. For the most part, since the ICS / ICOP upgrade, these Winsock errors do not interfere with daily Empower activities, but we have had two this month that have coincided with a interrupted run. Whether they were the cause of the interruption, or just by-product is undetermined. Waters Support has told us that these Winsock errors increase the likelihood of something going wrong, and since we get so many of them, we would like to eliminate them.

  • Hello

    It may take some time to troubleshoot and investigate this issue. To better assist in resolving these errors as quickly as possible, we would like to suggest your local Waters service representatives be contacted so they can involve us in the form of a technical inquiry. When a resolution is identified a post can be made for the users to view.

    Kind regards

    Dot

  • 3 experiences, not certain that any would apply to you...

    Some LAC/Es were sent out the door with the wrong driver for the instrument NIC. I *think* it was the model 12 LAC/Es that were sent out w/ the same driver as was used w/ model 10's NICs and you have to manually update the NIC driver.

    Are you using MiLAN switches provided by Waters? If so, you might want to reboot them regularly (or better yet, replace them w/ something comparable from Linksys or Netgear). I have had numerous problems w/ MiLAN switches.

    Are you using Host Intrusion Prevention software (as McAfee calls it) or BlackIce (Proventia's version)? If so, you may have to have an admin open ports for your subnet devices lest they be blocked as potential port scanning malware attackers.

    Best of luck, DR

Sign In or Register to comment.