Watch, Follow, &
Connect with Us
Public Report
Report From: Delphi-BCB/Debugger/Execution    [ Add a report in this area ]  
Report #:  103862   Status: Closed
[Regression in Update 4] When recompiling after debugging, the IDE does not close the handle to the EXE
Project:  Delphi Build #:  16.0.4429.46931
Version:    16.4 Submitted By:   Rubén Valls Blasco
Report Type:  Crash / Data loss / Total failure Date Reported:  3/2/2012 2:00:44 AM
Severity:    Critical / Show Stopper Last Updated: 4/15/2014 6:48:27 PM
Platform:    All versions Internal Tracking #:   28242
Resolution: Fixed (Resolution Comments) Resolved in Build: : XE6
Duplicate of:  None
Voting and Rating
Overall Rating: (1 Total Rating)
3.00 out of 5
Total Votes: 123
Description
It actually happens after the update to Update 4.

The first time after opening the IDE, the compilation goes fine. I execute the project to debug it, do some changes, and after recompiling, the next error is thrown:

[DCC Fatal Error] F2039 Could not create output file 'path to exe file'

I have to close the IDE before being able to manually delete the file.

My OS is Windows XP Service Pack 3 (if it matters).
Steps to Reproduce:

Added by Sysop
<<<<<<<<<<
I have the same problem.

File can be deleted without any problem. So I guess, the application is terminated. Perhaps there could be a process in background. I have not checked in the processlist.

Looking for this problem by google-search give many hits. It could not be a singular problem. I have this problem on more than one project (DB-Projects, XML-Projects, Very simple vlc-projects for tests). Waiting 1 or 2 minutes solve the problem either.

In my opinion the debugger hold the file-handle.

The problem occurs in win xp, win7, 32bit, 64bit. It does not matter for the rights (administrator or restricted user).

Fact is:
- Deleting is possible
- Waiting solve the problem also
- It does not matter what kind of project it is
- Turning off the av-program does not change anything
- Path exists an is not read-only
- Changing user-rights did not change anything
- My projects are all local. No mapped drives or something like this.

I hope these information will help to solve the problem.
>>>>>>>>>>
Workarounds
None
Attachment
None
Comments

Roland Kossow at 3/3/2012 12:31:07 PM -
Same here on Windows 7 64 BIT.
The only workaround is to close the IDE so the handle gets freed.

Tomohiro Takahashi at 3/4/2012 6:17:44 PM -
Could you please attach more detailed [Steps] and attach sample project to reproduce your issue?

> [DCC Fatal Error] F2039 Could not create output file 'path to exe file'
I guess the .exe file is locked by some proecess.
After debugging, does the process(.exe) is running in your OS?
and, can you delete the .exe file via Explorer or command prompt?

Peter Schrade at 3/21/2012 7:38:09 PM -
I have the same problem.

File can be deleted without any problem. So I guess, the application is terminated. Perhaps there could be a process in background. I have not checked in the processlist.

Looking for this problem by google-search give many hits. It could not be a singular problem. I have this problem on more than one project (DB-Projects, XML-Projects, Very simple vlc-projects for tests). Waiting 1 or 2 minutes solve the problem either.

In my opinion the debugger hold the file-handle.

The problem occurs in win xp, win7, 32bit, 64bit. It does not matter for the rights (administrator or restricted user).

Fact is:
- Deleting is possible
- Waiting solve the problem also
- It does not matter what kind of project it is
- Turning off the av-program does not change anything
- Path exists an is not read-only
- Changing user-rights did not change anything
- My projects are all local. No mapped drives or something like this.

I hope these information will help to solve the problem.

Tomohiro Takahashi at 3/22/2012 11:53:45 AM -
> Waiting 1 or 2 minutes solve the problem either.
Thanks for the information. This report will be opened after maintenance of our internal system.

Lance Rasmussen at 3/27/2012 3:19:21 PM -
I have same problem.  This regressed as XE did not have this issue.

My setup is XE2 Update 4 in Windows 7 x64 VMWare 8 Guest on Windows 7 X64 Host.  Project is in a mapped drive. No other IDE's or past RAD Studio IDE's were installed.  In current incarnation, I just did a clean VM install of Windows, RAD Studio XE2 with Update 4.

Antivirus is on host, with shared folder where project is - Excluded from scan.

Lance

Lance Rasmussen at 3/30/2012 11:24:44 AM -
Steps I've tried that still do not resolve this issue.

