[dcc32 Fatal Error] F2039 Could not create output file

[RockWallaby 1]

Hi,

 

I've been using RAD Studio (Delphi) 10.2.3 Tokyo for years.  All of a sudden yesterday afternoon, I have been unable to compile any applications I have written.  I get the following error message: [dcc32 Fatal Error] F2039 Could not create output file....

 

This is what I've done:

 

• Checked Task Manager to see if the executable is running - not running.
• Checked Process Explorer to see if the executable is running - not running.
• Used LockHunter to find out what is locking the executable - it reports nothing is locking it.  Tried using the Delete option - it says it is unable to delete it but can on next reboot.
• Tried deleting the file manually - comes up with Try Again message.
• Created a new blank application - same error.
• Rebooting the computer allows me to compile once, and then the error occurs on each subsequent compile (or build).
• Disabling anti-virus made no difference.
• Ran sfc /scannow - no corruption detected.
• Ran chkdsk - no issues detected.
• Now here's where it gets really weird.  I can create applications in RAD Studio 12 (Delphi) Athens without any problem.  It's just 10.2.3 that has the problem, but it worked fine up until yesterday afternoon (I was using it in the morning without any problem).
• Now this is bizarre - I can Cut and Paste the executable to another folder!!  I can then compile once but after that the same error message.  I can also hold down <shift> and move the file to another folder.

 

This is on a 2-month-old computer running Windows 11 Pro.  I've never had any problems compiling/building programs in 10.2.3 until yesterday, and I use it every day.

 

I haven't started using Delphi 12 Athens seriously yet because upgrading the components I use would cost over $2000.  So I'm sticking with 10.2.3 for now.

 

Any suggestions?

 

= Steve

 

Edited January 31 by RockWallaby

[DelphiUdIT 176]

Sometimes, but years ago, I had the same problem.

 

The executable is not show in the Task Manager or in Process Explorer, but it was running ... or better is locked in the shutdown state wait for something.

 

Sometimes you can delete it from disk, but pressing F5 will see it reappear. Other times, as you reported, you can't erase it.

At that time, not being able to understand what was happening, I inserted an "exitprocess" in the "destroy" event of the main Form and that solved the problem. Then subsequently starting to remove the "exitprocess" I no longer had any problems. But I can't tell you if it depended on the Delphi version or the operating system.

However, if I remember correctly from "Process Explorer" you can do a search with the name of the executable and it should find it for you (use "Find Handle and DLL" from the menu).

Bye

[RockWallaby 1]

I forgot to mention that I checked the permissions on the executable(s) too.

 

One thing I found is that, although I can't delete the file using the <delete> key, I can delete it using <shift> <delete>.

 

Edited February 1 by RockWallaby

[RockWallaby 1]

28 minutes ago, DelphiUdIT said:

Sometimes, but years ago, I had the same problem.

 

The executable is not show in the Task Manager or in Process Explorer, but it was running ... or better is locked in the shutdown state wait for something.

 

Sometimes you can delete it from disk, but pressing F5 will see it reappear. Other times, as you reported, you can't erase it.

At that time, not being able to understand what was happening, I inserted an "exitprocess" in the "destroy" event of the main Form and that solved the problem. Then subsequently starting to remove the "exitprocess" I no longer had any problems. But I can't tell you if it depended on the Delphi version or the operating system.

However, if I remember correctly from "Process Explorer" you can do a search with the name of the executable and it should find it for you (use "Find Handle and DLL" from the menu).

Bye

I tried searching for the executable in Process Explorer several times but it couldn't find it.

 

I will try the "exitprocess" but what I don't understand why it suddenly started happening, but only with the Delphi 10.2.3 IDE.

[RockWallaby 1]

2 hours ago, RockWallaby said:

I tried searching for the executable in Process Explorer several times but it couldn't find it.

 

I will try the "exitprocess" but what I don't understand why it suddenly started happening, but only with the Delphi 10.2.3 IDE.

Sorry, it didn't make any difference,  But thanks for the suggestion.

[Kas Ob. 121]

Hi,

9 hours ago, RockWallaby said:

Any suggestions?

6 hours ago, RockWallaby said:

I forgot to mention that I checked the permissions on the executable(s) too.

Yes, it is half of the problem in your case, here you didn't mention who is the owner of the EXE and the owner of the parent folder, both these values plays role,

 

The other half is either

1) System Protection has kicked in and sees that file (folder) as valuable and important, in this case there is copies and copies in the hidden/strict restore folder (System Volume Information) on the drive, you need to disable the protection and clear that folder then enable if you want it.

