As you should already understood by now: rule #1 when working with exceptions in DLLs is "never let exception escape DLL". That because caller may not know how to work with exception object generated by different programming language. For example, a Delphi .exe file have no idea to to read exception message from Microsoft C++ exception; it doesn't know how to properly release exception object after exception is handled. Therefore, all exceptions in DLL functions must be captured and handled by translating them to error code or other error signature as required by DLL API.
How this should be done? That highly depends on what your DLL API is. This also depends on what framework you do use. There are 3 possible cases:
See also: Creating bug reports for DLL exceptions.
What if I don't want to follow best practice rules?
You may want not to follow this rule ("never let exception escape DLL"). For example, you are sure that both host and all DLLs are always compiled by the same compiler version. Such usage case usually means using packages instead of DLLs. However, you may want to use DLLs for some other reasons.
In this case you can instruct EurekaLog to handle exceptions from other modules. You can enable this behavior by disabling "Capture stack only for exceptions from current module" option. You should probably disable chained exceptions support for DLLs that let exceptions escape DLL and be handled by the caller. This feature requires ability to track life time of exceptions objects. This is not possible for general case (e.g. host and DLL are compiled by different compilers and there is no assist from RTL for tracking exception objects). This feature may work in some specific configurations. See this article for more information.
Such usage case means using a single instance of exception tracer in application. Host .exe must have exception tracer with above mentioned options changed and enabled support for all necessary debug information formats. DLLs must have debug information source, but no exception tracer.