DLL unload if App bombs??

[Paul Squires]

Hi Everybody,

Probably a simple answer for someone more experienced than me.

If a PB or VB app terminates abnormally while code is
still executing in my PB created DLL (PB/DLL6), what happens???
Does the DLL get unloaded, continue to execute or just remain a
phantom process that stays in memory until the computer is
rebooted?

Thanks.


------------------
Paul Squires
[email protected]

[John Kovacich]

It continues to execute (or at least it frequently does).

------------------
Thanks,

John Kovacich

[Eric Pearson]

My experience is different from John's.

When an app GPF's or is end-tasked, or is terminated abnormally in any other way, the process itself -- all execution -- is halted. When the process is halted, all threads of execution are halted.

On 95/98/ME systems the process's EXE and DLLs are sometimes left write-protected, requiring a reboot, but this is not an indication that the program is still running.

While it is farily common for a malfunctioning app to remain in memory, running, after the GUI or console has disappeared, if the application actually "terminates abnormally" that means that the process terminates, period.

Also, as a side note, an abnormal termination often bypasses the DLL_PROCESS_DETACH and DLL_THREAD_DETACH mechanisms. The DLL is simply removed from memory without the usual "cleanup", so that's something else that can make it look like the app is still running (temp files that are supposed to be deleted in DLL_PROCESS_DETACH, etc.)

-- Eric


------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited February 15, 2001).]

[Paul Squires]

Eric,

You are dead on with the reason I am asking the question - I was
hoping the DLL DETACH code would fire because in my DLL I have
a lot of allocated memory that I need to call an API to free
when the DLL unloads.

Thanks,




------------------
Paul Squires
mailto:[email protected][email protected]</A>

[Lance Edmonds]

The memory allocated to the whole process (EXE & DLL's) *will* be deallocated when the app is terminated, either normally or abnormally.

All handles, resources and windows are destroyed & freed too, and all DLL's reduce their usage count by one. Once the usage count reaches zero, the DLL is freed from memory.

When Eric used the term "cleanup", he was really referring to anything that your own code may want to do, such as write data to a disk file, print a report, or write a log file, etc. When a GPF occurs, the process is shutdown without any notification. Windows cannot let an app continue once a GPF occurs as it could continue to GPF and may cause the O/S to crash too.

In simple terms, a GPF will always lead to immediate process termination.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Edwin Knoppert]

I had a crash in a thread, as long i didn't close the GPF errormsg, i could still work with the original app.


------------------

[Steve Hutchesson]

Here is a red herring in the DLL discussion, I have a complete
small app that I converted to a DLL with a normal LibMain() and
used the DLL instance handle and when the calling app is closed,
the DLL keeps running as it has its own message loop. It still
runs and closes normally.

I think what happens if you make a BIG mess of it that you end up
with a dead DLL in memory, much the same as an app that has crashed
badly.

Regards,

[email protected]

------------------

[Lance Edmonds]

Steve, that situation is a little different since you are talking about app's that terminate their primary thread normally, but this discussion concerns a GPF occurance (abnormal termination):

If the DLL does not "exit" when the calling EXE is finishes (ie, some reenterant or secondary thread code in the DLL is still running), then the Process hasn't actually finished running... once that DLL code stops running, the whole process will then be fully terminated normally.

The situation with Edwin's comment is similar: Until the GPF dialog is closed, the process will not have been shut down. Once that GPF dialog button is clicked though, the whole Process will be completely and immediately terminated (abnormally) without notification to the Process. If the GPF occurs in a thread, then at a minimum that thread will be affected, but it may affect the whole process. It realistically depends on what is going on at the moment of failure.

In the case of leaving the GPF dialog open, closing the main thread (the main app) may cause unexpected problems, since one of the app's threads is suspended. If the app's remaining threads are halted by a synchronization object that depends on the suspended thread (or some other similar problem that the suspended thread causes), the app will freeze anyway.

Disclaimer: these comments are based on my observations and my understandings of how Windows handles abnormal Process termination. So, can anyone dredge up a good MSDN reference on this topic so we can clarify the exact rules, assuming there is such documentation available? (I'm away from my DEV PC to check for myself!)



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>