I have old code, which is working fine with previous version of EurekaLog (5.x/6.x). It does not work with EurekaLog 7. I set all options as outlined in guides, but EurekaLog is not invoked automatically for exceptions. My code assigns Application.OnException handler.

Reason:

Previous EurekaLog versions ignored whenever Application.OnException event was set or not. This behavious conflicted with default behaviour of Application object.

EurekaLog 7 changes the way to work with Application.OnException event. EurekaLog 7 respects this event: if event handler is NOT set - then EurekaLog will handle exceptions automatically; if event handler is set - then EurekaLog assumes that you want to handle exceptions by yourself.

Solution:

That depends on what you want.

1. If you want EurekaLog to handle exception - you don't need Application.OnException handler. Just remove it:
   1. You can use {$IFDEF EUREKALOG} or EBase.IsEurekaLogActive to determinate if you need to install Application.OnException or not. You can install your own handler for Application.OnException when you compile application without EurekaLog.
   2. You can move your code to OnExceptionNotify handler.
2. If you want to run your custom code for each exception - then you can keep your handler:
   1. You can call EExceptionManager.ExceptionManager.ShowLastExceptionData inside your Application.OnException handler to invoke EurekaLog's processing for current exception.
   2. You can move your code to OnExceptionNotify handler and use AHandle argument to switch between EurekaLog's processing and your code.

See also:

• EurekaLog is not called when I am using TApplicationEvents component or (VCL.)AppEvnts unit

I have old code, which is working fine with previous version of EurekaLog (5.x/6.x). It does not work with EurekaLog 7. I set all options as outlined in guides, but EurekaLog is not invoked automatically for exceptions. My code uses TApplicationEvents component (from VCL.AppEvnts unit).

Reason:

Previous EurekaLog versions ignored whenever Application.OnException event was set or not. This behavious conflicted with default behaviour of Application object.

EurekaLog 7 changes the way to work with Application.OnException event. EurekaLog 7 respects this event: if event handler is NOT set - then EurekaLog will handle exceptions automatically; if event handler is set - then EurekaLog assumes that you want to handle exceptions by yourself.

TApplicationEvents component from VCL.AppEvnts unit overrides Application.OnException event handler to provide TApplicationEvents.OnException.

The problem is that Delphi VCL do not have multi-cast events, thus it is not possible to have both TApplicationEvents and EurekaLog to handle TApplication.OnException. Since EurekaLog is initialized very first and TApplicationEvents is constructed inside form later - TApplicationEvents will be the last one to set TApplication.OnException handler, it wins.

Solution:

That depends on what you want.

1. If you do not need TApplicationEvents component or can live without it (e.g. by assigning event handlers for TApplication manually instead of using component) - do this. Remove TApplicationEvents component and (important: see below) remove VCL.AppEvnts unit.
2. If you need TApplicationEvents component:
   1. If you want EurekaLog to handle exception - you need to pass exception to EurekaLog:
      1. Assign TApplicationEvents.OnException event handler and call EBase.HandleException to invoke EurekaLog for this exception.
   2. If you want to run your custom code for each exception (e.g. if you already have a TApplicationEvents.OnException handler):
      1. You can call EBase.HandleException inside your own TApplicationEvents.OnException handler to invoke EurekaLog's processing for specified exception.

Important Note:

TApplicationEvents component overrides TApplication.OnException event even if you do not assign TApplicationEvents.OnException property. Also, (in some Delphi versions) VCL.AppEvnts unit overrides Application.OnException event even if no TApplicationEvents component is created. Be sure to manually remove VCL.AppEvnts unit from your application if it is not needed.

Note:

If you did not assign TApplicationEvents.OnException hander - then RTL will invoke Application.ShowException to show error dialog. EurekaLog can catch this call and show EurekaLog error dialog instead - but only if "low-level hooks" option is enabled.

See also:

• EurekaLog is not called when I have Application.OnException event assigned

If I compile my project in "Debug" profile - everything works fine. But if I compile it in "Release" profile - EurekaLog does not work. Even though debug information options are set properly.

Reason:

This is a known bug (archive, QP) in C++ Builder.

Solution:

Sadly, there is no fix so far. You may try to use workarounds (e.g. using "Debug" profile).

Checked EL version: 7.2.2

Checked C++ Builder version: XE2-XE8

Internal Bug ID: 1086

See also:

• I can not debug my application after adding EurekaLog

I do not see "EurekaLog" stage during compilation.

Solution:

1. Check that EurekaLog IDE expert is installed: do you see EurekaLog items in IDE's main menu? If no - you must install EurekaLog IDE expert, either manually or by using "Manage EurekaLog in IDEs" tool;
2. Check that background compilation option is off;
3. Check that show compiler progress option is on;
4. Do you have "EUREKALOG" conditional symbol defined for your build configuration profile?
5. Update all other IDE extensions (such as CNPack) to the latest version.
6. Do you have IDE experts that may modify .map file installed? Such as JEDI (JCL). Check that option to delete .map files is NOT enabled.
7. Do you have any errors in IDE's "View" / "Messages" / "Build" window?

I get "Installer's executable is not signed" / "Installer's executable has not been signed" message when installing EurekaLog on Windows 2000, Windows 2003, or Windows XP.

Reason:

Missing SHA-2 (SHA-256/SHA-512) support is the reason for failed signature check on installer, because certificates for HTTPS and digital signature use SHA-2. 

• Windows 2000: does not support SHA-2.
• Windows 2003: does not support SHA-2 out of the box. Support for SHA-2 can be installed by installing KB 938397 (for Service Pack 1); KB 968730 (for Service Pack 2). We also highly recommend to install KB 2868626.
• Windows XP: support for SHA-2 is available since Windows XP SP3. We also highly recommend to install KB 2868626.

Solution:

• Windows 2000: please, contact our support, we will help you to install EurekaLog manually.
• Windows 2003: install Service Pack 2, install KB 968730, install KB 2868626. Verify that:
  • version of crypt32.dll is 5.131.3790.5235 or higher;
  • version of wcrypt32.dll is 5.131.3790.5235 or higher;
  • version of rsaenh.dll is 5.2.3790.3959 or higher;
  • version of w03a3409.dll is 5.2.3790.5235 or higher.
• Windows XP: install Service Pack 3, install KB 2868626. Verify that:
  • version of crypt32.dll is 5.131.2600.6459 or higher;
  • version of xpsp4res.dll is 5.1.2600.6459 or higher;
  • version of rsaenh.dll is 5.1.2600.5507 or higher.

You can verify that SHA-2 support is available in your system by opening our web-site in Internet Explorer:

• If SHA-2 support is present - you will see our web-site.
• If your system does not support SHA-2 - you will see "The page cannot be displayed" error message.

It is important to use Internet Explorer specifically for this test, as it uses system DLLs as the back-end, while other browsers (like Chrome, Firefox, Opera, etc) cary their own implementation, so they can open SHA-2 web-site even when host system does not support SHA-2.

Download links (English versions):

• Windows XP x86:
  • KB 968730
  • KB 2868626
• Windows XP x64:
  • KB 968730
  • KB 2868626
• Windows 2003 x86:
  • KB 968730
  • KB 2868626
• Windows 2003 x64:
  • KB 968730
  • KB 2868626

You may need to obtain corresponding updates manually. E.g. if you have OS in different language.

Additional notes:

• Please note that EurekaLog's code itself still works on Windows 2000, Windows 2003, and Windows XP systems. For example, you can develop your application on Windows 7 and deploy it on Windows 2000 - it will work just fine. Only installation of EurekaLog is not supported for Windows 2000.
• We used double-signing earlier (e.g. sign with both SHA-1 and SHA-2 at the same time). Unfortunately, our old SHA-1 certificate has expired a long time ago, and all new certificates are available in SHA-2 only. Sadly, we can no longer support installation on Windows 2000 - simply because we can not get SHA-1 certificate anymore. 

See also:

I get "The connection with the server was reset" or "An error occurred in the secure channel support" errors

I have installed EurekaLog, but I get "The procedure entry point XYZ could not be located in the dynamic link library ZXY" error message when I start IDE.

Reason:

EurekaLog is compiled against latest builds of IDEs. New IDE builds may be not binary compatible with older builds. Therefore EurekaLog compiled for one IDE build may fail to load with another IDE build. 

Just to clarify: we are talking about same IDE version, but with different builds/updates. For example, RAD Studio 10.3 Rio Update 2 (10.3.2) is not compatible with RAD Studio 10.3 Rio Update 1 (10.3.1) and earlier (10.3). Therefore you have to use EurekaLog built against 10.3.2 with 10.3.2, you can not use EurekaLog built for 10.3.2 with 10.3.1 or 10.3.

Unfortunately, it is not possible to install two different versions of the same IDE on a same machine at same time. Therefore we can not prepare installer which will contain files for each possible IDE update ever.

Solution:

Usually EurekaLog's installer will warn you when you are installing latest EurekaLog's build over old IDE's build.

1. Update your IDE to latest version;
2. Install all available IDE's updates, patches, and hot-fixes;
3. If you are unable to obtain a latest IDE's patches - use older EurekaLog's build (compiled for your update pack).
4. If you want to use the latest EurekaLog build with older version of IDE (without latest IDE updates installed) - you can recompile EurekaLog for your specific IDE version (for EurekaLog Enterprise edition only; comes with full source code).

See also:

• My IDE crashes with EurekaLog 7
• "File XYZ was compiled with different version of ABC" error
• "Could not compile used unit XYZ" error
• "File not found: XYZ" error
• Compiling project with EurekaLog fails with the F2084 Internal Error: URW8074

I get one of the following errors when I visit EurekaLog's web-site, or trying to install EurekaLog:

• 12031 / ERROR_INTERNET_CONNECTION_RESET ("The connection with the server was reset");
• 12157 / ERROR_WINHTTP_SECURE_CHANNEL_ERROR ("An error occurred in the secure channel support").

Reason:

EurekaLog uses WinInet / WinHTTP to make secure internet connections. Therefore, EurekaLog relies on operating system's support for SSL/TLS. The mentioned errors occur when client and server can not negotiate on common encryption protocol or exact details (ciphers).

Solution:

• Install latest service pack for your operating system;
• Install latest Internet Explorer for your operating system;
• Install latest updates for your operating system;
• Enable latest encryption protocols, disable obsolete protocols:
  • Open Internet Explorer;
  • Go to "Tools" / "Internet Options" menu;
  • Switch to "Advanced" tab;
  • Scroll down to "Security" section;
  • Disable "SSL 2.0", "SSL 3.0", enable "TLS 1.0" or "TLS 1.1", "TLS 1.2", and "TLS 1.3" (depending on which options are available; we recommend to disable "TLS 1.0" when "TLS 1.1", "TLS 1.2", or "TLS 1.3" options are available and enabled);
• Download license file manually from web-site using another machine

Important Note: EurekaLog's web-site uses SHA-2 certificate for SSL/TLS connection. Therefore, support for SHA-2 must be present in your operating system when you install EurekaLog. EurekaLog itself does not require SHA-2 support.

See also:

• Unable to install EurekaLog on Windows 2000, Windows XP, Windows 2003

