2

I have some questions about the order of initialization for the CLR and the CRT for mixed .NET assemblies (i.e. meaning mixed managed/unmanaged C++ assemblies).

So if I have a mixed mode assembly dll file, and it gets loaded via Assembly.Load. I notice that any static native objects won't get initialized or called until some managed code is called first. OK. So I take it that on startup that the CLR code gets initialized first, and CRT initialization gets called last. How is the order for shutdown? Is the CRT shutdown first, and the CLR shutdown last?

So is this how it goes?

start of program lifetime

initilialize CLR
...initilialize CRT
...construct native static instances

... program runs....

...shutdown CLR
...destruct native static instances
shutdown CLR

end of program lifetime

Or is it in some other order?

My question also applies to mixed mode assemblies that are executables (i.e. .exe). It is similar?

start of program lifetime

initilialize CLR
...initilialize CRT
...construct native static instances

... program runs....

...shutdown CLR
...destruct native static instances
shutdown CLR

end of program lifetime
C.J.
  • 15,637
  • 9
  • 61
  • 77
  • 1
    Pretty unclear, the CLR got initialized a while ago if you use Assembly.Load(). The CRT is initialized by an obscure CLI feature called "module initializers". Similar to a class initializer but automatically runs when an assembly is loaded. It gets uninitialized by an event handler for AppDomain::DomainUnload and ProcessExit so before the CLR exits. Maybe you ought to focus on the reason you ask this question. – Hans Passant Dec 20 '11 at 18:12
  • see my comments below with Reed for a partial explanation. – C.J. Dec 21 '11 at 06:28

1 Answers1

2

This is covered in the MSDN Page for Initialization of Mixed Mode Assemblies.

It's actually the opposite of your idea. Native code gets initialized first, then the managed code. You are not allowed to access any managed code inside of DllMain.

The tear down process order isn't explicitly documented on MSDN, and doesn't appear to be documented explicitly in the C++/CLI specifications. I believe this is implementation specific, and covered under the "Undocumented Behavior" section relating to interaction between native and managed libraries of the appendix.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • Thanks for the link. My problem is when our app shuts down, we have native static objects that are blowing up and crashing our application. – C.J. Dec 20 '11 at 22:29
  • @CJohnson I'd try to correct them, directly. There's no reason they should crash teh app on shutdown... – Reed Copsey Dec 20 '11 at 23:24
  • That's the thing... sometimes they crash and sometimes they don't. It's hard actually to describe it in one sentence. But I have nice minidumps (from the field) that show the callstack, on crash, as happening long after winmain has exited. – C.J. Dec 21 '11 at 06:27
  • I don't know, perhaps if we talked offline about this. It really seems to be quite complicated, and I need someone who is above me in knowledge to consult with. – C.J. Dec 21 '11 at 06:28