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.)
Ken
More information about the krbdev
mailing list