По умолчанию в EurekaLog включена опция "Active only when running under debugger".

P.S. Но вообще я большого смысла не вижу использовать трейсеры исключений для локальной отладки. У них цель другая - сообщить о проблеме с полей. Отладочный же инструмент типа FastMM в FullDebugMode всегда покажет больше деталей, потому что может использовать более тяжёлую артиллерию.

Такого точно быть не должно. Есть ненулевая вероятность, что возникает какое-то исключение при попытке показать отчёт. Под отладчиком если запустить - уведомление об исключении будут?

Ещё можно включить "Use Debug DCUs" и передать ключ командной строки --el_debug . При этом будет создан .csl файл в папке с .exe, куда будет записано всё, что происходит в приложении.

Я, правда, не уверен, что поможет первое или второе, поскольку утечки проверяются, когда в приложении уже всё убито - в том числе поддержка исключений. Скорее всего, тут надо по шагам смотреть.

Но если диалог появился, то файл отчёта должен быть уже создан. Он есть?

Andi_WEB, я не знаю, что именно вы смотрите, но по умолчанию диспетчер задач показывает сколько RAM выделяется программе. Это значение крайне слабо коррелирует с количеством выделенной в программе памяти.

У меня стоит Process Explorer в качестве диспетчера, но мне припоминается, что в штатном диспетчере Win10 в настройках была колонка Commit Size или что-то такое - это и будет реальное выделение памяти.

Во-вторых, утечка памяти Delphi тоже не всегда связаны с утечками памяти вообще. Например, вы можете создать TBitmap и его утечка - это, сколько, килобайт? Но в нём же есть HBITMAP - это по сути ссылка на растр в памяти. Он может мегабайты занимать, но как утечка обнаружен не будет, т.к. выделяется через другой менеджер памяти, не через Delphi. Однако устранив утечку TBitmap (килобайта) - устраните и утечку HBITMAP (мегабайтов). Ну, или если ваш код делает detach HBITMAP из TBitmap и потом утекает HBITMAP - тогда да, тут уже надо искать утечки не памяти Delphi, а прочих ресурсов.

Есть мнение, что надо начать с того, что устранить утечку уже найденного - начиная с самых комплексных объектов, типа TIdTCPClient, которых у вас утекло больше 200 штук! При этом, скорее всего, перестанут утекать и более мелкие, зависимые от него, объекты. Ну не знаю, какие-нибудь строки, TIdReply, TStringList...