Does anyone have issues with XE7 (for it happened with and without update 1) where you are unable to compile or clean because somehow the debugger did not properly release the binary? (compiler cannot create the binary and the clean says it does not have access to the file).

Does anyone have issues with XE7 (for it happened with and without update 1) where you are unable to compile or clean because somehow the debugger did not properly release the binary? (compiler cannot create the binary and the clean says it does not have access to the file).
Only possibility I have right now is to restart the IDE a dozen times each day. Since I did not find a pattern when it happens I am looking for more people experiencing this problem. This is on Windows 8.1.

Comments

  1. I have the same issue with XE6. And other (Out of Memory) in the IDE during build.

    ReplyDelete
  2. XE does it as well, very rarely, and with no repeatable pattern as well.

    ReplyDelete
  3. Eric Grange I never experienced this before but with XE7 it does it after like every fifth debugging session.
    Sometimes there is another (I guess related) error where it seems to start the debugger but then completely hangs and does not react anymore (have to kill it with task manager)

    ReplyDelete
  4. I've run into a similar problem (binaries not released) when using Build Dependencies, but this was in XE5. I disabled the dependencies and the problem went away.

    ReplyDelete
  5. Martijn Coppoolse It happens with simple button1 applications. So nothing fancy.

    ReplyDelete
  6. Stefan Glienke Hm... No, I haven't run into trouble with that, so far. Not in XE7 or XE5 anyway.

    ReplyDelete
  7. Yes. And if I am not mistaken this problem for me could be solved by setting HKEY_CURRENT_USER\Software\Embarcadero\BDS\15.0\Debugging\Embarcadero Debuggers\Evaluators\comp32x.dll to -1
    But that is probably not really the solution you are looking for - I guess.

    ReplyDelete
  8. Ah - and then I experienced Antivirus Application induced problems.

    ReplyDelete
  9. It happens sometimes in Appmethod 1.15 (XE7). My solution was to delete the .exe. I guess it has to do with target switching.

    ReplyDelete
  10. Gustav Schubert No target switching here and also deleting the exe does not work because the bds.exe still has a file handle open. So I either restart the IDE or i use process explorer to close that handle manually.

    ReplyDelete
  11. Stefan Glienke  Deleting the exe worked for me, perhaps because I have switched targets?

    ReplyDelete
  12. Stefan Glienke​, it happened to me also but I can't say exactly under which conditions (and also with versions previous than XE7)... I know a simple workaround is to rename the executable and an easy way to do that from the IDE is to rename the project in the Project Manager (then you can revert back to the original one). I think I saw someone doing this in a webinar or in a CodeRage session but can't remember who exactly...

    ReplyDelete
  13. It happens to me all the time as well, but have to delete the binary every time prior to compiling.  Restarting the IDE fix it, but not for long.  Also running on Windows 8.1.

    ReplyDelete
  14. Happens all the time, although slightly less often under Update 1.  I am not 100% sure, but it seems to happen more often if I end - normally - the application being debugged - than when I just use Ctrl-F2 to do a program reset, and debug again.

    I can't say for sure - but it appears that it happens more often when debugging something that is windows message triggered.

    Now and then I have to do like Steve van Niekerk and restart the IDE to get rid of a "stuck" debug .exe.

    Also on Windows 8.1.

    ReplyDelete
  15. Happens here as well. Small projects, debug a couple of times, and out of memory or cannot create binary. After a couple of searches I also get out-of-memory (on a 16GB win7 64 bit platform and a win8.1 64 bit platform). This has been disturbing since XE3, but happening more often with XE7.

    ReplyDelete
  16. XE2 does it and i can not build the whole group because of an out of memory. So both problems...

    ReplyDelete
  17. XE3 does it all the time VCL or console apps (random behavior), something I noticed is it only happening with projects created with XE3, I have some projects migrated from Delphi 2007 and never happens on them.

    ReplyDelete
  18. Beside the obvious culprit (anti virus, anti malware in the OS, and any other background process that hooks to the executable), there might be several "debug termination issues" that depend on the application, other that are purely on the debugger, and even (in case of high memory usage) errors in cleaning up the unit cache used by the debugger. We are working on some of these issues, but anything reproducible can help. Also version of Windows (beside version of RAD) might matter.

    ReplyDelete
  19. Windows 8.1 64-bit
    MS System Center Endpoint Protection (AV)
    RAD Studio Enterprise XE7 Update 1 (started with -noparser option)
    Eurekalog 7.1.1.0 Pro
    TMS Component Pack
    No other third party IDE plugins

    ReplyDelete
  20. Was rear for me in the past but have struck it often under XE7. Delete exe is not possible.  Environment is Win7 64 bit VM, XE7 Update 1. I have disabled and deleted the Avast software to rule that out, so will need to do some more testing.

    ReplyDelete
  21. Windows 7 64 bits VM, Delphi XE3 Update 2, CNPack Wizards, GExperts, IDEFixPack, no antivirus

    ReplyDelete
  22. Wow, I thought I was alone on this one. I am on Win7 and XE7, but XE5 did it as well, and I get it often. When I try and build, I get an exception that says it can't create the EXE. I am though, able to switch to Explorer and delete the EXE, then the build works fine. So I always questioned why I was able to delete the file, but Delphi wasn't? I can't say if it happens only when I exit my program normally, or when I use ALT-F2. I'll post again when I have more info.
    I do use AVG Anti-Virus and I think I have tried disabling it to no avail.

    All my development is done in VMWare as well.

    ReplyDelete
  23. XE2. I have this problem when my EXE is sent to a network-drive. The EXE is locked by the IDE. I never identified how or why, but it was resolved when I sent it to the local drive and my build scripts utilized a copy of the file first.

    ReplyDelete
  24. Vin Colgin
    I thought the network drive / VM shared drive issue had been resolved, I vaguely remember a setting somewhere for this at the time, can't remember if it was a Win7 setting or VM related.

    ReplyDelete
  25. Brett Wilton thanks. Yes, I'm using VMworkstation + Win7. But I've never found a solution to it in Googling. Sorry if this derails the current issue, it sounds the same.

    ReplyDelete
  26. Vin Colgin No need to apologize, I think its a possible issue and could be related.  I remember I had to do the same in compiling to local drive with network share being slow and locking but have been using VM share for a while now without the same issues, till XE7 I've noticed the exe locking again.

    ReplyDelete
  27. I am quite sure i had locking problems on a local drive using XE2, but that was when compiling 64-bit. I haven't done much 64-bit lately, though. I use VirtualBox with a mapped shared drive and do not have locking problems compiling 32-bit.

    Also, for XE2, the out of memory problem does not seem to relate to network output folders. Rather on source complexity. I have a pascal-written SSL library being compiled into the executables and i suspect the complexity is the culprit.

    ReplyDelete
  28. I have had some weird things happen before and after Update 1 including this issue once. Bill Meyer​ You seen anything?

    ReplyDelete
  29. I have this in XE - but just with particular apps, not all

    ReplyDelete
  30. Kerry Sanders I have not accumulated sufficient time yet, but will contact you later on YM.

    ReplyDelete
  31. With avast uninstalled I'm still getting this issue, having weird random debug display as well requiring restart.  A bit frustrating when you get led down the garden path to find its the debugger misleading you.

    ReplyDelete
  32. Russell Weetch I have never seen this on Delphi XE Pro in all the years I've been using it. Maybe it somehow depends on the OS version? Almost all my work with Delphi is in 32-bit Windows XP SP3 running in VMware workstation on a Linux Mint host machine, with complete DevExpress+RemObjects+UniDAC+FastReport suites, no antivirus.

    ReplyDelete
  33. I had the same problem myself and found out, accidentally, something useful (?)

    When I have this issue is always because I have Windows Explorer open AND showing the folder where the application .exe I am compiling is.
    I delete the application .exe, move Windows Explorer to another folder (or close it) and the issue doesn't come back any more.

    I have XE2 only so I cannot verify on other compilers.
     I have Windows 7

    ReplyDelete
  34. For me this issue was related to Raize Components; uninstalling Raize Components resolved this issue on my system.

    ReplyDelete

Post a Comment