win_glue DLLMain problems with WSAStartup / WSACleanup

Ken Raeburn raeburn at MIT.EDU
Fri Mar 25 06:17:33 EST 2005

On Mar 25, 2005, at 05:14, Jeffrey Altman wrote:
> In the DllMain() function of our DLLs, we currently call WSAStartup at 
> process attach and WSACleanup at process detach.  When the Microsoft
> Internet Connection Firewall is enabled, the call to WSACleanup will
> produce a deadlock.

Ick.  Is this specific to the Load/FreeLibrary or process 
startup/termination case, or does it apply to both cases?

(Odd.  I thought I had ICF enabled on my Windows box at work.  Have to 
check that....)

> According to Microsoft, we cannot make these calls.  Instead, the 
> application must initialize Winsock for us or we must initialize it
> outside of the DllMain().  This most likely means that we will have
> to check all Winsock() api calls to see whether there is a 
> WSANOTINITIALISED error and if so call WSAStartup() and then retry
> the operation.  By doing so, the most we will leak is one winsock
> initialization since as far as I can tell there is no method by which
> we can safely perform a WSACleanup().

For initialization, we've already got hooks for doing delayed 
initialization code.  We still need to run the mutex initialization at 
load time on Windows, but the macro call which currently just verifies 
that that initialization did in fact run could also call some new 
support function which would check that WSAStartup was called (with ref 
counts, mutex protection, whatever), or even do it directly if that's 
not too painful.

For WSACleanup, it may be trickier.  But if it's only process 
termination time that's the problem, and not unloading a library during 
normal execution, well, the first google hit I got on 
DLL_PROCESS_ATTACH is an MSDN page that indicates that we can 
distinguish the two cases by looking at the third argument to DllMain.  
Another, somewhat more intrusive, option would be to put conditional 
WSAStartup/WSACleanup calls around stuff doing network access.

(In a couple of quick searches, I couldn't find details on the nature 
of this problem.)


More information about the krbdev mailing list