Root > Advanced topics > Using EurekaLog in DLL > Using exception tracer tool in DLLs > Multiple instances of exception tracer

Multiple instances of exception tracer

Previous pageReturn to chapter overviewNext page   

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;
 
uses
  // Automatically generated:
  EMemLeaks, 
  EResLeaks,
  EDialogWinAPIMSClassic,
  EDialogWinAPIEurekaLogDetailed,
  EDialogWinAPIStepsToReproduce,
  EDebugExports,
  EDebugJCL,
  ExceptionLog7,
 
  // Added manually:
  Windows,
  SysUtils,
  Classes,
  EBase;
 
{$R *.res}
 
procedure Test1;
begin
  raise Exception.Create('Error Message');
end;
 
procedure Test2;
begin
  try
    raise Exception.Create('Error Message');
  except
    on E: Exception do
      // Ask exception manager in DLL to process this exception
      HandleException(E); // EBase unit
  end;
end;
 
exports
  Test1, Test2;
 
end.

 

Save all and recompile. Run application and hit all 3 buttons:

 

 

Typical exception in host application
There is no bug report, since host application do not have exception tracer

 

 

Exception escaped DLL
There is no bug report, since exception was caught by host application (without exception tracer)

 

 

Exception did not escape DLL, it was handled by DLL by displaying complete bug report
Call stack shows only lines within DLL
There is no information about exe, because exe do not have any debug infomation
 

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:




Send feedback... Build date: 2023-09-11
Last edited: 2023-03-07
PRIVACY STATEMENT
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.


Permanent link to this article: https://www.eurekalog.com/help/eurekalog/dll_multiply_instances.php