My application is fast when Eurekalog is disabled. But it runs significantly slower with EurekaLog enabled, like 20-50 times. For example, loading data without EurekaLog takes about 0.5 seconds, with EurekaLog - 50 seconds.

Reason:

EurekaLog is an exception tracer tool. This means that EurekaLog's code is not executing in your application unless:

1. Exception occurs;
2. Memory allocation or deallocation occurs (and you have memory checks enabled - which is a default);
3. Thread starts or stops (and you have low-level hooks enabled - which is a default);
4. Startup delays can be caused by EurekaLog starting up and preparing debug information (compressing debug information is not enabled by default);
5. Startup delays can be caused by EurekaLog verifying your executable file (disabled by default);
6. EurekaLog is running in troubleshooting logging mode (disabled by default).

This means that EurekaLog can not possibly affect performance of your application unless your application is:

1. Raising a lot of exceptions;
2. Allocating large amount of (small) memory blocks;
3. Constantly restarting threads;
4. Large application stores debug information as packed;
5. Large application asks EurekaLog to verify its checksum (CRC);
6. Running EurekaLog in run-time debug mode.

First, you need to find out which part of EurekaLog is slowing you down. In most cases: the performance issues are caused by enabled memory leaks checks (item #2), because EurekaLog has to build a full call stack for EACH memory allocation and deallocation in your application.

1. Start with checking if your code raises a lot of exceptions. For example, your or 3rd party code may use constructs like this:

try
  // do something
except
  Result := Default;
end;

Normally, you should see a debugger's notification about an exception. However, certain debugger's options could mask them (e.g. exception notifications could be disabled in settings). Please, go to your debugger's settings and:

• enable exception notifications;
• remove exceptions from the ignore list.

Run your code again and watch for exceptions.

Alternatively, you can create a run-time log. Open the produced log file and look for EurekaLog's hooks being called.

2. If large amount of exceptions are not the issue then try to find out if your or 3rd party code is doing a lot of memory allocations. You can review your code to ensure it does not abuse the memory manager. For example, allocating a single array/cache is better than allocating millions strings or objects.

You can test if memory operations are causing the issue by going into EurekaLog's memory options and disabling the "Enable extended memory manager" option.

Important: do not keep the "Enable extended memory manager" option disabled. Disabling the option is only meant as a diagnostic tool. Please, refer to the "Solution" section below to learn about the possible ways to fix memory-related performance issues.

3. If memory operations are not the issue - try to find out if your or 3rd party code is spawning a lot of threads. Again, you can review your code to ensure that it does not abuse threads. For example, a single thread pool is much better to run short tasks than creating millions threads.

You can test if threads are causing the issue by going into EurekaLog's advanced options and setting the "Low-level injection hooks" option to "Allow for current module only" or "Disabled".

Important: do not permanently set the "Low-level injection hooks" option to anything other than "Allow all". Changing the option is only meant as a diagnostic tool. Please, refer to the "Solution" section below to learn about the possible ways to fix thread-related performance issues.

4. If threads are not the issue - check if you have a (very) large application (or a slow network drive) and have enabled the "Compress debug information" option. Storing debug information compressed means that EurekaLog has to unpack it before it can be used - which can take time if your application is very large. If your application consists of a lot of BPLs and DLLs - ensure each BPL package and DLL has debug information. For example, you need to deploy *.jdbg files that come with your IDE to get debug information for RTL/VCL packages. See for more info.

5. If the debug information is not the issue - check if you have a (very) large application (or a slow network drive) and have enabled the "Check file corruption" option. Enabling this option will cause EurekaLog to read your entire executable in order to calculate its checksum (CRC). 

6. If CRC calculation is not the issue - check if you are running EurekaLog in debugging mode. Debugging is OFF by default and can be activated by:

• passing the --el_debug command line switch;
• creating the -el_debug suffixed file;
• using ELogOpen + EL_Debug in the source code.

See this article for more information.

Solution:

Once you have determined which part of EurekaLog affects your code then you can fix it either by altering your code or adjusting EurekaLog.

1. If the performance issue is caused by exceptions:

• Consider rewriting your code, so it won't use exceptions as means of normal workflow. For example, constructs like:

  try
    I := StrToInt(S);
  except
    I := -1;
  end;

  can be replaced with:

  I := StrToIntDef(S, -1);

  or:

  if not TryStrToInt(S, I) then
    // Handle bad conversion

• Alternatively, you can disable EurekaLog for expected exceptions like this:

  SetEurekaLogStateInThread(0, False);
  try
    I := StrToInt(S);
  except
    I := 0;
  end;
  SetEurekaLogStateInThread(0, True);

2. If the performance issue is caused by memory operations:

• Consider rewriting your code so it will use large memory blocks to store many smaller items. For example, an array of records can be an efficient replacement for an array of objects;
• If only parts of your code are affected - you can disable EurekaLog for such code:

  DisableMemLeaksRegistering;
  try
    // some long executing code
  finally
    EnableMemLeaksRegistering;
  end;

  or:

  SetEurekaLogStateInThread(0, False);
  try
    // some long executing code
  finally
    SetEurekaLogStateInThread(0, True);
  end;

• If you can not wrap all code in the above mentioned constructs - go to EurekaLog's memory options and disable the "Catch memory leaks" option. Collecting call stacks for each memory allocation takes a lot of time, so disabling this feature should speed up things significantly. Please note that you may keep the "Catch memory leaks" option enabled, because the "Active only when running under debugger" options is also enabled by default, so leaks checks will be on under debugger (developing) and will be off when run outside IDE (production);
• If above did not help - disable all memory features, except the "Enable extended memory manager" option. We do not recommend to turn off the "Enable extended memory manager" option unless absolutely needed;
• If above did not help - disable the "Enable extended memory manager" option. Please, refer to help to learn more about the implications of this decision.

3. If the performance issue is caused by threads:

• Consider rewriting your code, so it will use thread pool(s);

• If only parts of your code are affected - you can disable EurekaLog for such code:

  SetEurekaLogStateInThread(0, False);
  try
    // some long executing code
  finally
    SetEurekaLogStateInThread(0, True);
  end;

• You can disable EurekaLog for hooking threads by going into EurekaLog's advanced options and setting the "Low-level injection hooks" option to "Allow for current module only" or "Disabled". Please, refer to help to learn more about the implications of this decision.

4. If the startup performance issue is caused by debug information then do not compress it.

• We recommend that you store debug information unpacked (which is a default) - that way it is ready for immediate use. E.g. it is a typical "trade memory for speed" optimization.
• You can play around with other debug information options in order to minimize debug information size, but we do not recommend it as doing so may decrease detalization level of EurekaLog's reports. EurekaLog has the statistics feature, which you can use for troubleshooting.
• You can either disable the "DLL Exports" debug information provider (not recommended) or supply debug information for your BPLs/DLLs. See for more info.

5. If the startup performance issue is caused by CRC calculation then turn off the corresponding option. There is no other way around it. Either you are checking your executable - in which case EurekaLog has to read it from start to end. Or you don't - in which case Windows will read/load your executable only as neccessary (e.g. progressive loading on demand).

6. If the performance issue is caused by debugging mode - simply turn it off. The run-time debugging is not supposed to be used for developing nor production. This feature exists for troubleshooting purposes only. It is not enabled by default and should be turned off immediately after solving an issue for which this mode was enabled in the first place.

See also:

• Out of memory when using EurekaLog
• EurekaLog-enabled application starts up x2 times slower on Windows 2016
• How to enable/disable EurekaLog at run-time?
• How to enable EurekaLog for production, disable for development?
• How to use different settings for development/production?

My application runs just fine when compiled without EurekaLog.

However, if I compile it with EurekaLog:

• I am being stopped at the ELowLevel.DebugBreak being called from EBase.PanicModeOn when run under debugger;
• If I continue execution (or simply run outside debugger) - I get the following error dialog:

Reason:

EurekaLog has memory checks enabled by default. Please note that "leaks checks" and "memory checks" are two different things. You can enable memory checks while having leaks checks disabled (which is a default case). On the other hand, you can't have leaks checks enabled while memory checks are disabled.

If memory checks are enabled: each memory allocation in your application will have a larger size to store extra information (header/footer) required for checks to work:

• Leaks checks are disabled (default): each memory allocation will be larger on 32 bytes (to store block's info, flags, sentry values, see ETypes.TPointerDummyRecord, ETypes.BlockDummyOverHead);
• Leaks checks are enabled: each memory allocation will be larger on 272 bytes (to store call stack, see ETypes.TPointerRecord, ETypes.TPointerFooter, ETypes.BlockOverHead, ETypes.BlockOverFoot).

For example:

1. If you allocate 8 bytes 1'000 times: your application would allocate (8 + 32) x 1'000 = 40'000 bytes instead of the usual 8'000 bytes resulting in the overhead from EurekaLog (not including overhead from memory manager itself) of 32'000 bytes (x5 overhead);
2. On the other hand, if you allocate 200 bytes 1'000 times: your application would allocate (200 + 32) x 1'000 = 232'000 bytes instead of the usual 200'000 bytes resulting in the same overhead of 32'000 bytes, but now it is just x1.16 overhead;
3. Finally, if you disable memory checks altogether (the "Enable extended memory manager" option): EurekaLog won't be installing a filter on your memory manager, thus all your memory allocations will be unaffected by EuekaLog resulting in 0 overhead.

Conclusion: the larger your allocated memory blocks are = the less overhead. Worst case is like allocating simple TObjects - which are just 8 bytes (.InstanceSize method).

Diagnostic:

• The "Allocating" value indicates argument for the GetMem, AllocMem or a similar function. It indicates how much bytes your application tried to allocate when it failed. This value may be missing - for example, if memory checks are disabled (so RTL's default memory manager is used).
• The "Largest available" value indicates the size of the largest continuous free (unoccupied) memory block in your application. This value is obtained by scanning your address space looking for a MEM_FREE region of a largest RegionSize.
• The "Total allocated (RTL)" value indicate how much memory was allocated via RTL memory functions (GetMem, AllocMem, etc.). It can be either a single value or two values: 
  • One value: it is shown when EurekaLog memory filter is not installed, so all allocations go through the default RTL memory manager (or a 3rd party memory manager, if you have one installed);
  • Two values: it is shown when EurekaLog memory filter is installed, so allocations go through EurekaLog. Two values indicate total size of all allocations without and with overhead from EurekaLog.
• The "Total allocated (virtual)" value is equal to ullTotalVirtual - ullAvailVirtual from the GlobalMemoryStatusEx. It indicates how much memory is allocated (or reserved) in your address space. This includes loaded modules (exe, DLL, bpl), memory allocated via RTL, memory allocated by 3rd party code (system, DLLs, etc).
• The "Total available (RAM)" and "Total available (page file)" indicate free space in RAM and page file respectively.
• The "Total (RAM)" and "Total (page file)" indicate total size of RAM and page file respectively.

You need to analyze these values in order to understand why "out of memory" exception was thrown.

IMPORTANT: keep in mind - the memory is not static, it is always changing. It means, the memory will be changed between the moment exception was thrown and bug report was created. Therefore, various values from the error message and from the bug report may not be 100% accurate. Don't expect a perfect match, but look for generic patterns - see examples below.

A). If the "total allocated (virtual)" value is close to the possible maximum of address space for your application:

• 2 Gb for normal 32-bit app;
• 3 Gb for large address awared 32-bit app on 32-bit system;
• 4 Gb for large address awared 32-bit app on 64-bit system;
• 8 or 128 Tb for 64-bit app (depends on Windows version).

then you have a real out of memory error, because you have exhausted all free memory in your application.

For example:

Allocating: 1112 (1.09 Kb)
Largest available: 1183744 (1.13 Mb)
Total allocated (RTL): 1887792563 (1.76 Gb) (1945427109 (1.81 Gb))
Total allocated (virtual): 2076430336 (1.93 Gb)
Total available (RAM): 21130706944 (19.68 Gb)
Total available (page file): 20763758592 (19.34 Gb)
Total (RAM): 34297835520 (31.94 Gb)
Total (page file): 38592802816 (35.94 Gb)

As you can see, the "total allocated (virtual)" value is 1.93 Gb, which is pretty close to the possible maximum of 2.0 Gb for a normal 32-bit app. Therefore, it is an error message about real out of memory error, because you have used up all of your 2 Gb of available memory.

B). If the "total allocated (virtual)" value is not near the possible maximum limit for your application (outlined in the section A above), but the "total available (page file)" value is very low: you have a real out of memory error. It is not because you have exhausted all free memory in your application, but it is because your system does not have enough memory available.

For example:

As you can see, while the "total allocated (virtual)" value (833.80 Mb) is far less than 2 Gb for a 32-bit app, but the paging memory has run out ("total available (page file)" is very low).

• For example, if your system has 8 Gb of RAM and has swap/paging file disabled, then system will have just 8 Gb of memory for all applications. It means no application on such system can allocate more than 8 Gb - which is far less of 8/128 Tb of possible max for 64-bit app.
• Additionally, if other applications would occupy 7 Gb of memory already, your app would have just 1 Gb to run - which is less than even 2 Gb of possible max for 32-bit app.
• Finally, a system may have swap/paging file, but its size may be limited by some value. Say, a system can have 8 Gb of RAM with 16 Gb of swap/paging file. The size of the swap/page file could be limited by system's settings or by simply running out of a free HDD space. Again, maximum memory size for all apps will be limited to 8 + 16 Gb, and will be less for your own app - depending on how many memory other apps have allocated.

Specifically, the total amount of available memory for the system from the sample error message above is 1 Gb of RAM with 512 Mb of swap/page file, resulting in 1.5 Gb of total available memory.

So you may hit this limit, and while the "largest available" value would still show the largest continuous free block in your address space to be sufficiently large (or even huge for 64-bit apps), but the system doesn't have free memory to allow your app to actually allocate more memory.

C). If the "total allocated (RTL)" value has two numbers and first number is significantly smaller than the second number: you have out of memory error because of the overhead from EurekaLog.

