|
|
Home » U++ TheIDE » U++ TheIDE: Compiling, Linking, Debugging of your packages » I keep getting the same "cannot open exe for writing" error...
I keep getting the same "cannot open exe for writing" error... [message #9919] |
Fri, 08 June 2007 16:22  |
blackbyrus
Messages: 1 Registered: June 2007
|
Junior Member |
|
|
Here's an example of the error:
LINK : fatal error LNK1168: cannot open C:\upp\out\MSC71.Debug_full.Gui\Hello.exe for writing
In this specific one, Hello.exe had already compiled 3 times before it suddenly stopped working.
I get it for my (very simple, straight from tutorial) programs, and for the already written example programs that came packaged with the IDE. Sometimes a program will compile a couple of times, I'll make a very minor change, then I will get that error, I change it back, and now it won't compile anymore. I'm confused as to what I may be doing to cause this.
|
|
|
|
|
|
|
|
Re: I keep getting the same "cannot open exe for writing" error... [message #50600 is a reply to message #50484] |
Sun, 25 November 2018 17:40   |
 |
peterh
Messages: 108 Registered: November 2018 Location: Germany
|
Experienced Member |
|
|
For me it happens after previous debugging.
(I am on Windows10 64 Bit)
It happens for me when I am using MSVC17 or MSVC17 64 Bit in TheIDE and only after debugging.
In the Windows Taskmanager it can be seen, that the previously debugged process is still attached to TheIDE.
If I choose "Debug" in the Windows Taskmanager then Windows tries to attach the VSstudio debugger.
Attaching VSStudio debugger fails.
There is an error message, which says "There is another debugger attached to this process, which is not configured to handle this kind of exception".
It seems to me, it happens, when the debugee was stopped and had some kind of exception during shutdown and this probably prevented the debugger from detaching.
These are just my observations. (And educated guesses) Hope this is useful.
I have no experience with windows programming, but have used debuggers on DOS and Linux some decades ago.
[Updated on: Sun, 25 November 2018 20:24] Report message to a moderator
|
|
|
Re: I keep getting the same "cannot open exe for writing" error... [message #50610 is a reply to message #50600] |
Mon, 26 November 2018 10:54   |
 |
mirek
Messages: 14255 Registered: November 2005
|
Ultimate Member |
|
|
peterh wrote on Sun, 25 November 2018 17:40For me it happens after previous debugging.
(I am on Windows10 64 Bit)
It happens for me when I am using MSVC17 or MSVC17 64 Bit in TheIDE and only after debugging.
In the Windows Taskmanager it can be seen, that the previously debugged process is still attached to TheIDE.
If I choose "Debug" in the Windows Taskmanager then Windows tries to attach the VSstudio debugger.
Attaching VSStudio debugger fails.
There is an error message, which says "There is another debugger attached to this process, which is not configured to handle this kind of exception".
It seems to me, it happens, when the debugee was stopped and had some kind of exception during shutdown and this probably prevented the debugger from detaching.
These are just my observations. (And educated guesses) Hope this is useful.
I have no experience with windows programming, but have used debuggers on DOS and Linux some decades ago.
OK, then it is "known issue". We are well aware about this, but have found not solution yet. It looks like Microsoft .dll we are using to get symbolic information from the .exe fails to close same handles to .exe.
For now, if I run into this, I simply restart theide.
If you want to try to resolve this, the critical code is in Pdb::Stop (ide/Debuggers/Pdb.cpp). Problem is that it works "most of time"...
|
|
|
Re: I keep getting the same "cannot open exe for writing" error... [message #50613 is a reply to message #50610] |
Mon, 26 November 2018 12:45   |
 |
peterh
Messages: 108 Registered: November 2018 Location: Germany
|
Experienced Member |
|
|
Yes, when I see the problem then I try to solve it, or at least look for a way to reproduce it.
I see this problem frequently, because I use the debugger frequently.
Not that I write software, but I work through the examples and if I dont understand something, then I use the debugger to see how stuff works.
I could try the tools from sysinternals to investigate this problem furter, when it happens.
My observation is, sometimes it doesnt happen and sometimes it happens frequently, with the debugee being substancially unchanged.
It is not reproducible, this could be a hint for uninitialized variables, dangling pointer or race condition.
If the problem is in the microsoft dll then only a quick'n dirty workaround would be possible:
Before the build starts, delete the target *.exe file.
Possibly the Windows API has a way to get the filehandle and close and delete the file? (I dont know this; this is just an unproven idea)
If this is not possible rename it and delete it at next start.
Possibly move the exe to temp then windows would delete it.
[Updated on: Mon, 26 November 2018 13:30] Report message to a moderator
|
|
|
|
Re: I keep getting the same "cannot open exe for writing" error... [message #50618 is a reply to message #50617] |
Tue, 27 November 2018 00:14   |
 |
koldo
Messages: 3432 Registered: August 2008
|
Senior Veteran |
|
|
Hello Peterh
Good find.
Quote:The TerminateProcess() systemcall is asynchronous and returns immediately, eventually before the process is actually terminated.
Also it kills all threads.
(If the documentation is correct) TerminateProcess() does not kill child processes.
To handle that Bazaar/Functions4U includes TerminateChildProcesses(). It kills all processes tree.
It may be dangerous, as it does not follow the proper killing order but, as using TerminateProcess() is a brute force process end, TerminateChildProcesses() just tries to do the same thing, but in depth.
Edit: Similar focus is used in PauseChildThreads() with surprising effectivity even for child GUI software.
Best regards
Iñaki
[Updated on: Tue, 27 November 2018 00:19] Report message to a moderator
|
|
|
Re: I keep getting the same "cannot open exe for writing" error... [message #50619 is a reply to message #50618] |
Tue, 27 November 2018 08:54   |
 |
peterh
Messages: 108 Registered: November 2018 Location: Germany
|
Experienced Member |
|
|
Then TerminateChildProcesses() might be a better solution if it doesnt block.
In any case terminating an unknown eventually buggy process which can have childprocesses, threads and pending IO can go wrong.
Cleanly terminating is without problems in simple cases and might be impossible in complicated cases.
Compromises are necessary. Terminating is always an emergency brake.
I must admit, I am unable to write this debugger and I value and respect your work.
I have only focussed to this problem and went through the code step by step and had an idea what to look for: uninitialized variables, dangling pointers, buffer overflows, race conditions.
And in this case it seems to be a race condition.
BTW, if there are childprocesses, then there is the question if it is good to terminate them. Possibly they can be terminated with the taskmanager or Sysinternals Process explorer or a debugger can been attached to them?
All the best
[Updated on: Tue, 27 November 2018 09:11] Report message to a moderator
|
|
|
|
|
Re: I keep getting the same "cannot open exe for writing" error... [message #50623 is a reply to message #50621] |
Tue, 27 November 2018 10:07   |
 |
peterh
Messages: 108 Registered: November 2018 Location: Germany
|
Experienced Member |
|
|
Thank you!
So this is in nightly build tomorrow?
I am going to test and report in the evening, when I am at home.
Dayover I am at Job and look occasionally into the forum.
My Job is not programming, but industrial electronics hardware.
My idea is this:
In normal cases termination should be quicker than some 100 milliseconds.
Only if there are problems like pending IO it would last longer.
I do not know if in this cases Windows waits or if it terminates the process in the hard way, leaving open serial ports, USB devices and Files behind. 
However the timeout in WaitForSingleObject() must have a meaning and nobody knows how the next version of Windows or other versions will handle this.
So, if a timeout happens there must be an unusual problem and only the user/programmer can know for the reason.
It is then questionable wether the termination would succeed and the user should be asked, when a timeout happens if he wants to wait, instead of closing the process-handle, possibly unsuccessful.
Inbetween he/she could use other system-tools to debug or ignore the problem and restart the IDE and possibly chooses to reboot afterwards.
We use hardware testprograms here.
Some of the devices we test are defective and have unforseeable problems. This is, why we test. 
We connect potentially defective devices to the USB Port and disconnect them, semiautomatically some hundreds a day.
I have often seen USB devices vanish after a crash and in this case there is no other choice than to reboot after such an event.
So if such a situation is encountered while debugging the test program, the debugger must leave the decision about closing a process handle after timeout to the debuggers user.
[Updated on: Tue, 27 November 2018 13:17] Report message to a moderator
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Apr 25 15:17:31 CEST 2025
Total time taken to generate the page: 0.03460 seconds
|
|
|