1 ошибка cannot open output file debug untitled exe permission denied

On Windows 7 I was using Qt 5.12.6 with Qt Creator 4.10.2 IDE and compiling with MinGW 64-bit utilizing the provided qmake, on Windows 7. I ran into an interesting situation.

When attempting to compile and debug a project, Qt Creator started giving the following message

:-1: error: cannot open output file debugTestFlight.exe: Permission denied
collect2.exe:-1: error: error: ld returned 1 exit status

Assuming that the program somehow was not shut down correctly, I could not find any reference to the program using the task manager, so I attempted to see if it would run stand-alone, which just resulted in the following…

Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.

This appeared odd seeing as I have full administrative permissions and I should be the owner of the file. So I attempted to access the permissions of the file to see what exactly was going on by highlighting the file and taking the following steps…

1 Right clicked the file
2 Selected properties
3 Selected the security tab which then caused a new window to pop up with the following statement…

To continue, you must be an administrative user with permission to view this object’s security properties

4 Clicked Continue

A window then popped up displaying a message stating that I do not have permission to view the object’s security properties along with a section that should have displayed the owner information and another section with a list of users. However in the current owner section, it simply stated…

Unable to display current owner. To try taking ownership of the object select an account from the list, and then click OK.

5 There were two accounts in the list. Both of them were mine and they both had admin privileges. I attempted to change the owner using both accounts and each time a window popped up and sated…

Unable to set new owner on file name.
Access is denied

without any further explanation.

I’m somewhat confused on this one since I have full admin privileges and it doesn’t let me change, access, or even delete the file. I have run the Build->Clean All and Build->Run qmake options from the menu with out any effect on the outcome. So I rebuilt the whole program and attempted it again.

The rebuilt program compiled and ran just fine and did not exhibit any of the signs or problems experienced on prior attempts. When I checked the executable in the debug directory I was able to access the parameters and security settings of the file and I was listed as the owner. So after some minor coding changes, I checked the executable file in the debug directory again, and everything was as it should be. I felt it was fine to go ahead and attempt to compile it again.

Unfortunately, during the compile the same issues were reported by Qt Creator as with the prior build…

:-1: error: cannot open output file debugTestFlight.exe: Permission denied
collect2.exe:-1: error: error: ld returned 1 exit status

In addition to searching in the Task Manager and Process Explorer I’ve rebuilt this program several times, changed directories, scoured the operating system environment for anomalies, and shut down any other programs that were running. and yet I’m still getting the same results. I searched for and found a multitude of similar situations on several programming boards (including this one) but there have been no satisfactory solutions with the exception that some individuals seem to have found that turning on “Application Experience” in Windows seems to resolve the issue. Unfortunately, this appears to be a feature that is not in Windows 7. I’ve run out of things that I know to check for. I strongly suspect that this may be a problem minGW or maybe Windows, but if anyone has any insight on this issue, it would be highly appreciated.

I have occasionally come across a similar problem using Visual Studio in Windows 10, so I don’t think it is specifically a Qt Creator problem. What I surmise happens is that the build locks the output file and that this lock doesn’t get released. In VS and probably in Qt, builds can be multithreaded, so there could be a bug resulting in a race condition or other fault that sometimes keeps the lock from being properly released.

With Visual Studio, closing and restarting VS has often cleared things up. Sometimes it has taken a reboot if there is some dangling VS process left behind after closing it.

There is a new security feature that has recently been added to Windows 10, which prevents apps from writing to or changing files in certain «protected» directories without explicit permission, including Microsoft’s own programs, like Visual Studio and MS Office that are now blocked from updating the default options files in your App Data folders. Your choices are either to turn it off completely and risk a malware attack, or to go into Window security for every program you use, find out where it is trying to write, and add it to the list of allowed programs. It’s even worse with programs like OpenOffice, which consist of a driver program that fires off child programs to handle each specific document type. You have to add the driver and each of the child programs, individually and manually to the list. Major PITA. My solution has been to change the parameter directories to something I can control if possible.

Corny (6th December 2019)

Good morning Earth,

I had the same issue on my Windows 10 box, and the guilty was the antivirus : by disabling temporary my Kaspersky antivirus, I was able to successfully compile and run my Qt project.

Bonjour chez vous !

JPL

Yes. After this happened to me several times, I discovered that anti-virus software (Malwarebytes in my case) was incorrectly classifying the exe file as malware and was quarantining it. So the file would be written and as soon as the debugger would try to run it, the anti-virus software would delete it. I could watch the file appear in the output folder, then just as quickly it would disappear. For some reason, debug mode Qt apps seem to trigger anti-virus software occasionally.

The solution was to «white-list» the exe so Malwarebytes would ignore it. I don’t recommend totally disabling your anti-virus software, because you might forget to turn it back on after you have finished debugging.