For example: 

Allocating: 1112 (1.09 Kb)
Largest available: 1183744 (1.13 Mb)
Total allocated (RTL): 373146095 (355.86 Mb) (2072498176 (1.93 Gb))
Total allocated (virtual): 2072498176 (1.93 Gb)
Total available (page file): 20763758592 (19.34 Gb)
Total (page file): 38592802816 (35.94 Gb)

The second number in "total allocated (RTL)" (1.93 Gb) is significantly larger than the first number (355 Mb) - which means your code allocated a lot of small memory blocks (objects), so now you have a large overhead (about x5.4 times). In other words, you have out of memory error because of additional overhead from EurekaLog memory/leaks checks.

On the other hand:

For example:

Allocating: 1183744 (1.13 Mb)
Largest available: 867882 (847.54 Kb)
Total allocated (RTL): 686788239 (654.97 Mb)
Total allocated (virtual): 1086788239 (1 Gb)
Total available (page file): 20763758592 (19.34 Gb)
Total (page file): 38592802816 (35.94 Gb)

As you can see, there is plenty of free memory available in your application, because the "total allocated (virtual)" value (1 Gb) is not reaching the limit (2 Gb for a normal 32-bit app, see section A above) and the "total available (page file)" value is not hitting the system's limit (see section B above). However, the "largest available" value is very small - smaller than the requested memory (1.13 Mb). It is the classic symptom of a memory fragmentation: you try to allocate a (large) block and you can't, even though you appear to have enough free memory.

F). If the "largest available" value is more than few Mb in size and is significantly larger than the "Allocating" value, while the "total allocated (virtual)" value is not close to the maximum possible limit (see section A above) and the "total available (page file)" value is large enough (see section B above): you probably do not have an out of memory error at all. 

You see, memory allocation in Delphi (Builder) is implemented like so:

function GetMem(Size: NativeInt): Pointer;
begin
  if Size = 0 then
    Exit(nil);
  Result := MemoryManager.GetMem(Size);
  if Result = nil then
    Error(reOutOfMemory);
end;

As you can see, any memory allocation error is treated like "out of memory" error. So, what this error is saying is "unable to allocate memory" for whatever reason. It could be due to memory corruption bug somewhere. For example, a memory bug could damage control structures of the memory manager.

For example:

Allocating: 1112 (1.09 Kb)
Largest available: 1183744 (1.13 Mb)
Total allocated (RTL): 1193750159 (1.11 Gb)
Total allocated (virtual): 2076430336 (1.93 Gb)
Total available (page file): 20763758592 (19.34 Gb)
Total (page file): 38592802816 (35.94 Gb)

Notice while the "largest available" value (1.13 Mb) is larger than the "allocating" value (1.09 Kb), but it is not significantly larger.

The reason the "largest available" value is larger than the "allocating" value is because your application does not allocate memory directly from the system. Instead, your allocation requests go to your app's memory manager, which is the FastMM by default (on modern IDEs). Memory manager allocate larger chunks from the system and then uses these chunks to serve memory allocation requests from your code. Specifically, FastMM uses chunks of about 1.2 Mb in size. As you can see the available free memory (1.13 Mb) is less than 1.2 Mb required for FastMM to allocate a new chunk. Therefore, this case is a real out of memory error.

Another example:

Allocating: 2097152 (2 Mb)
Largest available: 1183744 (1.13 Mb)
Total allocated (RTL): 1193750159 (1.11 Gb)
Total allocated (virtual): 2076430336 (1.93 Gb)
Total available (page file): 20763758592 (19.34 Gb)
Total (page file): 38592802816 (35.94 Gb)

Notice the "largest available" value (1.13 Mb) is smaller than the "allocating" value (2 Mb). Therefore, this case is a real out of memory error.

On the other hand:

Allocating: 1112 (1.09 Kb)
Largest available: 138109829251072 (125.6 Tb)
Total allocated (RTL): 3522839902 (3.28 Gb)
Total allocated (virtual): 4914884608 (4.58 Gb)
Total available (page file): 20763758592 (19.34 Gb)
Total (page file): 38592802816 (35.94 Gb)

Notice the "largest available" value (125.6 Tb) is larger than few Mb and it is significantly larger than the "allocating" value (1.09 Kb), while the "total allocated (virtual)" is nowhere near close to the possible max and the "total available (page file)" indicate plently of free swap/page file space. All of this means: there is plenty of free memory in application, but request to allocate memory fails. Therefore, it is not a real out of memory error. It is a memory corruption error.

Solution:

A). Insufficient system's memory.

If you have insufficient system's memory (not enough RAM or/and swap/page file) - fix it. Enable swap/page file (if disabled), increase size of the swap/page file, and/or install more RAM.

You may follow other advices below (especially if you have a large overhead from EurekaLog), but increasing your system's memory is a faster and easier way.

B). Memory corruption.

If you have a memory corruption error - start searching for it.

We would recommend to enable memory and leaks checks in EurekaLog. Just be sure leaks checks are enabled (for example, you don't run your app outside debugger while having the "Active only when running under debugger" option enabled).

If it did not help - try to use full-featured debugging memory manager. Such as FastMM in full debug mode, SafeMM, etc.

If it did not help - try to review your code.

C). Memory fragmentation.

Memory fragmentation is when most of your memory is allocated in a large number of non-contiguous blocks, or chunks - leaving a good percentage of your total memory unallocated, but unusable for most typical scenarios. If you have a memory fragmentation - start by reviewing your code. 

First, ensure your code does not leak. Even a smallest leak of just 1 byte being repeated enough times can occupy your free memory dividing it into smaller blocks, thus causing fragmentation. Therefore, check your application for memory and resource leaks. Fix all leaks that you can find.

Second, once you are sure there are no leaks, and you left with pure memory fragmenation: review your code. Memory fragmentation is caused by the behavior of an application, it is about greatly different allocation lifetimes. In other words, some blocks/objects are allocated and freed regularly while other persist for long periods of time. The best thing you can do to address this type of a problem is logically divide objects by lifetimes. Basically, you want to have two (or more) heaps (pools) of temporal and permanent blocks/objects, or blocks/objects of a similar life-time. For example, if your application opens a file/document, you may want to allocate everything related to that file/document in a standalone heap/pool.

Additionally, you can reduce memory fragmentation by reducing the amount you allocate / deallocate. For example, you can use dynamic arrays as pool of various things, so instead of allocating a million of small objects - it is better to allocate a single array of small records. See also the "C). Out of memory" section below.

Notice that you can override the .NewInstance method for some classes to allocate objects differently: say, on an array or via specific heap.

Finally, you may try to replace your memory manager with another one that offer low fragmentation allocations.

Generally you don't need to worry about memory fragmentation, unless your application is long-running and does a lot of allocation (and freeing). It starts to be a problem when you have a mix of short-lived and long-lived blocks/objects on a long distance. Therefore, if you have such application (such as service) - you may be able to restart it from time to time, if it is possible - thus avoiding memory fragmentation error in the first place.

D). Out of memory due to overhead.

Running out of memory because of EurekaLog's overhead means your code allocates a lot of small memory blocks (objects).

If you have out of memory error because of added EurekaLog's overhead:

1. If you need/want EurekaLog's features of memory and/or leaks checks: you can follow advices from the "E). Out of memory" section below to reduce memory footprint of your application and/or you can follow the "C). Memory fragmentation" section above to refactor your code to allocate memory more efficiently (less allocations, larger blocks);
2. If you don't need/want EurekaLog's features of memory and/or leaks checks: you can disable leaks checks in EurekaLog by unchecking the "Catch memory leaks" option. If that did not help - you can disable memory checks in EurekaLog by unchecking the "Enable extended memory manager" option.

E). Out of memory.

You have out of memory error, but it is not because of EurekaLog's overhead. For example, your application allocates 1.8 Gb of memory and runs just fine, but if you add large enough code to your application (not just EurekaLog, any code of a sufficient size) - your application may not fit inside 2.0 Gb. If this is the case, you have no other choice but to decrease memory footprint of your application.