2) Windows Defender has kicked in and most likely sent the exe sample to Microsoft labs, i never ran this cloud protection (my main developing machine is still Windows 10), so don't know exactly what it does or how it behave, https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/cloud-protection-microsoft-antivirus-sample-submission?view=o365-worldwide

 

Also you can run Process Monitor https://learn.microsoft.com/en-us/sysinternals/downloads/procmon remove/exclude all other processes and leave only BDS.exe in this case (to catch dcc32 operation), from there you should have the real and internal failure on API level

this example of that same compiler error when the target exe is running and when was not

 

[Brandon Staggs 275]

Is this file in a location that is mirrored with a cloud service (OneDrive, DropBox, etc)? If so, remove that location from the cloud service.

[RockWallaby 1]

3 hours ago, Brandon Staggs said:

Is this file in a location that is mirrored with a cloud service (OneDrive, DropBox, etc)? If so, remove that location from the cloud service.

No it's not.  As I said previously, nothing has changed on my computer.  At least I haven't installed, changed or uninstalled anything.  It just suddenly started happening after working fine for years.  No matter what project I try to compile, I get this error.  And it doesn't happen with Delphi 12, only Delphi 10.2.

[RockWallaby 1]

14 hours ago, Kas Ob. said:

Hi,

Yes, it is half of the problem in your case, here you didn't mention who is the owner of the EXE and the owner of the parent folder, both these values plays role,

 

The other half is either

1) System Protection has kicked in and sees that file (folder) as valuable and important, in this case there is copies and copies in the hidden/strict restore folder (System Volume Information) on the drive, you need to disable the protection and clear that folder then enable if you want it.

2) Windows Defender has kicked in and most likely sent the exe sample to Microsoft labs, i never ran this cloud protection (my main developing machine is still Windows 10), so don't know exactly what it does or how it behave, https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/cloud-protection-microsoft-antivirus-sample-submission?view=o365-worldwide

 

Also you can run Process Monitor https://learn.microsoft.com/en-us/sysinternals/downloads/procmon remove/exclude all other processes and leave only BDS.exe in this case (to catch dcc32 operation), from there you should have the real and internal failure on API level

this example of that same compiler error when the target exe is running and when was not

 

1) System Protection - not sure where that is so I'll have to do some research.

2) Windows Defender is disabled as far as I can tell.  I use Webroot.

 

I ran Process Monitor as you suggested but this is what I get when I get the compile error:

 

 

Edited February 1 by RockWallaby
Image too small to see

[RockWallaby 1]

Damn, that image comes out small.  Edited the image - hopefully it's more usable.

 

[MrQNet 0]

I am having this same problem! only in Delphi 11.3,.

 

Updated Windows this week and am now having this annoying problem. The only way to clear the lock is to reboot. Hopefully another windows update will fix the issue, but can't wait for that!

 

Tracing my file thru Process Explorer tells me Explorer.exe is locking the file, even restarting explorer doesn't clear the lock. I am at my wits end trying to resolve this, who do we turn to? I can keep recompiling and all is well but as soon as I run the program  subsequent compiles fails with F2039 error.

 

I have tried different drives, simple programs ie 1 button to close the tiny program, but still fails.

 

Frustrating

 

[MrQNet 0]

Rockwallaby... did your OS update this week?

[RockWallaby 1]

46 minutes ago, MrQNet said:

Rockwallaby... did your OS update this week?

I had these two updates on January 10:

• 2024-01 Cumulative Update for Windows 11 Version 22H2 for x64-based Systems (KB5034123)
• 2024-01 Cumulative Update for .NET Framework 3.5 and 4.8.1 for Windows 11, version 22H2 for x64 (KB5033920)

My problems started after a Dell Firmware Update:

• Dell, Inc. - Firmware - 0.2.11.1

It may be just a coincidence though.  I'm talking with Dell Support right at this moment to find out what changes they made in the firmware update but they're pretty useless.
 

By the way, you can delete the compiled file by using <shift> <delete>.  Normal <delete> won't work.

 

 

[Vincent Parrett 750]

Is your machine on an active directory domain? If so it's possible a group policy was applied that changed your permissions. Have a look at the permissions on the output folder. 

[RockWallaby 1]

16 minutes ago, Vincent Parrett said:

Is your machine on an active directory domain? If so it's possible a group policy was applied that changed your permissions. Have a look at the permissions on the output folder. 

No, it's not.  Sorry.

[Vincent Parrett 750]

13 minutes ago, RockWallaby said:

No, it's not.  Sorry.

Ok, then my fallback answer for everything is 42 Antivirus - some av systems still do weird sh1t even when "disabled". Try adding explicit exclusions for your output folder for live. 

