How to fix "LME288/Unknown heap name" warning?

Question

Suddenly, out of the blue, I get the LME288 linker error.

[ilink32 Warning] Warning: D:/Projects/TrainFever Game Manager/TFGM/Win32/Debug/TFGameManager.ilc: 0x00010000 / 0x08000000
[ilink32 Warning] Warning: D:/Projects/TrainFever Game Manager/TFGM/Win32/Debug/TFGameManager.ild: 0x00010000 / 0x08000000
[ilink32 Warning] Warning: D:/Projects/TrainFever Game Manager/TFGM/Win32/Debug/TFGameManager.ilf: 0x00010000 / 0x0a000000
[ilink32 Warning] Warning: D:/Projects/TrainFever Game Manager/TFGM/Win32/Debug/TFGameManager.ils: 0x0003b000 / 0x08000000
[ilink32 Warning] Warning: unknown heap name   : 0x08000000 / 0x08000000
[ilink32 Warning] Warning: Error detected (LME288)
[ilink32 Error] Error: Unable to perform link

I have no AV installed and the project has been running fine for over a year. I have tried:

• Incremental linker disabled/enabled, no difference...
• Manually removing all files in /debug, still no change...
• Full Build, no difference...
• Reboot computer, no changes...

This has been asked before here but no real explanation or solution was presented.

What else can I do to fix this?

EDIT
I tried to rebuild a couple of other projects that has been running fine for years and now I get the LME288 error on all my projects.

Answer 1

On 15 Jan, 2020, Embarcadero changed the status of RSP-12869 from "Needs feedback" to "Open" and assigned it to Internal Dev.

Older History: With the 10.2 Tokyo release of C++ Builder in April 2017, Embarcadero upgraded the linker, claiming to solve the problem: "The linker is now large address aware and can address up to 4GB on a 64-bit system, twice the previous amount. (Some customers hacked the linker to be LAE [sic] in the past by toggling the bit in the PE header; since the code wasn't written to be LAE-aware this hack prevented incremental linking and sometimes other functionality from functioning correctly.)" https://community.embarcadero.com/blogs/entry/what-s-new-in-c-builder-10-2-part-1-the-linker

However, on May 24, 2017, Ashleigh Quick reported that 10.2 Tokyo's linker still does not resolve the problem: RSP-12869. Similarly, @Ultralisk reports the same problem in a comment below on 2020-01-09.

Here's one workaround: beginning with 10.2 Tokyo, you have some new options to control LARGEADDRESSAWARE and linker heap sizes. Dieter Woellner reported on 26-Oct-2017 that, temporarily, setting C++-Linker | Advanced | Advanced Options entry to "-GF:LARGEADDRESSAWARE" eliminated the problem. But the problem returned, and he discovered that if you set the TDS Heapsize to a value below 0x08000000 you avoid the error/crash on linking...for now.

=====================================