1. Enable the "large address aware" PE flag, which will give your 32-bit app an extra 1 Gb of memory on 32-bit systems and extra 2 Gb of memory on 64-bit systems:
   1. You can use "Project" / "Options" menu to open project's options, then enable the "Building" / "Delphi Compiler" / "Linking" / "Enable large addresses" option on modern IDEs;
   2. You can add {$LARGEADDRESSAWARE ON} directive on modern IDEs;
   3. You can add the {$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE} directive if your IDE does not support {$LARGEADDRESSAWARE ON} (don't forget to include the Windows unit for the declaration of the IMAGE_FILE_LARGE_ADDRESS_AWARE).
2. Ensure the "Reserve lower memory" option is turned off.
3. Use a memory profiler to find what is occupying most of your memory. Start with largest ones.
4. Do not load all information into memory at the same time. Load necessary information only when required and unload immediately after use. For example, do not use auto-create forms, create forms on demand. Pay attention to scopes of your objects and things with automatic reference counting (strings, arrays, interfaces, etc.).
5. Try to offload large information blocks into files or database. For example, giant arrays should be converted to database.
6. You may try to execute memory hungry tasks in stanalone processes, designed only to run this specific task and nothing else.
7. Offload large resources from executable into standalone files or a database. Smaller executables will occupy less address space. 
8. If you are using background threads: consider doing things in sequence rather than at the same time.
9. Review your code for memory optimization. For example:
   1. Check compiler's optimizations; 
   2. Review your code for duplicates. Pay attention to generics to avoid blowing up your code. Smaller executables will occupy less address space;
   3. Check usage of virtual functions. Ensure your application will not be dragging unnecessary code that is never called;
   4. Use algorithms with lower memory usage;
   5. A missing const in arguments could cause unneccessary copying;
   6. Use smallest possible data types and pack everything in records (however, this will probably make your application slower);
   7. Check if you have too much function inlining in your code.
10. If you have out of memory error because of a 3rd party code - try to find what specific code actually allocates that much memory. 

Finally, you can switch to the 64-bit.

See also:

• My application runs (very) slowly with EurekaLog
• How to enable/disable EurekaLog at run-time?
• How to enable EurekaLog for production, disable for development?
• How to use different settings for development/production?

Once you're logged in to your control panel - you should see available to you EurekaLog versions. There will be a link to download the last stable and last test version of EurekaLog (if any present).

See also:

What is my log in and password for customer's area (control panel)?

• If you didn't receive your e-mail - check you spam folder (e-mail client or server). It's a good idea to add @eurekalog.com to your white-list for e-mail applications.
• If you buy EurekaLog via reseller - ask him for your account data.
• If you know your login (e-mail) - just use "Reset password" function.

If you're unable to resolve your problems - please ask our sales department to recover your password. Provide as much details about your purchase as possible.

Note: you can log in on https://www.eurekalog.com/login.php

EurekaLog (IDE add-on) and/or EurekaLog's tools use bad/unreadable font.

Reason:

EurekaLog use system's settings for fonts. It uses lfMessageFont (SystemParametersInfo with SPI_GETNONCLIENTMETRICS) for general font and GetStockObject(ANSI_FIXED_FONT) for mono-width font.

Solution:

A). Adjust your system font settings.

B). Specify override for fonts settings:

1. Open regedit.exe
2. Navigate to HKEY_CURRENT_USER\Software\EurekaLab\EurekaLog\7.0
3. Create subkeys "FontGUI" and "FontMono" (without quotes).
4. Create one or more string values with the following possible names: "Name", "Height", "Style", "Charset", "Orientation", "Pitch", "Quality". Specify your own values.

Example:

Note: both solutions are applicable for any tool, including EurekaLog Viewer.

There are big differences between EurekaLog v6 and v7.  If you try to import your old settings from a v6 project into v7 without reviewing all the pages of the v7 project setup dialog, then I can almost guarantee you will not be able to send logs or have EL work in any meaningful way.

You must (at minimum) select a Project Type and then set up the method you wish to send error logs back to your programmers. v6 had no concept of Project Type, so this parameter does not get set when you import old settings into v7.  If the project type is not set, you have basically disabled EurekaLog!

Tuning your v7 settings

I recommend you create a small app with a single button on the main form.  The button click event should raise some sort of exception.  Go ahead and load your v6 settings into the EurekaLog Project Options dialog using the Import button found at the bottom of the form. This will load your old v6 settings into your Test project.

Now, we need to finish the setup of EL v7...

In the v7 setup dialog, set the General|Project Type to VCL Forms application

Now check all the pages of the EurekaLog Project Options form an see if you have correct settings, localization, Etc that you desire for your project.  Compile and run the test app.  Click the button to raise an exception.

Your app should display the expected EurekaLog dialog boxes (if any).  If you opt to send the log to your email/web server, does it get there? Is the incoming log in the format you want?

If you are not getting the results you want, then stop your test program, tweak the EL settings, recompile and try again. 

Reusing your new v7 settings in other projects

Once you have your test program running, then you can export your preferred settings to an EOF file.  Import this file into any similar projects that need EurekaLog support.

I get error report about multiple leaks after using sending with Mantis send method. There is no leak report if I don't click on "Send report".

Reason:

It's a bug in Delphi's SOAP implementation.

Solution:

1. Use the latest RAD Studio version which fixes this bug.
2. Manually edit WSDLLookup.pas file and recompile it. Recompile EurekaLog to use new file (this will require EurekaLog Enterprise edition with full source code).

Update: 

Use latest EurekaLog version, we are not using Delphi's SOAP implementation anymore.

I get error message saying that installer/uninstaller has detected running EurekaLog instance and asks me to close it before continue with installation/uninstallation. However, I do not see any EurekaLog programs. 

Reason:

There may be hang EurekaLog application that is still running in the background.

Solution:

• Try to find and kill EurekaLog's processes manually.

or

• Restart your computer.

A). EurekaLog takes a lot of time to complete its tasks during compilation of your projects.

B). IDE becomes unresponsive during EurekaLog's work.

Reason:

EurekaLog IDE expert performs post-processing of your projects. The post-processing runs outside of the IDE (as standalone child process) - to minimize impact on the IDE, and gain more memory for large projects (IDE process may ).

This design may cause issues with performance in certain rare conditions (such as running under virtual machine, with lots of background services, etc.).

Solution:

You can adjust process priority class for EurekaLog post-process compiler (ECC32/EMake):

A). Go to HKCU\Software\EurekaLab\EurekaLog\7.0\IDE and creare a new string value "ECC32PriorityClass" (without quotes). Set it to a valid value of process priority class - such as $20 or 32 (for NORMAL_PRIORITY_CLASS), $4000 or 16384 (for BELOW_NORMAL_PRIORITY_CLASS), $8000 or 32768 (for ABOVE_NORMAL_PRIORITY_CLASS), $40 or 64 (for IDLE_PRIORITY_CLASS), $80 or 128 (for HIGH_PRIORITY_CLASS).

B). Use --el_priority command line option. You can pass this command-line option to ecc32/emake when you are invoking it manually. Or you can add this switch to "ECC32AdditionalOptions" option under Advanced / Custom page in EurekaLog's project options. 

I downloaded and started installer. However, it hangs on start. Nothing happens.

Reason:

It is a known problem with Malwarebytes Anti-Malware tool. Its driver (mbamchameleon.sys) injects into CreateProcess call and cause infinite loop during check for digital signature of some signed executables.

Solution:

• Avoid mbamchameleon.sys:
  • Uninstall Malwarebytes (important: simple stop/exit will not help; even if services are off, the driver will continue to run)
  • OR
  • Use safe mode.
• Contact Malwarebytes support for help.

This is not EurekaLog issue, it is not specific to any EurekaLog version. An empty signed Delphi executable will exibit the same behaviour. The problem seems to be related to certain digital certificates.

I need to install old version of EurekaLog for one IDE and new version of EurekaLog for other IDE. In other words, I want to have two different versions of EurekaLog to be installed at the same time, on the same machine.

Solution:

EurekaLog 7.0-7.1 allows you to install EurekaLog 7 over EurekaLog 6 installation and switch between EurekaLog 6 and EurekaLog 7 by using "Manage" tool provided by EurekaLog 7.

Starting with EurekaLog 7.2, it is no longer possible to install EurekaLog 7 over EurekaLog 6. File layout was changed drammatically, and it is no longer compatitible with EurekaLog 6 file layout. Old version of "Manage" tool (v7.1.5, which is capable of working with EurekaLog 6) can be downloaded here: https://www.eurekalog.com/files/ManageProfilesV6.exe. See instructions below.

Starting with EurekaLog 7.5, additional tools is included into EurekaLog installer, so it is possible to automatically install EurekaLog 7 over EurekaLog 6. "Manage" tool for EurekaLog 6 will be installed automatically by EurekaLog 7.5+ installer.

Instructions for manual installation EurekaLog 7.2, 7.3, or 7.4 with EurekaLog 6

(not applicable to EurekaLog 7.0, 7.1, 7.5+)

You have to manually install both EurekaLog versions:

1. Uninstall any installed EurekaLog versions;
   • Perform a clean uninstallation (older versions) to be sure there are no leftovers from old installation;
2. Install older (previous) version of EurekaLog (v4, v5, or v6):
   • IMPORTANT: Install older version of EurekaLog FIRST;
   • Make sure that you checked only IDE which you want to work with this older EurekaLog version, and unchecked other IDEs. For example, you can install EurekaLog 6 for Delphi 7 only;
   • Complete installation as usual, make sure that older/previous version of EurekaLog works as expected in the installed IDE, make sure there are no EurekaLog visible in other IDEs;
   • IMPORTANT: Copy ecc32.exe/emake.exe files from \bin folder of the selected IDEs into corresponding sub-folder(s) of your EurekaLog installation. For example, C:\Program Files (x86)\Borland\Delphi7\Bin\ecc32.exe -> C:\Program Files (x86)\EurekaLab\EurekaLog 6\Delphi7\ecc32.exe;
3. Remove installation information about older/previous EurekaLog version:
   • Go to "Start" / "Run..." and type "regedit" to open registry editor;
   • Navigate to HKEY_CURRENT_USER\Software\EurekaLog;
   • Rename the "EurekaLog" key to something else. For example, "OldEurekaLog";
4. Install new (latest) version of EurekaLog (v7.2, v7.3, or v7.4):
   • IMPORTANT: Make sure that you are installing new version of EurekaLog into different folder; Do not install it in the same folder which was used at step 2;
   • IMPORTANT: You may install new/latest version of EurekaLog for the same IDEs as used in step 2. However, use caution when switching between EurekaLog versions in the same IDE - read remaks below for more info. It is recommended to install different EurekaLog versions into different IDEs;
   • Complete installation as usual, make sure that new version of EurekaLog works as expected in the selected IDEs;
5. Restore older/previous EurekaLog version:
   • Open registry editor;
   • Navigate to HKEY_CURRENT_USER\Software\OldEurekaLog;
   • Rename "OldEurekaLog" key to its original name ("EurekaLog");
   • Restore old EurekaLog IDE registration:
     
     • If selected IDE has EurekaLog 7 installed - remove EurekaLog 7 from the specified IDE (by using latest "Manage" tool);
     • Automatic (EurekaLog 6 only) - use old version of "Manage" tool to register EurekaLog 6 into IDE. IMPORTANT: Do not use old version of "Manage" tool to edit settings for IDEs with installed EurekaLog 7, do not use latest version of "Manage" tool to edit settings for IDEs with EurekaLog 6 - see remarks below;
     • Manual (EurekaLog 4, 5, and 6):
       • Copy previosly saved ecc32.exe/emake.exe file(s) into its proper location (\bin folder of IDE);
       • Use "Component" / "Install packages" IDE's menu command to register (C)ExceptionExpert.bpl file (for example: C:\Program Files (x86)\EurekaLab\EurekaLog 6\Delphi7\ExceptionExpert7.bpl);
       • Add directory containing the (C)ExceptionExpert.bpl file into Library Search Path setting of your IDE ("Tools" / "Environment Options" / "Library Path").
