Static initializers with option /CLR in dlls

[Jesper Schmidt]

Hi,

I have a relatively large C++ code base, which requires that static
initializers are called when a dll is loaded. This seems to work well
for native code, but it does not work for files compiled with the /CLR
option enabled. I will try to give a simple example that illustrates my
problem.

Library code:
-----------
#include <cstdio>
static int dummy = std::puts("initializer called");

Program code:
-----------------
#include "windows.h"
int main()
{
LoadLibrary("library.dll");
return 0;
}

The program prints, "initializer called", when the library is
compiled without the /CLR option, but it prints nothing if the library
is compiled with the /CLR option. My initial thought was that the
linker eliminated the unreferenced 'dummy' symbol, but this does
not seem to be the case because I can locate the 'dummy'
initializer in the 'library.dll'. Does anybody know why the CLR
loader does not call the 'dummy' initializer when the library is
loaded, or does anybody know how I force the CLR loader to call the
'dummy' initializer without referring directly to the 'dummy'
symbol itself?

Many thanks in advance for any help!
Jesper

[William DePalo [MVP VC++]]

"Jesper Schmidt" <sc******@gmail.comwrote in message
news:11**********************@i42g2000cwa.googlegr oups.com...

I have a relatively large C++ code base, which requires that static
initializers are called when a dll is loaded. This seems to work well
for native code, but it does not work for files compiled with the /CLR
option enabled. I will try to give a simple example that illustrates my
problem.

Which version of the compiler are you using?

Have you run your application compiled for the /CLR case in both debug and
release configurations?

You see, .Net can initialize an assembly that contains only managed code on
its own. But for one which contains native code as well, it has to use
Windows' loader. The loader uses a critical section to insure that no code
in any DLL runs before its DllMain() sees "attach" notifications. That can
give rise to deadlock situations because the compiler sees to it that static
initializes run while processing the DLL_PROCESS_ATTACH notification:

http://msdn.microsoft.com/library/de...ingproblem.asp

Under VS2003, when one gets into that situation, one often receives cryptic
error messages for which a workaround is described here:

http://support.microsoft.com/kb/814472/en-us

But because you didn't mention those messages, I'm assuming you are using
VS2005.

I still use 2003 for my mixed-mode DLLs so take this with a grain of salt
but I _think_ that VS2005 warns one in debug mode when one does proscribed
things and simply chooses not to do them in release mode. I'm wondering if
ran into that problem.

But you didn't mention seeing a warning. That leaves me confused as to which
compiler you are using. :-)

Finally - and this is just thinking out loud - you might want to put a call
to OutputDebugString() where you have

std::puts("initializer called");

now. I'm wondering whether it could be the case that the project you are
using does not yet have the console I/O stuff initialized, either because
it's of the wrong type or for some other reason.

Regards,
Will

[Jesper Schmidt]

William DePalo [MVP VC++] wrote:

"Jesper Schmidt" <sc******@gmail.comwrote in message
news:11**********************@i42g2000cwa.googlegr oups.com...

I have a relatively large C++ code base, which requires that static
initializers are called when a dll is loaded. This seems to work well
for native code, but it does not work for files compiled with the /CLR
option enabled. I will try to give a simple example that illustrates my
problem.

Which version of the compiler are you using?

I am using Microsoft Visual Studio 2005.

Have you run your application compiled for the /CLR case in both debug and
release configurations?

Yes, I get the same result in both debug and release.

You see, .Net can initialize an assembly that contains only managed code on
its own. But for one which contains native code as well, it has to use
Windows' loader. The loader uses a critical section to insure that no code
in any DLL runs before its DllMain() sees "attach" notifications. That can
give rise to deadlock situations because the compiler sees to it that static
initializes run while processing the DLL_PROCESS_ATTACH notification:

http://msdn.microsoft.com/library/de...ingproblem.asp

Under VS2003, when one gets into that situation, one often receives cryptic
error messages for which a workaround is described here:

http://support.microsoft.com/kb/814472/en-us

But because you didn't mention those messages, I'm assuming you are using
VS2005.

I still use 2003 for my mixed-mode DLLs so take this with a grain of salt
but I _think_ that VS2005 warns one in debug mode when one does proscribed
things and simply chooses not to do them in release mode. I'm wondering if
ran into that problem.

I know of this problem, but I do not think that this is the case here.
I think that my problem has to do with some kind of
just-in-time-initialization performed by the clr code. I think that the
call to the 'dummy' initializer is deferred to the first time that
'dummy' is referenced. I have tried to proof this by accessing 'dummy'
through a function call from the 'main' function. This does indeed
trigger the initialization of 'dummy', but it does not solve my
problem, because the test framework that I am working on does not know
any functions in the test dll(s) that it loads. Instead, each test case
installs itself into the test framework with the help of a static
initializer.

--
Jesper

[Ben Voigt]

I know of this problem, but I do not think that this is the case here.
I think that my problem has to do with some kind of
just-in-time-initialization performed by the clr code. I think that the
call to the 'dummy' initializer is deferred to the first time that
'dummy' is referenced. I have tried to proof this by accessing 'dummy'
through a function call from the 'main' function. This does indeed
trigger the initialization of 'dummy', but it does not solve my
problem, because the test framework that I am working on does not know
any functions in the test dll(s) that it loads. Instead, each test case
installs itself into the test framework with the help of a static
initializer.

Does __crt_dll_initialize() solve your problem? (you don't then need to know
how many static variables there are).

See http://support.microsoft.com/kb/814472. Although, all these problems
were supposed to go away in VC++ 2005.

Another possibility is to use #pragma managed(push, off) ... declare static
initializers ... #pragma managed(pop)

>
--
Jesper

[Jesper Schmidt]

Ben Voigt wrote:

I know of this problem, but I do not think that this is the case here.
I think that my problem has to do with some kind of
just-in-time-initialization performed by the clr code. I think that the
call to the 'dummy' initializer is deferred to the first time that
'dummy' is referenced. I have tried to proof this by accessing 'dummy'
through a function call from the 'main' function. This does indeed
trigger the initialization of 'dummy', but it does not solve my
problem, because the test framework that I am working on does not know
any functions in the test dll(s) that it loads. Instead, each test case
installs itself into the test framework with the help of a static
initializer.

Another possibility is to use #pragma managed(push, off) ... declare static
initializers ... #pragma managed(pop)

I have tried this, but it does not help. Apparently, the unmanaged
intializer exhibits the same just-in-time-initialization as the managed
initializer. Loading the module still does not trigger the 'dummy'
initializer. It looks as if the initialization is deferred until the
module code actually is referenced/called. I would be grateful if
someone could verify this?

--
Jesper

[Jesper Schmidt]

Ben Voigt wrote:

I know of this problem, but I do not think that this is the case here.
I think that my problem has to do with some kind of
just-in-time-initialization performed by the clr code. I think that the
call to the 'dummy' initializer is deferred to the first time that
'dummy' is referenced. I have tried to proof this by accessing 'dummy'
through a function call from the 'main' function. This does indeed
trigger the initialization of 'dummy', but it does not solve my
problem, because the test framework that I am working on does not know
any functions in the test dll(s) that it loads. Instead, each test case
installs itself into the test framework with the help of a static
initializer.

Another possibility is to use #pragma managed(push, off) ... declare static
initializers ... #pragma managed(pop)

I have tried this, but it does not help. Apparently, the unmanaged
intializer exhibits the same just-in-time-initialization as the managed
initializer. Loading the module still does not trigger the 'dummy'
initializer. It looks as if the initialization is deferred until the
module code actually is referenced/called. I would be grateful if
someone could verify this?

--
Jesper