Delphi XE8 and Fatal Error F2039

Question

With XE8 update 1, Win 7 64 bit and a single component added to an otherwise empty folder I get: error: [dcc32 Fatal Error] F2039 could not create output file .\Win32\Debug\MountTest.

The test will compile and run fine the first time but XE8 has to be shut down and restarted to compile again. The component is a gauge from Mitov Software. The component vendor say's that this is a known bug with no fix. If so its a showstopper and project end'r for me. Is it really the end of the line for Delphi?

I hope some one can pull this rabbit out of a hat somehow.

This is what I have done to isolate the problem.

1. Started with a failing application (will not compile a 2ed time)
2. Remove all external units used
3. Remove al references to those units
4. Remove all references in the 'Uses' clause
5. Comment code until it compiles

It should compile every time you hit run (no problem).Now add a blank form to the project. Don't do anything to the form just add it. Add it to your uses clause.

Its should compile every time you hit Run. Now open the blank form and simply touch it so that it needs to be recompiled.

When you run the application its back to failing when you run it a second time.

Notice that happens when you simply add a form and 'touch' it. No code needed.

This problem is not something wrong with my code - it can't be. Its a bug in the UI - must be.

Bettyannbettye

It could be an issue with this mysterious component. There are no real details here so it's hard to see how anyone here can help. – Rundgren

docwiki.embarcadero.com/RADStudio/XE8/en/… – Purview

Or it could be an issue with your system. It could be literally anything. Unless you can furnish more details, nobody can help. – Rundgren

I had this issue, and the solution was to make sure the service "Application Experience" is running. – Collimator

The 'Mysterious Component' is a gauge from Mitov Software (in the text). I don't know what else I could add. Running Win 7 64 bit. Single component added to Delphi XE8 application. Creates the error every time. – Bettyannbettye

Jerry - I have seen a lot of comments that pointed to this service and I did make sure it was running with no help. I also tried all combinations of parameters also no change. – Bettyannbettye

The EXE generated cannot be deleted manually. When I try the system tells me I don't have enough privileged. I cannot even see who the owner of the EXE is. The only way to get rid of it is to restart XE8. – Bettyannbettye

Well, if there's nothing more you can provide, so be it. – Rundgren

There's your problem, you need to verify that your folder has appropriate privileges. This isn't even a programming issue, it's a basic computer usage issue. I find it highly suspicious that the vendor says it's a "known bug with no fix". – Collimator

Jerry - You misunderstand the problem. I created the folder before I compiled the application. The created EXE that goes into the folder is what cannot be deleted manually. Its like XE8 sets some sort of privilege on the EXE when it creates it and forgets what it was. – Bettyannbettye

David - I would be glad to add more information. What do you think might help? – Bettyannbettye

One obvious possibility is that the application is not actually terminating completely. Attempting to rebuld can fail if the previous executable cannot be deleted and replaced with the new one - this can happen if the exe in question is still alive. Did you check that the process exits completely in task manager? – Cadman

@Jerry: I had the issue with Application Experience running; I even restarted it as part of searching for a solution. It didn't help. – Diller

I agree with @J.... If this happens to me, it is caused by an application or the debugger not terminating properly. The debugger may still have a lock on the application. Try to rename the project and see if it compiles then. – Casias

are you using IdeFixPack? – Hornbeck

Did you contact the vendor? – Rundgren

@Hornbeck - No on ideFexPack. Are you seeing the same problem? – Bettyannbettye

@SetiNet -- No, i don't have such issue. Tested under: Win 7 SP1 -- Delphi XE7 Update 1, Delphi XE8 Update 1. Win 8.1 -- Delphi XE8 Update 1. – Hornbeck

@SetiNet: I have the same issue with Delphi XE8 Update 1, Windows 7 64 bit. In my case I use Devexpress controls in a very simple project. Application Experience is running. After several successful runs, I run the app in the debug mode, I closed its window, and I now get the error that it cannot create the exe. It seems that the bds.exe process holds a lock on the app executable (I used process explorer to find this). – Beetroot

@SetiNet: Did you find any resolution? I now get this consistently and it is extremely annoying. I have a second laptop and I never get the error on that one which makes it even more annoying. On this one I run Windows 7 64 as parallels VM. The project code is on the C: drive. – Beetroot

@SetiNet: Sorry, one more thing, I don't get the error on Delphi 10 Seattle with the latest update. – Beetroot

Answer 1

Coincidentally, I just fought with this issue yesterday testing some components I ported to XE8. The output file in my case is the project executable.

