FastMM does not show leaks even if Inc file is properly set

An old project landed in my hands. It has 130000 lines of really bad code (no try/finally all exceptions swallowed, thousands of global variables). I expect thousands of memory leaks. However, FastMM4 shows nothing on shutdown. No message box, no txt log file.

I use the same FastMM settings (inc) for all other projects, it works. So, I am not suggesting FastMM (or its settings) is broken. I think just can't handle this impressive amount of leaks. A friend of mine told me that on a large project also with many leaks, it needed 5-10 minutes until FastMM generated the txt log.

Verifications:

• FastMM is declared on the first line in DPR.
• I manually created a line of code to generate a leak.
• EnableMemoryLeakReporting is defined (see listing below)
• I am in debug mode (Map file generation is set to "Detailed")

Any tips on how to get the log?

{$define UseCustomFixedSizeMoveRoutines}
{$define UseCustomVariableSizeMoveRoutines}
{$define NoDebugInfo}
{$define ASMVersion}
{$define CheckHeapForCorruption}
{$define DetectMMOperationsAfterUninstall}
{$define FullDebugMode}

  {$define RawStackTraces}
  {$define LogErrorsToFile}
  {$define LogMemoryLeakDetailToFile}
  {$define ClearLogFileOnStartup}
  {$define LoadDebugDLLDynamically}
  {$define AlwaysAllocateTopDown}
  {$define SuppressFreeMemErrorsInsideException}

{$define EnableMemoryLeakReporting}
  {$define HideExpectedLeaksRegisteredByPointer}
  {$define RequireDebuggerPresenceForLeakReporting}
  {$define EnableMemoryLeakReportingUsesQualifiedClassName}
{$define EnableMMX}
  {$define ForceMMX}

I have found the reason: The person who wrote the code uses KillTask to terminate the program (followed by Application.Terminate).
I removed that code. Now FastMM generates the log file which is 12MB! I have to fix them. Lucky me!

Personal thoughts: When I got the solution, I was sad, and I thought maybe this was not supposed to be a post for StackOverflow. On a second thought, it is fine. We learned something today: how not to write programs :)
Also, we learned that there are myriad of magic ways in which a mad programmer can break a program and we will spend days to figure our his mad-ways.

(In my language we have a saying: "When a mad-man throws a rock in a lake, 10 smart people cannot retrieve it", which means that it is easy to do something stupid, it is difficult to fix it.)