1) Remove Antivirus from Host.
2) Create new Windows 7 Pro X64 Host, Reinstall IDE.
3) Remove Antivirus from Guest.
4) Added DEL $(OUTPUTDIR)\$(OUTPUTFILENAME) to the Pre-Build Event. On failure, I noticed the IDE couldn't delete the EXE, yet I could through Windows guest or host.
5) Changed DEP settings to ignore the project built EXE.
6) Monitored to see if issue only occurs during F2 terminating or if closing application gracefully when debugging. Issue happened under either situation.

This issue happens about every 2-3 times I compile and debug an application. Due to the number of components installed, restarting the IDE is time consuming and not acceptable to do almost every time I debug an application.

Lance Rasmussen at 3/30/2012 1:11:55 PM -
Using OpenedFilesView utility, it appears that the IDE still is holding onto the file handle of the built EXE, regardless of if the debugged EXE was closed gracefully or Reset in the IDE.  This happens for me every couple builds.  This prevents the IDE from deleting the EXE or overwriting to it.

Pierre Duparte at 3/30/2012 2:31:16 PM -
In my case I am using update 3. I get fatal errors when I try to install update 4.

In fact, I think the problem actually began for me after upgrade 3.

Pierre Duparte at 3/30/2012 2:33:18 PM -
I forgot to mention the problem only occurs when I do a "RUN" F9 and then RESET or if the application being tested crashes with an AV etc. If I exit the run cleanly then there's no problem,

Tomohiro Takahashi at 5/17/2012 7:35:29 PM -
This report was opened with valid Internal Tracking Number.
Thanks.

Jeferson Oliveira at 6/8/2012 3:41:26 AM -
Workaround that is working for me:

1) Download and install Unlocker (http://www.emptyloop.com/unlocker/);

2) Inside the IDE, open your project and access "Project/Options/Build Events/";

3) Define the following command on the "Pre-build events":
C:\Progra~1\Unlocker\Unlocker.exe $(OUTPUTDIR)\$(OUTPUTFILENAME) /D /S

Every time the project is compiled Unlocker will close the handle of the file and force its deletion before the IDE call the compiler again.

P.S.: The pre-build command should be define for every project to be compiled.

Gabriel Castillo at 6/19/2012 9:31:32 AM -
(Sorry for my english... but.. I hope this can help)

In my case the problem was because Delhi don't report an exception when I use Run without Debug, and when I run the program with F9 (Run) I get the exception. Above the problem and the solution. So I recomend use always Run (with the debugger -key F9- )

----

OK, I have some code like this:


procedure TSincronizador.SetProyecto(const Value: TFProyecto);
begin
           FProyecto := Value;
           FDiagrama := FProyecto.Diagrama;
           FProyecto.herramientas := herramientas;
           FProyecto.ActionListDiagram := ActionListDiagram;
end;

when compile/execute the program delphi don't do anything! I try to run again and I don't have any response... I run some times and I don't see nothing!

But if I see the process I see the program running! I close this process and go to debug, Then I get an exception notification:

Projec xxx.exe raised exception class $c000005 with message 'acces violation at 0x00656b7: read of address 0x000039

the solution was:

procedure TSincronizador.SetProyecto(const Value: TFProyecto);
begin
  if Value <> nil then
      begin

           FProyecto := Value;
           FDiagrama := FProyecto.Diagrama;
           FProyecto.herramientas := herramientas;
           FProyecto.ActionListDiagram := ActionListDiagram;
      end;

end;

Hansie Grobler at 6/19/2012 1:38:14 PM -
I actually had this error before update 4. This is definitly something new to delphi and very, very unwanted!

I'm am guessing it is **something** todo with the 3rd party libs that we use, because you can work in one project and not hit the problem, but in another, hitting it after each run (program-break or even successfull close).

This problem is not due to any simple faulty code.

They/we really need to sort this because it is effecting productivity big-time and the only solution in my case is restarting the IDE.

Getting the problem on:
OS:
  Win7 64bit

Envir:
  Normal VCL app with NO FireMonkey
  DevExpress
  Graphics32
  Zeos Lib
  Some smaller libs...

Hansie Grobler at 7/31/2012 10:01:57 AM -
Well, I seemed to have solved my problem, when going through all my libraries, I saw that Jedi Library installs IDE experts, removing these additions from the Jcl-install under "IDE Experts" solved the problem completely for apps that use to crash after only one build.