Also, it's still worth checking folder permissions, perhaps windows updates changed something. Where is the output folder?

[MrQNet 0]

.. By the way, you can delete the compiled file by using <shift> <delete>.  Normal <delete> won't work.

 

Thanks, Yes that works for me too!

[RockWallaby 1]

35 minutes ago, Vincent Parrett said:

Ok, then my fallback answer for everything is 42 Antivirus - some av systems still do weird sh1t even when "disabled". Try adding explicit exclusions for your output folder for live. 

Also, it's still worth checking folder permissions, perhaps windows updates changed something. Where is the output folder?

Ha ha, unfortunately 42 didn't help me in this case. 🙂  All of the projects are stored under D:\Projects and I added an exclusion for that and all sub-folders.  The Output folders are always under the projects' folder, eg. D:\Projects\MyProject\Win32\Debug (or D:\Projects\MyProject\Win32\Release).

 

I'll go check the permissions again.

[Kas Ob. 121]

10 hours ago, RockWallaby said:

I can't find many resources about USER_MAPPED_FILE, in fact there is near nothing on the internet , found this https://stackoverflow.com/questions/41844842/when-error-1224-error-user-mapped-file-occurs though not so helpful.

 

Anyway, to decode this situation using my own logic, the file is already being opened for mapping by another process, hence the BDS call to CreateFile is failing, and there is a few ways to catch the culprit redhanded.

 

we start with the easiest way to find the culprit :

1) grab Handle from https://learn.microsoft.com/en-us/sysinternals/downloads/handle 

2) put it some write permitted folder ( don't use any root directory like  C: \ or D:\ ...)

3) run cmd with Administrator rights (elevated) on that folder

4) run this command : handle64 > hlist.txt

5) open that hlist.txt file and search for your EXE name 

 

Now if we fortunate and things went as we wish for, then we expect to see is something like this, here the file i locked with mapping is 1.txt

 

Share with us to further discussion if discussion is needed, but in all cases we appreciate your finding !

 

Newer and updated guessing part: 

1) system protection for some reason has kicked in .

2) that folder or driver is shared and/or locked by some GoogleDrive (may be) or something similar, and remotely there is software is parsing or handling that file, it easily can be an AV on remote device !

3) Again that Webroot on your device might be is doing some shenanigans.

 

Don't forget to run handle.exe or handle64.exe with Administrator !

[Brandon Staggs 275]

19 hours ago, RockWallaby said:

As I said previously, nothing has changed on my computer.  At least I haven't installed, changed or uninstalled anything.  It just suddenly started happening after working fine for years.

We should all know better than to assume "nothing has changed" on our computers, especially over a period of "years." Unless you have Windows updates (and everything else) disabled, most definitely things have changed. A recent update to Windows trashed many of my file locations when it decided to start including a lot more locations in OneDrive file syncing, even without me knowingly allowing it to do so. I don't know if this applies to your situation, but it could, so I suggested it.

[Brian Evans 105]

Can try Process Monitor - Sysinternals | Microsoft Learn and check what is accessing it as you compile / run / close. Something must be holding something open. 

Edited February 2 by Brian Evans

[MrQNet 0]

RockWallaby.. are you using Webroot?

[RockWallaby 1]

19 hours ago, RockWallaby said:

Ha ha, unfortunately 42 didn't help me in this case. 🙂  All of the projects are stored under D:\Projects and I added an exclusion for that and all sub-folders.  The Output folders are always under the projects' folder, eg. D:\Projects\MyProject\Win32\Debug (or D:\Projects\MyProject\Win32\Release).

 

I'll go check the permissions again.

Checked the permissions and they were all good.

Edited February 2 by RockWallaby

[RockWallaby 1]

1 hour ago, MrQNet said:

RockWallaby.. are you using Webroot?

Yes, I am.

[MrQNet 0]

I am too! And I sent a support request to WR and they sent this reply..

 

Hello,

Thank you for bringing the issue you are experiencing to our attention. The Webroot Development team has been notified of this issue and is currently working on a resolution. We expect to address this issue in an upcoming software version release, which will be downloaded automatically to your device and installed when it is available.

Once the newer version has been installed, check to see if the issue you reported is still occurring. If it is, let us know and we will check the status of the issue. You may contact us by phone by clicking here and choosing the sales number for the location that works best for you, or online at support.webroot.com.

Thank you,

The Webroot Support Team

 

So I assume it's a WR issue in the end even tho' I turned all WR options off. Webroot updates their software in the backgound and you never know when it's updated. My version I am using is Webroot SecureAnywhere CE 4.1.

 

I don't know how to tell when a new version of WR is installed but will keep testing Iguess.