This case does not require you to enable exception tracer for host application. You can do it, but it's not required. Typically this approach should be used only when you develop DLLs to be used in non-EurekaLog enabled host. If you have EurekaLog enable for the host - please, try to implement case 1 approach.
Since host application do not necessary have exception tracer - you must to include tracer in each of your DLLs. Each DLL will have exception tracer. All tracers and DLLs will be independent of each other. Each exception will be catched by each exception tracer in each DLL.
Therefore, each DLL must has EurekaLog enabled and project type must be set to "Standalone DLL". Such settings will add exception tracer in each DLL and inject debug information.
Important notice: Windows 2000 does not provide any way to set exception hook in documented way. This means that any exception tracer have to install low-level injecting hook for internal routines. Only single module can install such hook reliably for the same routine. If two or more different modules attempt to install such hook - it will either fail or crash. Therefore, it's highly not recommended to use multiple instances of exception tracers on Windows 2000. Windows XP and above do not have such issues, because newer systems allow you to install arbitrary amount of exception hooks via documented API. This API is called VEH: Vectored Exception Handling. If you can't use single instance of exception tracer and have to support Windows 2000: we suggest to use Delphi 2009 or above and disable "Use low-level hooks" option. Delphi 2009 introduced better integration between application and exception tracer. It allow you to react on hi-level exceptions without need to install low-level hook (however, low-level hook still may be installed to capture CPU state). Combination of Windows 2000 and any IDE before 2009 (such as Delphi 7) will not work reliably for multiple instances of exception manager - regardless of options in those modules.
Host application loads multiple DLLs with "Standalone DLL" profile
Let's see this on practice. We'll use the same host application for this example. Of course, it has EurekaLog enabled, but remember that it's not necessary. You may turn EurekaLog off for host application, if you want. Actually, let's do this for the sake of better illustration. So, open your host application project, disable EurekaLog for it and recompile (all source code will remain the same as above).
We'll use the same DLL project for this example. We'll make only few changes. Open DLL project and change project type from "Lightweight DLL" to "Standalone DLL". This will also replace EAppDLL unit in uses clause with multiple EurekaLog units. Also, go to dialogs options and change "None" to any dialog that you like. We will use "MS Classic" for this example.
So full changed code will looks like:
library Project2;
Save all and recompile. Run application and hit all 3 buttons:
Typical exception in host application
Exception escaped DLL
Exception did not escape DLL, it was handled by DLL by displaying complete bug report This example gives you full EurekaLog support within DLL, but host .exe completely lacks any support. It doesn't even have debug information, so even exception tracer from DLL is unable to display call stack for exe. Of course, this can be fixed by enabling EurekaLog for exe, or adding debug information by any other means (e.g. deploying .map file, injecting JDBG information, etc.). Just remember that host application is not always under your control.
See also:
|