TCPError 10048

Using (or providing) components based on the "Win32" framework

TCPError 10048

Postby MBaas on Wed Aug 11, 2010 9:01 pm

I have a 10.1-app-server running on a W2003-server (SP2) and for years it was running reliably. Yesterday the client's IT patched the server - and suddenly the app lost client-connections and reported TCPError 10048.
So they undid the patch, but for some reason things even "got worse" (as the client said) - it seems the time-interval in which the problem occurred came down to every 15mins (after restarting the app).

Has anyone else recently observed strange crashes after applying the latest MS-Patchwork? Any ideas/comments/suggestions?
User avatar
MBaas
 
Posts: 156
Joined: Thu Oct 16, 2008 1:17 am
Location: Gründau / Germany

Re: TCPError 10048

Postby AndyS|Dyalog on Thu Aug 12, 2010 9:20 am

I wonder if you're getting abortive closes on the sockets ? In that case, the timeout period can be quite long before the kernel frees the address, so socket error 10048 is not unlikely.

It might be worth examining the possible timeout settings that can be set in the registry at both ends of the link. Unfortunately there's a goodly number of places in the registry where TCP-related values are set: two it may be worth searching for in MSDN are

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP

These and other places may lead to the solution (and, I fear, potentially open a can of worms on what _could_ be configured !)

For anyone who wants to have a little more detail about the possible errors that TCP sockets can generate under Windows, then this is a good place to look: http://msdn.microsoft.com/en-us/library/ms740668%28VS.85%29.aspx.
User avatar
AndyS|Dyalog
 
Posts: 257
Joined: Tue May 12, 2009 6:06 pm

Re: TCPError 10048

Postby harsman on Fri Aug 13, 2010 11:33 am

10048 is "Address already in use" and is usually reported when a server tries to bind to a port that already has a listening socket due to some other process or connection.

Make sure that there isn't several processes listening on the same port (try "netstat -a -n -o" and grep for whatever port you usually listen on). If your application restarts itself, note that it can take a while for the port to become available, so it it restarts to quickly after shutting down, you might get this error.

We've also seen instances where software firewalls cause a different error message to be returned, e.g. some versions of McAffee turn 10061 Connection refused into 10060 Time out which can be confusing.
harsman
 
Posts: 27
Joined: Thu Nov 26, 2009 12:21 pm


Return to Windows: GUI, COM/OLE/ActiveX

Who is online

Users browsing this forum: No registered users and 1 guest