TRACEBACKQQ keeps DLL stuck in memory!

[rahzan]

An (in-process) com server calls a DLL. If a routine in the DLL throws an execption of any kind it kills the entire process including the caller app of the comserver.

Add execption catching via a c-wrapper inside the DLL, which then reports a caught exception the same as it would expected terminal errors. for example:

real:: B(5)
A=B(0) !out of bounds error caught by c-wrapper whose handler sets an error code
vs.
if(i==0)then; errorcode=-2; return !Expected terminal error
A=B(i)

I have verified that a termination via a caught exception traces the same execution path as expected errors and hence all clean up is done the same for both cases.
This INCLUDES the freeing of the com server via the main caller app.

However, in the case of the c-wrapper-caught-execption, the DLL seems to stay stuck in the memory, so that it is not possible to overwrite it by the compiler, after the correction is made and recompiled. That is not Until the main app is closed. i.e. upon recompile:

fatal error LNK1104: cannot open file "xxx.dll"

I have found that the difference is a TRACEBACKQQ call in the execption handler
(intended only to get the failing line no).
for some reason the TRACEBACKQQ keeps the DLL stuck in memory, while without it things proceed just like expected errors if an execption is caught.

Is there a way to prevent TRACEBACKQQ from doing this?
or
Is there a way to force the an app importing the DLL lib to explicitly say that it is finished with
the DLL and it MUST close?

Any hints will be appreciated.
Tim