So the problem was never really in Delphi ...

Hope this helps someone.



Christina Louise Warne at 8/7/2012 12:30:51 PM -
A colleague and I are both experiencing this issue.

Environments are a mix of Windows XP (SP3) and Windows 7.  XE2 is update 4, help is update 6.

We have the latest versions of madExcept, DevExpress, SecureBridge and UniDAC installed.  My colleagure also has the latest version of the Jedi libraries installed.

My investigations have shown that a handle to the output file is retained following a compile/link.  I'm not sure whether it's the compiler or the linker, but once that handle is retained, it's a spiral to an XE2 restart.

I can delete the file, for a while or I can close the handle using ProcessExplorer.  But ultimately, once the problem starts it ends with an XE2 restart being required.

Between us we've found it doesn't really matter what components/libraries we have installed.  My colleague has whittled it back to a bare install, even trying a fresh install, and he can still end up in this scenario.

Waiting does not appear to solve the problem for us as the handle seems to be retained indefinitely.  I've also tried the suggestions relating to Data Execution Prevention settings.  These had no effect.

I can however confirm, that the same project, with the same libraries installed does not appear to suffer this issue on an installation of XE2 that only has update 3 applied to it.

As Hansie Grobler has already stated, this is a serious issue that needs to be given some attention.  It is a major block to productivity if you have to stop and restart your IDE every 15-20 minutes or so.

Warren Postma at 8/27/2012 12:18:53 PM -
I am experiencing the same problem as Christina.

It seems that the following are factors:

1. This happens to me on a Windows Server 2008 R2 machine with Delphi XE2 update 4. It did not happen prior to XE2 update 4.

2. It does not happen to me on Windows 7 or Vista.

3. Deleting the EXE allows Windows to create a new executable in my case, but many people report identical symptoms but they have to shut down the ide (or terminate it from task manager) in order to continue their work.

Warren

David Heffernan at 8/29/2012 11:44:58 AM -
I'm seeing this behaviour on XE2 update 3

Primoz Cerar at 9/6/2012 2:32:38 AM -
I have same issue though not in every project in my large project I do not have this problem but in new small VCL application I keep getting it. Sometimes the IDE also says it can not find the exe and when I do a compile I get F2039.
Win7 x64.
Delphi XE 2 Update 4 HotFix 1
DevExpress, and some other libs
IDE Fix Pack XE2 4.9.1
DDevExtensions 2.5
Compiler speed pack XE2 4.9.1

Greg Smith at 9/25/2012 9:43:12 AM -
I'm seeing this problem too, driving me crazy.

XE2 Update 4 hotfix 1
DevExpress
Unidac
Eurekalog 7

Warren Postma at 10/4/2012 6:06:57 AM -
I am now having similar problems in XE3, but only when I run the debugger on firemonkey applications.

Warren

Jeremy Knowles at 11/18/2012 7:34:47 AM -
Same thing happens to me all the time, with XE3, using Win7 64-bit.

Drives me nuts, the only way round it is to restart the IDE.

Perry Kappetein at 1/3/2013 6:19:03 PM -
I am having this in XE3 as well and in XE2 sometimes..
Now, I have both XE2 and XE3 installed.
I removed XE3 and did not get the error so far..

Harald Wolf at 3/15/2013 7:05:17 AM -
I had this issue with BDS 2009 and XE3 on Windows 7 64Bit.
I compared the "Application Experience"-service settings with other machines and
switched from Disabled to Manual and this problem ist gone.

read:
http://stackoverflow.com/questions/4378192/windows-2008-r2-kernel-system-process-pid-4-is-locking-files-and-folders

hope this helps!

Roy Tollison at 9/20/2013 4:02:25 PM -
I was using XE4 without any problems. Then started turning of misc. services looking to resolve another issue. Then with that problem resolved i tried to use XE4 again and started getting this problem. Tried uninstalling 3rd party add-ins, then did the uninstall and re-install, problem still existed. Finally saw post about the Application Experience Service and went and turned it back on. Problem was solved.

Aleksandr Shumihin at 6/18/2014 2:12:11 AM -
Still experiencing this issue with 64-bit projects in XE6 on Windows 7 afeter it was marked as fixed.

João Tavares at 8/4/2014 12:02:39 PM -
Set bds.exe to run as Admnistrator; Reset delphi and go be happy.

Server Response from: ETNACODE01