6. Done!

If you want to update/reinstall newer version of EurekaLog (v7.2, v7.3, v7.4) - perform such steps:

1. Remove installation information about older/previous EurekaLog version:
   • Go to "Start" / "Run..." and type "regedit" to open registry editor;
   • Navigate to HKEY_CURRENT_USER\Software\EurekaLog;
   • Rename the "EurekaLog" key to something else. For example, "OldEurekaLog";
2. Install new (latest) version of EurekaLog (v7.2, v7.3, v7.4):
   • Uninstall current v7 version;
   • IMPORTANT: Make sure that you are installing new version of EurekaLog into different folder; Do not install it in the same folder which was used at step 2;
   • Complete installation as usual, make sure that new version of EurekaLog works as expected in the selected IDEs;
3. Restore older/previous EurekaLog version:
   • Open registry editor;
   • Navigate to HKEY_CURRENT_USER\Software\OldEurekaLog;
   • Rename "OldEurekaLog" key to its original name ("EurekaLog");
   • Re-register EurekaLog 6 into desired IDEs as discussed above;
4. Done!

Important notes:

• Do not use latest "Manage" utility from EurekaLog 7.2-7.4 to change settings for IDEs with old EurekaLog versions (v6). You can use latest "Manage" utility to alter settings of IDEs with EurekaLog 7 only;
• Do not use old "Manage" utility from EurekaLog 7.1- to change settings for IDEs with EurekaLog 7.2+, use it only for IDEs with EurekaLog 6;
• Do not uninstall old/previous EurekaLog version (v4-v6), unless you have restored uninstallation information under "Uninstall" registry key;
• You may try to install EurekaLog 6 and EurekaLog 7 for the same IDE. However, use caution when switching between versions:
  • Use new "Manage" tool (7.2-7.4) to remove/install EurekaLog 7 from IDE;
  • Use old "Manage" tool (7.1-) to remove/install EurekaLog 6 from IDE;
  • Do not install EurekaLog 6 into IDE with installed EurekaLog 7: remove EurekaLog 7 (with new "Manage" tool) first, then install EurekaLog 6 (with old "Manage" tool);
  • Do not install EurekaLog 7 into IDE with installed EurekaLog 6: remove EurekaLog 6 (with old "Manage" tool) first, then install EurekaLog 7 (with new "Manage" tool).

I develop IDE package (component or expert). When I compile my package, no EurekaLog information is added, even though package is configured with EurekaLog. Instead, a message "Package is installed in IDE. It's not possible to modify .bpl file" is shown in IDE's messages window under "EurekaLog" node.

Explanation:

This is a limitation of IDE's OpenTools API.

You have your package installed (registered) in IDE. Thus, your package is loaded by IDE process. This means that no one can alter it. When you compile your package in IDE, IDE unloads your package, recompiles it, then loads it back.

EurekaLog IDE expert assigns "AfterCompile" event via IDE's OpenTools API. Unfortunately, this event is triggered after compiled package is loaded back in IDE. Thus, EurekaLog code can only see your package when it was already reloaded back to IDE. Therefore, EurekaLog IDE expert is unable to modify your package.

Solution:

1. Manually unload (unregister) your package in IDE, recompile it (since package is not loaded - this time EurekaLog will be able to alter it), then install/register it back.
2. Manually invoke EurekaLog's post-processing before package is loaded. Specifically, project's post-build event (not to be confused with EurekaLog's post-build event) is executed when compiled package is unloaded. In other words, you have to place a call to ecc32 to your project's post-build event as described in this article.

Checked EL version: 7.3.1

Ticket ID: 10965 (GIR-315-42360)

I get "out of memory" exception from ecc32 when compiling my large project with EurekaLog.

Explanation:

EurekaLog's ecc32 uses arrgessive memory allocation to speed up post-processing. Doing so it can post-process smaller projects in a matter of few seconds (sometimes even less than one second). However, if you try to compile larger project in this mode - ecc32 would run out of memory, as it is 32-bit process limited to 2 Gb of address space.

Solution:

You can instruct ecc32 to conserve memory usage. The post-processing will be slower, but it will use far less memory. To do that:

1. Open "Project" / "EurekaLog options" dialog;
2. Go to "Advanced" / "Custom / Manual" tab;
3. Add the following option to any location:

ECC32TradeSpeedForMemory=1

Note: be sure to check if such option already exists (the options' list is sorted alphabetically). The option is not presend by default, but someone may already added it. If this option exists - replace '0' with '1'.

I set up sending to a web-tracker. I'm pretty sure that entered settings are correct (e.g. "Test" button in EurekaLog project settings dialog may work, or sending from real application may work). However, sending (either from "Test" button or from real application) may fail sometimes (or most of the times). The failure is either entire bug report is not sent, or bug report is sent, but bug report file is not attached.

Reason:

Your web-server or web-tracker may have size limitation for requests, replies, or file uploads. Sending will fail if current report is greater than this size limit. Sending will succeed if current report is less than this size limit. If API requires two steps (to create bug report and attach file) - then bug report itself may be created successfully (as small text), but file attaching will fail (as file is large).

Solution:

1. Diagnose that problem is indeed some sort of a size limit:
   1. Use run-time debug mode to add a logging to your application;
   2. Use Fiddler or WireShark to monitor network traffic between your application and web-tracker;
   3. There should be some sort of error messages/code indicating failure due to size limitation.
2. Increase size limit or remove it.

See also:

• file uploads, upload_max_filesize, max_file_uploads, post_max_size, memory_limit settings in PHP
• JIRA Character Limits on Comments and Description
• Mantis file upload limits
• FogBugz attachment limits
• maxattachmentsize setting in BugZilla
• (Mantis) All file attaches has size of 0 bytes

I receive leak reports from EurekaLog in a blank empty VCL application.

Reason:

1. You did not set up your project properly, so EurekaLog's leak checking code is running too early.
2. You may see technical leaks. See below for an example.

Example (technical leak):

1. When application exits: RTL enters shutdown cycle inside _cleanup() routine from initexit.c file. This routine will call any registered finalization subroutine (e.g. exit procedure), such as EurekaLog and I/O streams finalization.
2. C++ RTL will flush opened streams during shutdown (fflush() routine from fflush.c file is called from _exit_streams() finalization routine from streams.c file).
3. Unfortunately, flushing stream will keep an allocated memory block used for stream locking (lock is allocated from _lock_stream() from streams.c).
4. This memory block will remain alive, even when other code (including EurekaLog) cleanup (inside cleanup cycle in the _cleanup() routine).
5. EurekaLog will detect memory block that was allocated, but not freed. EurekaLog will report this block as leak.
6. Once EurekaLog (and other code) finishes shutdown - RTL will continue to cleanup.
7. RTL will delete allocated locks by calling _cleanup_handle_locks() and _cleanup_stream_locks() (after _cleanup() routine completes) and terminate the process.

Solution: 

1. Follow our guidelines for setting up your project for leak reporting. Basically, you need to ensure that EurekaLog's code is initialized first and finalized last. Otherwise, EurekaLog's leak checking code will run when there are unallocated resources. Such resources will be reported as leaks, even though it is finalized later.
2. Ignore technical leaks. You may try to add such leaks as expected leaks. Or you may try to cleanup such leaks manually before execution of EurekaLog's leaks checking. E.g. calling routines such as _cleanup_stream_locks() at shutdown. But this may not always be possible.

See also:

• I get "Abnormal program termination" or other type of crash at shutdown

Yes, EurekaLog supports CLang and LLVM in both 32 and 64 bits - with some limitations.

Long Answer

History

The 64-bit Delphi is build on classic Borland toolchain. EurekaLog 7 supported 64-bit Delphi since the very begining: the original release of EurekaLog 7.0.0.0 in 2012. Since many of our clients were using the new 64-bit platform, we were also able to improve its support over time. It was feature-complete in somewhere near 2014. Currently it does not have any limitations. 

On the other hand, the 64-bit C++ Builder is build on entirely different toolchain: LLVM. Classic toolchain is not used for 64-bit C++ Builder. The CLang is LLVM's frontend for C++. Initially EurekaLog 7 did not have support for LLVM. 

While 32-bit C++ Builder was also originally build on classic Borland toolchain, Embarcadero has released RAD Studio 10 Seattle in 2015 with an option to use LLVM-based toolchain for 32-bit C++ Builder. In other words, starting with RAD Studio 10 Seattle (2015+):

• 32-bit Delphi: classic only
• 64-bit Delphi: classic only
• 32-bit C++ Builder: classic OR LLVM - your choice
• 64-bit C++ Builder: LLVM only

Since now CLang was accessible in 32-bit, we also started implementing support for LLVM and CLang. However, not many of our clients use C++Builder. And very few clients immediately switched to CLang/LLVM. Therefore, we also couldn't polish our CLang/LLVM support as quickly as Delphi's 64-bit support. However, a lot of time has passed and we can say with confidence that many of our clients use EurekaLog for CLang/LLVM today.

Support for 64-bit C++ Builder is a relatively recent addition. It was enabled in 2020. EurekaLog doesn't track usage statistics, so we don't know exactly how many of our clients are using 64-bit C++ Builder. But we can judge this indirectly: by the number of questions to our technical support. And judging by it: almost none of our clients use 64-bit C++ Builder. This means we don't get a lot of feedback and improvements to 64-bit C++ Builder support are VERY slow.

In summary: while EurekaLog does support CLang, LLVM and 64-bit, you must understand that some aspects had more time to polish and evolve. For these historical reasons, the levels of maturnity (in order from high to low) are:

1. 32-bit Delphi
2. 32-bit C++ Builder on classic toolchain
3. 64-bit Delphi
4. 32-bit C++ Builder on LLVM toolchain (CLang)
5. 64-bit C++ Builder

Technical details and limitations

Unfortunately, using LLVM (CLang) for 32 or 64-bits means that some exception info is missing. LLVM (or its implementation in C++ Builder) is very unpolished for exception tracing. Specifically, it does not set an exception address, it does not set a valid stack pointer and a frame - all those necessary and important values are just zeros. We really got into the wilds of workarounds and hacks, only to extract the address of the exception. Everything really hangs on straws and assumptions.

Classic C++ Builder is much better in this aspect. We are improving diagnostic as much as possible, so newer versions of EurekaLog should provide better info. But there may be something that is impossible to implement from our side. We highly recommend that you don't use LLVM on 32-bit, use classic compiler. Naturally, you are limited to LLVM only for 64-bit C++ Builder as there is no option to use classic compiler. 

One other point to consider is debug information. Delphi, C++ Builder and RAD Studio has an option to generate a text .map file, which contains debug information about the compiled module - such as unit, class, function names and line numbers. Such .map file is used by EurekaLog to compose debug information in EurekaLog's own format - designed for maximum access speed or minimum space. The issue is that .map files produced by the C++ Builder do not have line numbers - just names of units, classes, and functions:

1. EurekaLog is also able to read debug information in Turbo Debugger (TD32, TDS) format. If it is enabled for C++ Builder - EurekaLog will use it to extract line numbers. So, when using 32-bit C++ Builder on the classic toolchain - EurekaLog will be able to show line numbers in bug reports.
2. If you would use LLVM/CLang on Win32 (e.g. "Use Classic compiler" option is disabled) or 64-bit C++ Builder (which is LLVM/CLang-only) - then no TD32/TDS debug information will be available, as LLVM/clang generates DWARF debug information, not TD32/TDS. Currently EurekaLog is unable to read DWARF debug information, so there will be no line numbers in bug reports.

You can help us to fix this issue by voting for this entry: [RSP-27359] No line numbers in map files for LLVM-based compilers.

I get the following messages when trying to compile or install my own package, 3rd party package, or 3rd party framework:

• "The following changes are necessary to make this package compatible with other installed packages. Choose OK to apply these changes and rebuild the package: Add EurekaLogCore. EurekaLogCore contains implicit unit(s) Web.Win.IsapiHTTP".
• "Cannot load package 'my-package.' It contains unit 'Web.Win.IsapiHTTP', which is also contained in package 'EurekaLogCore'."

Reason:

1. Same unit may not appear in two or more loaded packages;
2. Web.Win.IsapiHTTP unit is not included in any default RTL/VCL package, which means this unit became part of any package that references this unit.

E.g. Web.Win.IsapiHTTP becomes part of EurekaLogCore package, your own package / 3rd party package / 3rd party framework.

Solution:

You need to move Web.Win.IsapiHTTP unit into a new package, which will be shared by all other packages that need Web.Win.IsapiHTTP unit:

Step 1: prepare shared package:

1. Create new run-time package;
2. Add Web.Win.IsapiHTTP unit to this package ("contains" section);
3. Add rtl, vcl, inet packages to "requires" section;
4. Build modified package.

Step 2: redirect other packages to use new shared package:

1. Open EurekaLogCore package (available in EurekaLog Enterprise);
2. Add package name from previous step to "requires" section;
3. Rebuild the package;
4. Use "Manage EurekaLog in IDEs" tool to reinstall EurekaLog.

Step 3+: repeat "Step 2" actions for your own packages, 3rd party packages, 3rd party frameworks.

I get "The operating system is not presently configured to run this application." error message when working with EurekaLog.

Reason:

The error message comes from ERROR_IOPL_NOT_ENABLED (197/$C5) error code.

It is usually caused by damaged installation of MS Office (which itself may be caused by operating system upgrade). The issue is that EurekaLog may use Simple MAPI or MAPI, which will load MAPI DLL. MAPI DLL comes from Outlook when MS Office is installed. Therefore, configuration problem of MS Office/Outlook will affect EurekaLog when it try to use (Simple) MAPI.

Solution:

1. Repair your MS Office installation. Search internet for possible solutions.
2. Alternatively, add explicit MAPI DLL override for EurekaLog only: 
   1. Open HKEY_CURRENT_USER\Software\EurekaLab\EurekaLog\7.0 registry key (you can also add a global override by going to HKEY_LOCAL_MACHINE\Software\[WOW6432Node\]EurekaLab\EurekaLog\7.0 registry key);
   2. Create DLLPath and DLLPathEx string values;
   3. Specify full file path to alternative MAPI DLL as these values. For example: %ProgramFiles%\Internet Explorer\hmmapi.dll, %ProgramFiles%\Windows Live\Mail\smapi.dll, or C:\Windows\System32\mapi32.dll. File must exist.
3. Alternatively, add explicit MAPI DLL override per application:
   1. Open HKEY_LOCAL_MACHINE\SOFTWARE\[WOW6432Node\]Microsoft\Windows Messaging Subsystem\MSMapiApps registry key;
   2. Add a new application=mail client pair, where the application is .exe file name of the crashed application, and the mail client is name of registry subkey under HKEY_LOCAL_MACHINE\SOFTWARE\[WOW6432Node\]Clients\Mail. For example: Viewer.exe=Hotmail.

See also:

• Explicitly Mapping MAPI Calls to MAPI DLLs
• Mapi32.dll Stub Registry Settings

1. Open your browser and go to: https://www.eurekalog.com/resetpassword.php
2. Enter your email address into the "E-Mail" field. You must use the same email address that you used to register EurekaLog;
3. Click the "Reset Password" button;
4. The web-site will send you a e-mail with URL. Check your spam folder if you don't see this e-mail;
5. Follow URL from e-mail;
6. Web-site will ask you for a new password;
7. Enter any text as your new password;
8. Log in to our web-site using your new password.

Almost any attempt to use Mantis fails when executing the mc_issue_add SOAP command with "EXMLRPCError: SOAP-ENV:Server: Cannot use object of type stdClass as array" error.

Reason:

This is a known bug in Mantis.

Solution:

A). Update Mantis to the latest version.

B). Fix mc_project_api.php file manually as described here.

