I was recently hit quite often by the "cannot create exe" error and was able to track it down to adb.exe keeping the file open. While I have no idea what adb (Android Debug Bridge) has to do with a plain Win32 application, I killed that process and changed the entry for adb in SDK Manager to an invalid file path. After that the problem seems to disappear. Can anyone with some spare time try to confirm this? I am reluctant to file a QP report for this without any backing from someone. XE8.1 btw.
I found that if I stop the application and delete the EXE in the debug / release (depending what I was working on), it resolved the issue. Still do not understand how this cannot be fixed after several releases.
ReplyDeleteI have same problem with XE8 update 1. Developing FMX application, with mobile preview (I don't know if this is important). After killing adb problem disappear. Do you create VCL or FMX?
ReplyDeleteI can confirm that adb.exe is loaded even if no Android projects in the project group for me as well. I've also had this problem before (VCL projects), but I can't say for sure if it was after I was doing some FMX tests.
ReplyDeleteJust trying to gather some conditions that make this happen. My project group contains one mobile project with Android target. The problem occurs even in a plain Win32 project, but only when I start with debugging.
ReplyDeleteRichard Baroniunas I noticed that deleting the exe solves it temporarily, but it is no cure on the long term. Actually I am trying to prepare a reproduceable test case to definitely get this fixed.
Weird! Re-enabling abd doesn't make the error appear. At least not immediately. Still investigating...
ReplyDeleteDid a cleanup of the project group and a reboot. No signs of adb.exe for my VCL only project list. Added a FMX multidevice project. adb.exe appeared before the first compilation - even if the default target platform is 32-bit Windows.
ReplyDeleteLeft the FMX project in the project group, made a VCL project active, compiled and ran. Stopped it, exited Delphi, killed adb.exe - restarted Delphi. adb.exe started too, even if the selected project in the project group was a VCL project.
ReplyDeleteSidenote: A bit unhealthy that adb is left running after exiting the IDE, IMO.
ReplyDeleteRemoved the Android target from the FMX project. Saved, exited, killed adb, restarted IDE. No adb.exe loaded.
ReplyDeleteSo - adb will follow any Android Targets in your project group - even if project is not active. Now the question is - when will it start meddling with your VCL builds?
ReplyDeleteIf anyone using TestInsight has an issue with adb.exe reappearing all the time (can only be the case for up to XE7 though because there is not yet an XE8 version ^^) - that is a TestInsight issue (related to specific logcat reporting for android targets). I just don't know if that is related to adb locking the file. I will fix that for 1.1
ReplyDeleteStefan Glienke Besides missing TestInsight for XE8, the issue did happen in XE8. So probably not directly related. On the other hand there are currently no reliable steps to reproduce it either.
ReplyDeleteUwe Raabe I just thought I mention it before someone else does ;)
ReplyDeleteDo not know that I had any FMX projects connected to my recent project group in XE7. but I find adm.exe is fired up :-(
ReplyDelete(All projects in group is to my rememberance VCL projects.)
(And no, i don't have testinsight installed at all)
I've had similar things without adb.exe in both various Delphi and Visual Studio versions where either bds.exe or devenv.exe keep the target locked. Process Explorer is your friend then. Never could reproduce it, but in Delphi it happens more often with x64 targets than with x86 targets.
ReplyDeleteI haven't seen abd.exe, but I do see this bug for VCL-only projects (so no Android in sight.) In my case, cleaning the project solves it, although it's a tad annoying to have to completely rebuild in order to run. Worse is that sometimes the fact that the IDE couldn't write to the EXE is not logged or shown as an error - i.e. compilation appears to entirely succeed, the IDE starts the process, etc - and it's only when you're debugging and puzzling over odd results that you realise the EXE does not reflect the code you wrote and apparently just compiled.
ReplyDeleteARGH.
Luckily this doesn't happen very often.
David Millington - I've seen that one. Win32 app, IDE running on Win64.
ReplyDeleteI wonder - can this problem and the dreaded "Debug process is already running." be related?
Lars Fosdal Win32 on Win64 OS (Win 7 Pro) too. I can't remember if it happened with a Win64 app on the same OS.
ReplyDeleteRe that message: I don't know... could be! Here's hoping someone at Emb is reading this thread and accumulating useful information ("Hmm, Win32 on Win7Pro64, let me examine that code path...")
I reported this to our QA team early this morning. Here is their reply:
ReplyDelete"Thank you for the heads up. Regarding this, there is a bug reported at https://quality.embarcadero.com/browse/RSP-11273. In that report there is no mention of the "cannot create exe" error. I will update the original report with Uwe's information and raise its priority."
David Intersimone Thanks, David, for stepping in here. I had seen this adb appearing in the task manager before, but couldn't relate it to the locked exe. But yesterday Process Explorer told me that the exe was held open by adb.exe. Restarting Delphi didn't help, but killing adb.exe did. I am still not sure how this may be related. As I said, it is not reproduceable yet.
ReplyDeleteAny report in this area is welcome, there is a significant number of apparent unrelated cases of external tools locking the EXE, and also the debugger itself. Very elusive to reproduce, which is the reason we haven't been able to offer a lot of help...
ReplyDeleteOK, some new findings. I disabled adb in the registry (the SDK Manager dialog doesn't allow that) and the virus scanner. When I start the project in debug mode Process Manager shows bds.exe holding two open handles for the exe. Closing the app normally closes both handles, but sometimes one handle stays open. Even with this one open handle I might be able to compile. After this happens and when I start the program in debug mode again, two new handles are created and one of them stays open after closing the app. I managed to get six open handles to the exe. Now I changed to another project in the project group, compiled and debugged and the switched back. Now when I compile I get the access error. After closing all handles to the exe hold by bds with Process Explorer I can compile again.
ReplyDeleteSomeone forgot their try/finally :P
ReplyDeleteGood we at least have this resource to discuss when others resources used to, fails or is up and down like good olde jojos :-)
ReplyDeleteThere is a tool under Codecentral that could help:
ReplyDeletehttp://cc.embarcadero.com/Item/30160