I am one of those customers who hacked the linker to be LAA, thereby interfering with incremental linking (which I don't need) and solving my problem. If you don't need incremental linking, read on.

=====================================

I resolved the problem by setting the /LARGEADDRESSAWARE flag in ilink32.exe. The original solution came from Hiroyuki Shimada, using editbin, and posted at http://qc.embarcadero.com/wc/qcmain.aspx?d=134775 on 1/12/2016. He also applied it to bcc32.exe; I didn't need to.

As a public service, I have posted my patched ilink32.exe versions here:

• RAD Studio 10 Seattle: https://s3.amazonaws.com/public-mfay/ilink32.exe
• RAD Studio 10.1 Berlin: https://s3.amazonaws.com/public-mfay/ilink32-10.1.exe

To use either, rename your ilink32.exe in your RAD Studio binaries directory (e.g. C:\Program Files (x86)\Embarcadero\Studio\17.0\bin for RAD Studio Seattle, or ...\18.0\bin for Berlin), and copy mine in its place, renaming it to ilink32.exe.

[Note: these /LAA linkers solve the problem for many, but not all users; see @Andrew Legget's post on 7/25/2016 at https://quality.embarcadero.com/browse/RSP-13247]

This problem has been around for a long time and is not limited to XE3, XE5, XE7, XE8... There is now a lengthy discussion/lament at https://quality.embarcadero.com/browse/RSP-13247 as to why this was fixed in one version of RAD Studio but backed out in a later version; apparently /LAA "resulted in failures when linking incrementally with the static RTL". According to the 28/Mar/16 12:14 PM post by Dennis Jones in that thread, the /LAA patch does NOT address the other linker errors "EXE1825" or "out of memory".

Read below if you want to see three ways in which ilink32.exe can be patched...

---

1. Set Large Address Aware flag with the lamarker tool, downloadable from: http://cc.embarcadero.com/Item/30459 (thanks to Doug Hay, 19/Jul/16 post in https://quality.embarcadero.com/browse/RSP-13247):

   lamarker -M -Filink32.exe

(You may do this directly in your C:\Program Files (x86)\Embarcadero\Studio\17.0\bin (or ...\18.0\bin) directory; it will rename the original ilink32.exe to ilink32.exe.old -- if you have permission)

--OR--

2. Use editbin from MS Visual Studio, if you already have such installed (Microsoft claims that editbin must be run from within the IDE). As a preliminary step, copy bcc32.exe and ilink32.exe to prevent UAC's block (and to back them up)

   copy "C:\Program Files (x86)\Embarcadero\RAD Studio\12.0\bin\bcc32.exe" .

   copy "C:\Program Files (x86)\Embarcadero\RAD Studio\12.0\bin\ilink32.exe" .

   editbin /LARGEADDRESSAWARE bcc32.exe

   editbin /LARGEADDRESSAWARE ilink32.exe

-- OR --

3. Set the Large Address Aware flag using editbin from the masm32 package:

Download from http://www.masm32.com/download.htm, which creates c:\masm32\bin\editbin.exe. I got a few warnings (involving ordinals 201 and 203) during MASM32 installation but its self-test passed, and all I needed was editbin.exe.

Answer 2

I have been having this problem as well with RAD Studio XE8 installed on Windows 10. When installed on Windows 7 (x86), RAD Studio XE8 worked properly.

After upgrading to Windows 10 (x86) I ran into the dreaded unknown heap LME288 errors. At first it didn't appear on Windows 10 but if I installed something, it would pop up. If I restored the computer to Windows 7, it would disappear.

After a little research on the net, I found the solution. There is a memory problem with ilink32.exe and you need to enable the 3GB memory space at bootup on the computer. Here is what I do now if this error is ever displayed again:

1. Run command prompt as Administrator.
2. Type (without quotes) "bcdedit /set IncreaseUserVa 3072"
3. Reboot computer.

After doing that, ilink32 works properly.

I found that after installing a newer version of Acronis True Image (2016), the LME288 error came back. But running the bcdedit solution here, it fixed the RAD Studio XE8 linker!!!

Answer 3

I found a workaround that seems to work.

It seems to have something to do with corrupted temporary files. I managed to get it to work again after I did a "Disk Cleanup" on my system disk.

I Deleted all files in the list (all checkboxes checked) and also the "Clean up system files"

After that I could compile and link, even without rebooting. Even the incremental link began to work again!

Answer 4

Just running XE8 as administrator fixed it for me.

Answer 5

As Drewski I ran into the LME288 error after the upgrade to Windows 10 (x64).

The error disappeared changing the Data Execution Prevention settings for ilink32.exe:

• System properties -> Advanced system settings -> Performance -> Settings -> Data Execution Prevention
• Turn on DEP for all programs and services except those I select -> ilink32.exe.

Answer 6

In my case, trying all the other options here mentioned didn't work at all.

What seems to did the trick was setting manually the amount of virtual memory, in the System Settings of my Windows 10 machine. It was set to be managed automatically by the Operating System, but changing it to a manual value (even when the minimum was less than what was assigned automatically, and it is what is being used actually) made the linker work again.

In my case the OS had assigned something like 1,600 Mb. I set the minimum to 1,024 and the maximum to 3,072, restarted, and now the linker is working fine. The amount used says 1,024 (even when the recommended value says ~1,900).

Answer 7

I have a different solution that hopefully will help someone struggling with this.

I tried everything and none of the solutions suggested earlier worked for me. Disk cleanup didn't help. This is clearly a bug in C++Builder that existed for many years, and is still not fixed even in XE8 as of 2015.

Luckily, I had another computer with working environment, where the same project did compile. I copied all files (*.exe, *.obj, etc) from the output directory (Win32/Debug) from that computer to the one where I had the problem, and that magically set C++ Builder straight; all builds afterward started to work.

Answer 8

Fixed for XE10 and Windows 10 (x64) with Bitdefender IS 2016:

Bitdefender -> Modules -> Antivirus -> Exclusions -> Excluded Processes -> Add "...\bin\ilink32.exe" -> Allow

Answer 9

Rebooting W10 solved this issue on XE5 but I am desactivating incremental build