what happens during ExitProcess? (in threads stopping, static objects, dll unloading)

[goanuj]

Using VC++6.0

Imagine a Mutli-Threaded, executable that implicitly links Idll0 and Idll1 and explicitly links (LoadLibrary) Edll2 and Edll3.
Imagine that there are static objects (class0, class1, class2, class3 declared respectively in Idll0, Idll1, Edll2, Edll3) in each of the DLLs.

Imagine that this program is running and has dynamically loaded all the DLLs and all
the static objects have been constructed and then main() spins off 10
threads, each of which will access all 3 static objects in each of the different dlls.

Now the program is running and main() returns. Remember, all threads are still running, and DLLs
are still loaded and main() does have any code that joins the threads back before returning.

Could someone explain to me what happens as the process exits.
Especially the interelationship/sequence between execution of the static objects destructors, dll unloads, and thread termination.

I understand that relying on any particular behavior is dangerous, but when dealing with third party DLLs and debugging the resulting programs, understanding this would be helpful.

Does anyone know of a document that accurately describes what would happen in this situation?

[Alexey B]

When a process terminates, the following actions occur:

1. All threads in the process are halted.
2. All the User and GDI objects owned by the process are freed.
3. The process kernel object's status becomes signaled.
4. The processes code changes to whatever is passed to the function.
5. The process' kernel object's usage count is decremented by one.
6. The memory containing the code and the memory privately allocated by the process in its address space are freed.

The memory that the system reservers for the process kernel object is not freed until its usage count reaches zero.

No destructors are called. If you use structured exception handling, the __finally statements are not called. The main difference between ExitProcess and TerminateProcess is that latter does not notify any DLL's attached to the process that the process is about to be terminated. This can bring very undesirable consequences, so the use of TerminateProcess is highly discouraged.

An interesting fact: C run-time calls ExitProcess after WinMain returns.

[goanuj]

I think you are right on most counts, but I do know for a fact that destructors are called on static objects because I put printfs in them and there are printed to stdout. There are two ways to do this: either the DLL itself has a DLLMain() function which ExitProcess() eventually calls, or the DLL does not have a DLLMain() call in which case, the OS sticks code into your DLL to take care of your static destructors. I painfully know this after a 2 hour debug dession where myself and manager stepped(F10) through the ExitProcess call as it was unloading DLLs. We found in our code that we _had_ registered a DLLMain for some of our DLL.

Here are some more questions... I am especially interested in the order in which these events may be happening.


What happens to the threads?
for example, what happens in terms of detaching from the DLL?
Does this have any effect on the d'tor of the static object? etc...

What happens to the DLLs?
Are they unloaded in a specific order? Are the unloaded haphazardly?
Are they unloaded _only_ after all threads that access them??? etc...
Do they ever get unloaded before calling the d'tor of their static objets?

What happens to the static objects whose destructors have to be called? (in relation to the threads and DLLs)

What will happen to the static objects as all the
threads that are accessing are detached from the dll?



As you can see this is a hard/difficult question... all three things are interelated and I think
some subtle stuff is going on here... maybe even non-deterministic.
1. static objects
2. dlls
3. threads

[Alexey B]

I can't say much about static objects, but I can about threads and DLLs.

DLLs

• If you call ExitProcess, the system notifies the DLLs attached to the process that the process is ending. DllMain will be called with the value of DLL_PROCESS_DETACH.
• If you call TerminateProcess, DllMain will not be called.

Threads

• When a thread terminates, all User object handles owned bt the thread are freed.
• The state of the thread kernel object becomes signalled.
• The thread's exit code is set.
• The thread kernel object's usage count is decremented by 1.

Regardless of how the process terminates, the system guarantees that all allocated memory, all User and GDI objects are freed, all open files are closed and the usage count on all kernel objects is decremented.

I don't know for certain about the order in which DLLs are ended, but I imagine that it is either the same as the order of their creation, or it is in the order of addresses at which the DLLs are mapped.