After spending several hours trying to figure out what was going on (including efforts to reconfigure my AV software, disabling it entirely, moving the project to a different location, etc.), I was able to solve the problem by disabling Castalia. If I run the IDE without Castalia, the problem does not occur. If I enable Castalia again, it starts happening again.

You can find instructions for disabling/enabling Castalia in How can I disable Castalia in XE8?

I'm removing the above content because the issue has reappeared (with Castalia disabled). Further investigation shows a couple of things:

1. The problem seems to be related to any sort of exception being raised in the debugger (even those that are handled in the code). Clicking either Break or Continue in the debugger exception dialog works as always. However, the next attempt to compile or build the application fails with the F2039 error. Deleting the executable in Windows Explorer allows compilation and running once, and then the error recurs.

2. Restarting the IDE fixes the issue, until the next debugger exception occurs.

3. Neither taskkill or a batch file with del worked in either a pre- or post-build event.

4. There is an open QC entry for it at Embarcadero which indicates that it was reported in XE7, XE7.1, and XE8, and is currently an open internal ticket. I can't find a way to add the information in the two points above to that open ticket in the new JIRA-based Quality Portal. Perhaps someone who has access and can do so will on my behalf (or at least add a link to this post).

5. It's not linked to a specific project. The original answer (as mentioned above) was related to a test app while porting some components to XE8 from an earlier version. When the problem reappeared for me, it was in a brand new project, totally unrelated, that does not use any non-standard components.

(I previously had access to EMBT QC, and had a few open tickets. The accounts appear to have not migrated to the new QP, and I can't locate any tickets there under my account.)

Diller

Yes - That does the trick. I can get along without refactoring but what else am I missing with Castalia removed. – Bettyannbettye

Ken - I wanted to thank you for posting this fix. I was within an Ace of chucking the whole project and Delphi along with it. Now I can go ahead. – Bettyannbettye

I thought that stopping Castalia was the solution but it was not. The next day and I T ' S B A C K ! – Bettyannbettye

It didn't come back on mine, and I've used it all day yesterday. – Diller

Its back full time for me. I also thought I had it solved when I started running the IDE as an administrator. Seem'd to work for a while but then back again. – Bettyannbettye

I did find a 'solution' that seems to help. I noticed that my service: AppMgmt was not running and was set to start manualy. I changed that to automatic start and it does seem to help. Still experimenting with it. – Bettyannbettye

Answer 2

Found It. I decided to start from scratch on my development system and uncovered the problem.

I installed Windows 10 on a virgin disk

Installed XE8 update 1

Installed MITIOV Instruments for XE 8 and tested them. All working find

Installed AsyncPro - Still working

Installed the JEDI Jcl - Fails

Remove JEDI Jcl - now works

Trash JEDI completly - Everything works fine

Something in the JEDI Jcl version 3.48 is causing the problem. I can code around the JEDI components I was using without to much trouble but its a shame.

Bettyannbettye

I thought the JCL and JVCL available from the XE8 package manager might fix this problem - I was wrong. JCL is still not useable with XE8. – Bettyannbettye

Answer 3

How about automatically kill your "hang-up" application before build?

Hornbeck

Good idea but still fails. I put in: del $(OUTPUTFILENAME) but that command returns: Access is denied. – Bettyannbettye

Doesn't work. The IDE won't delete it. I tried using both a pre- and post-build event. I tried both killing the task and deleting the .exe with a batch file. None worked. See my repro steps. – Diller

Answer 4

I also had this problem on Win 7 Pro 64 bit with XE8.

Removing JCL fixed the problem. If I was a betting man, I would look closer at the JCL Debug IDE extension.

Cordy

Answer 5

Guy's..

There is no reason to upgrade to Delphi 10.1, because all previous versions are equipped with an older version of the Android SDK.

Now, how to solve this annoying issue:

Just find the map where the Android SDK is located. See: Tools/Options/Delphi Options/SDK Manager/Android Location

Now run the ..\sdk\tools\android.bat as Admin This will show the Andoid SDK Manager.

Next is to update to the newest Android SDK and SDK Tools.

If all completed, you don't have to upgrade to Delphi 10.1 or whatever "advised".

Restart Delphi and problem:= solved!

btw: It took some effort to find out what's happening here, because the Eclipse compiler suffered the same issue as Delphi. Finally all was related to bugs in earlier versions of the Android SDK causing adb.exe to keep a filehandle held hostage.

Columnist