See also:

• (Mantis) "EXMLRPCError: SOAP-ENV:Server: Object of class SoapFault could not be converted to int" error
• (Mantis) "#1366: Incorrect string value" error
• (Mantis) "Error Type: SYSTEM NOTICE, Error Description: Array to string conversion" error
• (Mantis) All file attaches has size of 0 bytes
• Almost all sending to web-tracker (JIRA, Mantis, etc.) fails with generic error message or bug report files are not attached

Almost any attempt to use Mantis fails when executing the mc_issue_add SOAP command with "EXMLRPCError: SOAP-ENV:Server: Object of class SoapFault could not be converted to int" error.

Reason:

This is a known bug in Mantis.

Solution:

A). Update Mantis to the latest version.

B). Check server logs to learn real error from SoapFault object (for example, category name may be empty, but Mantis does not allow empty category). 

See also:

• (Mantis) "EXMLRPCError: SOAP-ENV:Server: Cannot use object of type stdClass as array"
• (Mantis) "#1366: Incorrect string value" error
• (Mantis) "Error Type: SYSTEM NOTICE, Error Description: Array to string conversion" error
• (Mantis) All file attaches has size of 0 bytes
• Almost all sending to web-tracker (JIRA, Mantis, etc.) fails with generic error message or bug report files are not attached

When I am sending bug report to Mantis - I get the following message:

---------------------------
FAILED: Error code = 50
---------------------------
Current application version is obsolete, bug submission is closed.

Thank you for your feedback!

Please, obtain a new version of this application.
---------------------------
ОК
---------------------------

However, I am already using lastest version of EurekaLog.

Reason:

This message is not about EurekaLog, it is about your application. It means that while EurekaLog was able to connect to Mantis, but it was unable to post new bug report.

This message is supposed to be used when you are not interested in bug reports from obsolete releases of your application. For example, you have released v2 of your application, you don't want reports from v1 anymore. So you remove v1 from Mantis (mark as "obsolete"). Then v2 versions of your app can continue to post bug reports, while v1 versions of your app will report "This app is obsolete, please get a new version".

Solution:

However, if you get this message in a new app - then you did not set up your Mantis settings properly. Most likely your EurekaLog settings indicate that EurekaLog should match version of your Delphi project to project version in Mantis, but your actual Mantis versions do not match your Delphi project's versions.

There could be other reasons for this message. We have a detailed guide for bug tracker setup. You can also study help for EurekaLog's settings. Be sure to understand what each option is doing.

If you still can't figure out what is wrong with settings - create a run-time log.

IDE may stop executing my application when I run it under debugger. IDE opens a new tab in code editor with EurekaLog's unit. However, there is nothing useful inside, just a lot of repeating "// You do not have source code" lines.

Reason:

1. You are using Trial or Professional editor of EurekaLog (e.g. without source code). These editions of EurekaLog come with headers only (e.g. interface sections). That is why all implementation sections are empty (filled with "// You do not have source code" comments);
2. The reason why you have stopped inside EurekaLog's unit may vary:
   • EurekaLog may want to draw your attention to the problem which happened in your application;
   • There may be an exception inside EurekaLog's code.

Solution:

Check call stack of your application (View / Debug Windows / Call Stack):

1. If you are inside ELowLevel.DebugBreak function - it means that EurekaLog is trying to get your attention, because some important issue was found in your application. Typically, it would be some memory problem (see also: "Use safe mode to handle special exceptions" option). You are supposed to inspect the problem before EurekaLog will process it. You can also continue execution to let EurekaLog process exception as usual. This happens ONLY when you are running under debugger;
2. If you are in any other location - it usually means that there was an exception in EurekaLog's code. This could be an expected exception, as well as a bug in EurekaLog. Simply continue execution and see if application will behave as expected.

If you are still uncertain about this case - you can always create a run-time log. This log will show everything that is happening in your app. You can send us the resulting .csl file (packed in any type of archive), so we can investigate it and provide an explanation.

See also:

• "Use safe mode to handle special exceptions" option

I am getting the "No frames are available to insert" error when I am trying to insert a frame on the form after I have enabled EurekaLog for my project with frames.

Reason: 

Unfortunately, this is a bug in IDE.

EurekaLog uses the official OpenTools API (OTA) to integrate with IDE. When you are enabling EurekaLog for your project - EurekaLog edits .dpr file to insert units and this confuses IDE.

Specifically, IDE offers IOTASourceEditor interface, which has CreateWriter method to obtain a IOTAEditWriter interface. EurekaLog uses methods of IOTAEditWriter interface to edit content of .dpr file (basically, this is just a series of .DeleteTo and .Insert). Apparently this is somehow forces IDE to corrupt .dproj file.

Solution:

Once you have enable EurekaLog for your project - close your IDE and open .dproj file in any text editor. Search for name of your frame. You should find something like this:

    <ItemGroup>
        <DelphiCompile Include="$(MainSource)">
            <MainSource>MainSource</MainSource>
        </DelphiCompile>
		...
        <DCCReference Include="UnitFrame.pas">
            <Form>Frame1</Form>
            <DesignClass>TFrame</DesignClass>
        </DCCReference>
		...
    </ItemGroup>

Add the FormType tag like this:

    <ItemGroup>
        <DelphiCompile Include="$(MainSource)">
            <MainSource>MainSource</MainSource>
        </DelphiCompile>
		...
        <DCCReference Include="UnitFrame.pas">
            <Form>Frame1</Form>
            <FormType>dfm</FormType>
            <DesignClass>TFrame</DesignClass>
        </DCCReference>
		...
    </ItemGroup>

Please note that the order of tags are important.

Repeat these steps for each frame in your project.

Save changes and reopen your project in IDE. It should work as expected now.

We are using CData's connectors with FireDAC to issue a SQL statement. When executing the SQL statement when EurekaLog is enabled, we get a generic exception error: E0434352 on the Query.Open. EurekaLog reports this exception as:

CLR (.NET) Exception
HRESULT: 8007002 (The system cannot find the file specified)
Module clr.dll
Code: E0434352
Address: 72D128F1 (001028F1)

Reason:

This issue is not related to EurekaLog:

1. One of our customer has confirmed that this issue happens even in a project without EurekaLog: 

   > When not running with EurekaLog, I still get the error like this: EExternalException with message 'External exception E0434352'. I found that if I don't close the database connection when I destroy the FDQuery to the AWS database this error occurs very frequently (connection timeout?). So I added a statement in the Destroy event of the Query to set the FDConnection.Connected := False; This seems to solve the problem;

2. CData's support has confirmed the same thing: "we tried to manually load the 'VCRUNTIME140_CLR0400.dll' and 'vcruntime140.dll' libraries in absence of EurekaLog and managed to reproduce the issue".

Communicating with CData's support suggests that the issue seems to be caused by loading VCRUNTIME140_CLR0400.dll and/or msvcr100.dll. Since EurekaLog is Delphi native code, it does not reference .NET/CLR run-time (VCRUNTIME140_CLR0400.dll) and it does not reference C++ run-time (msvcr100.dll). In other words, EurekaLog does NOT load VCRUNTIME140_CLR0400.dll/msvcr100.dll. You can verify this with empty Delphi project by enabling EurekaLog for it.

The mentioned DLLs can be used/loaded by other components in your application. For example, EurekaLog may load MAPI DLL to send e-mails, and that MAPI DLL may reference the mentioned DLLs.

Solution:

It looks like CData may be using "current directory"/relative paths to find/load DLLs. Loading one of the above mentioned DLLs either changes current folder or overrides DLL search paths, so that is why CData is no longer able to find/load the DLL.

Until the issue is fixed on CData's side (assuming it is a bug): you can workaround it by finding the DLL in question (by using the Process Monitor tool from SysInternals) and placing it into any of DLL search paths. For example, into your app's folder.

Our customer confirms that he is able to fix the issue by placing the required DLL into DLL search paths:

> I found an error about CData.Firem.SalesForce.dll using Process Monitor: PATH NOT FOUND. So I added this dll in the application's folder, and my application works fine now. If I remove the DLL - then I get the error again.

Summary:

1. As this issue is not related to EurekaLog - we would suggest to seek help from CData's support;
2. We would also suggest trying Process Monitor tool (from SysInternals) to check which file your application is unable to open;
3. You can also try sxstrace tool or "Break on module load" IDE's breakpoint to determinate who is loading the offending library.

After installing EurekaLog: if I double-click on the IDE project file (for example, .dproj) - a pop up dialog will be open, asking me to select application to open the file. I think it is a bug, EurekaLog should not change file associations.

Reason:

Our installer registers the new "Edit EurekaLog settings" action ("EditEL" verb) for all IDE project types (such as .dproj, .cbproj, etc.):

Please note that our installer does not change the file association. Your project files are still associated with IDE.

However, Windows 10 has the feature of showing you a dialog box where you can choose an application to open the file with - when you try to open a particular file, if you have multiple applications that can do so. This is actually helpful in a lot of scenarios, as it tells you to try the apps that you actually installed. 

Please note that the RAD Studio IDE (bdslauncher) is still a default choice in this dialog.

Solution:

1. Simply check the "Always use this app" checkbox and click on the OK button (the "Keep using this app" option should be highlighted by default).

2. If you do not like this feature of Windows 10 - you can disable it by enabling the "Do not show the 'new application installed' notification" group policy:

This policy removes the end-user notification for new application associations. These associations are based on file types (e.g. *.txt) or protocols (e.g. http:)

If this group policy is enabled, no notifications will be shown. If the group policy is not configured or disabled, notifications will be shown to the end user if a new application has been installed that can handle the file type or protocol association that was invoked.

My application runs fine without EurekaLog, but fails after adding EurekaLog. It fails with the error like "REST request failed: Error  sending data: (12175) A security error occurred", which is the ERROR_WINHTTP_SECURE_FAILURE error. I am using TREST.Request or/and THTTPRio. The same compiled executable may run fine on one machine, but fail on another.

Explanation:

This issue is not caused by EurekaLog directly. See this thread on DelphiPraxis. EurekaLog loads DbgHelp.dll from Microsoft Windows SDK, DbgHelp.dll uses SymSrv.dll, and loading a specific version of SymSrv.dll is what seems to cause/reveal the issue. We are using the DbgHelp.dll and the SymSrv.dll from the latest Windows SDK.

Solution:

This is not EurekaLog issue, as the issue appears even in applications without any EurekaLog's code. It seems to be related to WinHTTP settings. We recommend to seek solutions on forums.

As a temporal workaround, you can delete/move/rename DbgHelp.dll from the \Bin folder of your EurekaLog installation. This DLL is not deployed with your application.

P.S. In our particular case:

1. The WinHttpSendRequest function spawns background worker threads that calls into Crypt32.dll. 
2. The internal functions of Crypt32.dll raise Access Violation exception for an unknown reason.
3. The AV exception is returned as 12175/ERROR_WINHTTP_SECURE_FAILURE from the WinHttpSendRequest function.

In our case the "reason" for Access Violation was the loaded DbgHelp.dll from Windows SDK (not the one from the \Windows folder).

I can not debug my application in IDE after I have added EurekaLog. IDE's debugger is either fails to start / load or it runs executable with disabled breakpoints and no source code debugging.

P.S. Possible error message from IDE: "Debugger fatal error: debug kernel not responding. The debug process will be terminated."

P.P.S. It may happen in C++ Builder only.

Reason:

EurekaLog needs to change your executable by adding (injecting) debug information. Debug information is stored as an additional PE section. Our code takes extra care to keep changed (after injection) executable as similar to the original as possible: including restoring file timestamps, recalculating PE header CRC, etc.

However, sometimes it is not enough for IDE's debugger. It may fail to recognize your executable after modifications. Unfortunately, we are unlikely to fix such issue from our end, as IDE's debugger is essentially a black box for us with little to no control. What we can do is a bit of woodo magic, trying to understand things that it does not like.

We have reports from our customers that sometimes C++ Builder refuses to debug executable. Either failing to load / run, or running executable without debug information (e.g. breakpoints are disabled; no source code debugging, etc.). On the other side, we did not have a single report about such cases for Delphi.

Solution:

1. Report the issue to the Embarcadero's bug tracker;
2. Upgrade to the latest IDE;
3. Apply/install all latest IDE's service packs / updates / patches;
4. Switch "Debug Information" option from "Inject" to "Add";
5. If the above does not help - go to "Project" / "EurekaLog options" / "Advanced" / "Custom/Manual" and look for the DoNotTouchEXE option. If not found - add it like so:
   DoNotTouchEXE=1

Important Notes:

Switching the "Debug Information" option from "Inject" to "Add" (or using the DoNotTouchEXE=1) is supposed to be a temporal workaround for debugging. Please note that your executable will not be self-sustained with either of these options:

• you need to deploy .edbg file with your executable;

or

• recompile with "Inject" (DoNotTouchEXE=0) option for production.

Please note that if you use the DoNotTouchEXE=1 option - then EurekaLog will not touch (open) your executable at all. So if you still have your issue while using that option - then EurekaLog has absolutely nothing to do with the issue.

See also:

• Debugging / breakpoints are not working (non-EurekaLog related)
• RSP-29696 C++64: Debugger fatal error: debug kernel not responding. The debug process willl be terminated
• EurekaLog does not work when compiling "Release" profile in C++ Builder

EurekaLog causes internal error URW8074 when compiling my fairly-large project. I have uninstalled it and re-installed older version of EurekaLog, and now I don't have that problem anymore.

Reason:

Unfortunately, internal errors are bugs in the IDE's compiler. That is something that we can not fix.

Occasionally when compiling an application in Delphi, the compile will halt and display an error message that reads, for example: Internal Error - X1234. This error message indicates that the compiler has encountered a condition, other than a syntax error, that it cannot successfully process. The information after "Internal Error" contains one or more characters, immediately followed by a number that indicates the file and line number in the compiler itself where the error occurred. Although this information may not help you, it can help Embarcadero track down the problem if and when you report the error to the Embarcadero. Be sure to jot down this information and include it with your internal error description.

A possible reason for such error is when IDE has few minor updates (for example, RAD Studio 11, RAD Studio 11.1, RAD Studio 11.2, RAD Studio 11.3), and one minor update (like RAD Studio 11.2) has a bug that makes it incompatible with other IDE updates. The mentioned issue could appear when you are building a project in IDE containing the bug (like RAD Studio 11.2) while linking it with precompiled files compiled in IDE update without the bug (like RAD Studio 11.3).

Solution:

1. Install the latest updates for your IDE. For example, Update 3 for RAD Studio 11 Alexandia lists one particular case of the URW8074 internal error. 
2. If upgrading to the latest IDE patch is not possible - one possible way that may work is to recompile EurekaLog for your IDE version.
3. One common reason why your project fails when adding EurekaLog is because you are running out of memory. In other words, you have a large project, you add more code to it (not necessarily EurekaLog, just any code that is large enough). If this is the case, try setting "Project" - "Options" - "Delphi Compiler" - "Use MSBuild externally to compile" to true. This will cause the compiler to run out of process (as a standalone process), which means a bit more free memory to actually do the work.
4. If that did not help - please, report this issue to Embarcadero support.
5. While the issue is being investigated by Embarcadero - please, follow these steps.

Reported in:

EurekaLog version: 7.11.1.3

IDE version: 11.2

See also:

• Compiling project with EurekaLog fails with the F2084 Internal Error: DBG2304
• My IDE crashes with EurekaLog 7
• "File XYZ was compiled with different version of ABC" error
• "Could not compile used unit XYZ" error
• "File not found: XYZ" error
• "The procedure entry point XYZ could not be located in the dynamic link library ZXY" when starting IDE with EurekaLog installed

I get the following error message when trying to compile my C++ Builder project with TwineCompile:

Target TCPostLink:
ecc32.exe --el_alter_exe=C:\Projects\Project1.cbproj
'ecc32.exe' is not recognized as an internal or external command, operable program or batch file.
C:\Program Files (x86)\JomiTech\TwineCompile\TCTargets120.Targets(888,5): error MSB3073: 
The command "ecc32.exe --el_alter_exe=C:\Projects\Project1.cbproj" exited with code 9009.

It happens even in a project without EurekaLog. Why is there this post link event if EurekaLog is not included? There are no post build events specified for this project and no mentions in the project file.

Reason:

EurekaLog does not modify your project's build events. The C:\Program Files (x86)\JomiTech\TwineCompile\TCTargetsXYZ.Targets file (which is a part of TwineCompile) contains the following:

<Target Name="TCPostLink">
  <Exec
    Condition="'$(EurekaLog)'!='' And '$(TLibLink)'!='true' And ('@(OutputOutOfDate)'!='' Or '$(ForceLink)'=='true')"
    Command="ecc32.exe --el_alter_exe=$(MSBuildProjectFullPath)"
    />
</Target>

This command is supposed to post-process the compiled executable to include EurekaLog's data.

However, this command will not work with modern versions of EurekaLog and modern IDEs:

1. This command is trying to call the ecc32.exe file from the \bin folder of your IDE. However, the ecc32.exe is no longer copied into the \bin folder of your IDE, because modern IDE will throw the license validation error if 3rd party files are copied into IDE's \bin folder:

   Question: I’ve installed and registered C++ Builder or Delphi, yet when it starts I am brought to a web page with the error “Product or License Validation Error”. How can I fix this?
   Answer: By far the most common cause for this error is having files or applications not provided by Embarcadero that are copied into the bin folder below where RAD Studio is installed. Only files provided by Embarcadero may reside in the bin folder.

   That is why modern EurekaLog versions will have the ecc32.exe file located in the corresponding C:\Program Files (x86)\Neos Eureka S.r.l\EurekaLog 7\Packages\IDEName\ folder. The command line from the TCTargetsXYZ.Targets file will fail to locate the ecc32.exe inside the mentioned folder.
2. The command line does not mention which build configuration was used to compile the project (for example, "Debug" or "Release"). It means that even if the ecc32.exe could be called - it will not know where your compiled file is located, failing with the error message similar to this:
   

   Target TCPostLink:
   ecc32.exe --el_alter_exe=C:\Projects\Project1.cbproj
   EurekaLog Command-Line Compiler (debug) v7.12.0.0 for RAD Studio 28.0
   ----------------------------------------------------------------
   Loading EurekaLog options...
   Compiled file "C:\Projects\Win32\Release\Project1.exe" not found
   C:\Program Files (x86)\JomiTech\TwineCompile\TCTargets120.Targets(888,5): error MSB3073: 
   The command "ecc32.exe --el_alter_exe=C:\Projects\Project1.cbproj" exited with code 2.
   Done building target "TCPostLink" in project "Project1.cbproj" -- FAILED.

   or it will try to post-process a wrong file (and either fail or succeed).

Conclusion: the TCTargetsXYZ.Targets file was created for EurekaLog 6 and early builds of EurekaLog 7 for older IDEs which output the compiled file into the same folder as the project file by default.

Solution:

Try to update TwineCompile to the latest version.

The TCPostLink target will be executed only when the "EurekaLog" condition is defined. You can remove/disable the "EurekaLog" condition/override to skip the TCPostLink target. Please note that you will have to manually call ecc32.exe to post-process your compiled executable. For example, you may try to use MSBuild build events.

Alternatively, to fix the "'ecc32.exe' is not recognized as an internal or external command, operable program or batch file" error you can do one of the following:

1. If you have just one IDE installed - you can just add the corresponding C:\Program Files (x86)\Neos Eureka S.r.l\EurekaLog 7\Packages\IDEName\ folder to your PATH environment variable.
2. Alternatively, you can edit the C:\Program Files (x86)\JomiTech\TwineCompile\TCTargetsXYZ.Targets file to include full file name of the ecc32.exe. Do not forget to add double quotes to escape spaces. 
3. As last resort measure - you can copy the ecc32.exe file from EurekaLog's folder to the \bin folder of your IDE and see if your IDE will load. While it is a possible workaround, we do not recommend it.
4. Or you can edit the C:\Program Files (x86)\JomiTech\TwineCompile\TCTargetsXYZ.Targets file to simply remove the whole TCPostLink block, so it will not try to call EurekaLog at all. Please note that you will have to manually call ecc32.exe to post-process your compiled executable. For example, you may try to use MSBuild build events.

Once the ecc32.exe will be called properly - you need to sort out the "Compiled file "...\Win32\Release\Project1.exe" not found" error. You can do one of the following:

1. Configure your project to output the final compiled file into the same folder as your project file (.cbproj). Do it for the Base configuration - so it will be inherited by all build configurations. If some build configuration overrides this setting - do not forget to reset it too.
2. Alternatively, you can edit the C:\Program Files (x86)\JomiTech\TwineCompile\TCTargetsXYZ.Targets file to include additional info about how your project is compiled.

For example, the final fixed TCPostLink target in the TCTargetsXYZ.Targets file may look something like this:

<Target Name="TCPostLink">
  <Exec
    Condition="'$(EurekaLog)'!='' And '$(TLibLink)'!='true' And ('@(OutputOutOfDate)'!='' Or '$(ForceLink)'=='true')"
    Command='"C:\EurekaLog\Packages\Studio29\ecc32.exe" --el_mode=Builder "--el_alter_exe=$(MSBuildProjectFullPath);$(OutputPath)"'
    />
</Target>

where:

• "C:\EurekaLog" is your EurekaLog installation folder. You should replace it with your EurekaLog path; 
• "Studio29" is the name of RAD Studio 12. You should replace it with your IDE name.

However, you can add additional arguments - such as --el_ide, --el_buildconfig, --el_config, --el_wait, etc.

I get this error when building my C++ application with EurekaLog:

[bcc64 Error] Project.cpp(4): C++ requires a type specifier for all declarations

Is this a bug or am I doing something wrong?

Reason:

This issue has nothing to do with EurekaLog. One possible reason for this issue may be IDE being confused by your manual editing of your project's .cpp file and auto-inserting code in a wrong location.

For example, if you create a new application (without EurekaLog) and put code in the following order:

USEFORM("Unit1.cpp", Form1);
#include 
#pragma hdrstop
#include 
//---------------------------------------------------------------------------
int WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPTSTR, int)
{
  ...

you will get the mentioned error.

The correct order should be:

#include 
#pragma hdrstop
#include 
USEFORM("Unit1.cpp", Form1);
//---------------------------------------------------------------------------
int WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPTSTR, int)
{
  ...

Solution:

Rearrange code in your main .cpp file in the correct order. Create a brand new empty application to serve as a reference point. Pay close attention to your forms.

See also:

• Configuring C++ Builder project for EurekaLog.

EurekaLog causes internal error DBG2304 when compiling my fairly-large project. I have uninstalled it and re-installed older version of EurekaLog, and now I don't have that problem anymore.

Reason:

Unfortunately, internal errors are bugs in the IDE's compiler. That is something that we can not fix.

Occasionally when compiling an application in Delphi, the compile will halt and display an error message that reads, for example: Internal Error - X1234. This error message indicates that the compiler has encountered a condition, other than a syntax error, that it cannot successfully process. The information after "Internal Error" contains one or more characters, immediately followed by a number that indicates the file and line number in the compiler itself where the error occurred. Although this information may not help you, it can help Embarcadero track down the problem if and when you report the error to the Embarcadero. Be sure to jot down this information and include it with your internal error description.

A possible reason for such error is when IDE has few minor updates (for example, RAD Studio 12, RAD Studio 12.1, RAD Studio 12.2), and one minor update (like RAD Studio 12.1) has a bug that makes it incompatible with other IDE updates. The mentioned issue could appear when you are building a project in IDE containing the bug (like RAD Studio 12.1) while linking it with precompiled files compiled in IDE update without the bug (like RAD Studio 12.2).

Solution:

1. Install the latest updates for your IDE. 
2. If upgrading to the latest IDE patch is not possible - one possible way that may work is to recompile EurekaLog for your IDE version.
3. One common reason why your project fails when adding EurekaLog is because you are running out of memory. In other words, you have a large project, you add more code to it (not necessarily EurekaLog, just any code that is large enough). If this is the case, try setting "Project" - "Options" - "Delphi Compiler" - "Use MSBuild externally to compile" to true. This will cause the compiler to run out of process (as a standalone process), which means a bit more free memory to actually do the work.
4. If that did not help - please, report this issue to Embarcadero support.
5. While the issue is being investigated by Embarcadero - please, follow these steps.

Reported in:

EurekaLog version: 7.13.1.0

IDE version: 12.1

See also:

• Compiling project with EurekaLog fails with the F2084 Internal Error: URW8074
• My IDE crashes with EurekaLog 7
• "File XYZ was compiled with different version of ABC" error
• "Could not compile used unit XYZ" error
• "File not found: XYZ" error
• "The procedure entry point XYZ could not be located in the dynamic link library ZXY" when starting IDE with EurekaLog installed

I receive the following error when I run my application compiled with EurekaLog with DLL also compiled with EurekaLog:

Invalid EurekaLog configuration found.

Exception from the following module:
full-file-name-to-your-EXE-or-DLL
was catched in the following module:
full-file-name-to-your-DLL-or-EXE
Both modules have EurekaLog enabled, but EurekaLog code is not shared.

This is essentially the same error as:
- "Can''t assign a TFont to a TFont";
- "Invalid class typecast";
- reInvalidCast;
- "Run-time error 10".
etc.

Possible solutions:
- Do not allow exceptions from one module escape into another (recommended)
- Compile DLLs with Lightweight DLL profile, so your DLL will not have EurekaLog's code
- Compile EXE and DLL with run-time packages, so EXE and DLL will share EurekaLog's code

Reason:

The check is triggered when EurekaLog catches exception, which has EurekaLog information assigned, but this EurekaLog information does not come from EurekaLog itself! 

Solution:

After upgrading from EurekaLog 7.12.0.5 to EurekaLog 7.14.0.0, localized resourcestrings are no longer correctly loaded when compiling VCL application with EurekaLog. Localized forms are loaded correctly, but resourcestrings remain in their original values or simply empty. When compiling without EurekaLog, everything works as expected.

Reason:

1. When you add/remove EurekaLog from your project: list of resourcestrings in your project changes, because EurekaLog also has resourcestrings. The same thing may happen when you change EurekaLog version, as the different EurekaLog's versions may have different resourcestrings.

Changing list of resourcestrings can cause changing IDs of resourcestrings.

For example, a particular resourcestring rsCaption may have the ID of 1 in your project. When you add, remove or change EurekaLog in your project, the rsCaption may get ID of 99. However, your localization project still contain localization for the ID 1 (not 99). Which means your application will fail to load translation for the ID 99 from your localization project, as your localization project does not have translation for ID 99; it has translation for ID 1. This will cause the rsCaption to become empty, remain unchanged, or receive an incorrect value.

2. Alternative reason could be you are not using ITE to auto-load the resource DLL to match the UI language. Rather you wrote a code to manually force-loading a specific resource DLL by altering the .ResInstance property of a module. However, the .ResInstance property is not used directly to load resourcestrings. Rather it is stored (on demand) into internal hashed list of resource modules. 

Solution:

1. You have to update your localization projects. Use the "Project" / "Languages" / "Update Localized Projects" IDE's menu item, then do "Project" / "Build All Projects". This should sync your resourcestrings IDs.

Just make sure you deploy new versions of your localization binaries.

2. If you are dynamically changing resource DLL's, the SysUtils module provides the ResStringCleanupCache function to purge the internal cache of loaded resource strings. Which will cause the new (updated) .ResInstance property to be stored into the hashed list. EurekaLog also has a similar cache for resource strings, which also has to be purged. There is a similar ResStringCleanupCache function in the EResourceStrings unit. In other words, your code should look something like this:

uses
  ...
  SysUtils,
  {$IFDEF EUREKALOG}EResourceStrings,{$ENDIF}
  ...


begin
  ...
  
  // Load new resource module:
  CurModule.ResInstance := LoadLibraryEx(PChar(ResModuleName), 0, LOAD_LIBRARY_AS_DATAFILE);


  // Cleanup internal cache of loaded resource strings:
  ResStringCleanupCache; // will call the EResourceStrings.ResStringCleanupCache or SysUtils.ResStringCleanupCache 
  
  ...