DLL-Initialization causes application hangup

[S.Winkler]

Using dcmtk 3.6.0 I encountered a problem under the following conditions:
Windows 7 / 64 Bit / Visual Studio 2010

I implemented a Windows Services, which does not use dcmtk itself, but uses LoadLibrary to load DLLs, which themselves encapsulate the DICOM-stuff. If there are more than one instances of this Windows Service running on a host, the processes often hang up on DLL-Initialization.

Because there is no dcmtk-context in the calling process, loading the DLL triggers the intialization of static content and OFLog_init() is called, which calls WSAStartup(). This seems to cause the processes to hang up.

Calling OFLog::getLogger() in the Windows Service part on application startup solves the problem.
(As an unwanted side-effekt, this process now has to link the dcmtk-libs, too)

Is this a corrrect procedure to do so?

I did not find any hint for this behaviour in the documentation - have I missed something?

Thank you in advance,
Silvia

[J. Riesmeier]

Calling OFLog::getLogger() in the Windows Service part on application startup solves the problem.
(As an unwanted side-effekt, this process now has to link the dcmtk-libs, too)

So, introducing an initLibrary() function in your DLL that calls OFLog::getLogger() and that is called by your Windows service should also work, right?

[S.Winkler]

Thank you for your reply!
I dont't think, it could solve the hangup:

My Windows Service uses runtime dynamic linking, it does not link anything from the DLL statically (there is not .lib, just a .dll). The name of the DLL to load is determined on runtine (by the given working context), I cannot call any function in the DLL before loading it. And loading produces the hangup.

Best regards, Silvia

[J. Riesmeier]

OK, now I got it but, unfortunately, I have no idea how to solve this issue (since my experience in this Windows-specific field is very limited).
Maybe, other DCMTK users can help. Alternatively, you could ask in other more general forums like "Stack Overflow".

Addendum: Does DllMain() help?

[Jan Schlamelcher]

Do you use the static or the DLL version of the DCMTK-libraries? Maybe linking to a oflog.dll helps. WSAStartup might only be called when the DLL is first loaded and in that case and not by every service DLL using DCMTK. I'm not exactly sure how windows does this things (order of execution + loading of static members in DLLs is one of those things where windows is "special"). If using DCMTK DLLs does not help, maybe we can try to implement the init-method based on this functionality, but this would be yet another special handling case for microsoft specific behaviour:
http://msdn.microsoft.com/en-us/library ... 85%29.aspx

[S.Winkler]

I use the static dcmtk-libs. Using dlls could maybe be usefull. Could you please provide a short description (or a link to the information), how I can build dmtk into dlls? Is this supported in 3.6.0? I think, DCMTK-INSTALL-documentation does not mention, how to do this ....

For me right now it's ok to trigger the toolkit-initialization in the Windows Service process itself, it's not really smart but it works

The main intention of my post was to provide this hint to other people who may run into the same situation ...

[J. Riesmeier]

Support for building shared libraries (e.g. DLL on Windows) has been added after the release of DCMTK 3.6.0, see e.g. this blog posting: http://blog.jriesmeier.com/2012/01/buil ... libraries/

The current version of the INSTALL file also has a section on "CMake and shared libraries", see e.g. here: http://support.dcmtk.org/docs-snapshot/ ... stall.html

[Jan Schlamelcher]

Is this supported in 3.6.0?

As J. Riesmeier already mentioned, building shared libraries was introduced after version 3.6.0, you would need to use a snapshot, at least http://dicom.offis.de/download/dcmtk/sn ... 222.tar.gz, but better take the newest one http://www.dcmtk.org/dcmtk#snapshot.

Could you please provide a short description (or a link to the information), how I can build dmtk into dlls?

Simply set the CMake variable "BUILD_SHARED_LIBS" to "ON".