Hello all

I get very frequently this error.
The system is Windows 10 and compiler is VS 2017.
It is annoying as only way to avoid it is restarting TheIDE or changing exe name.
Thank you.

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.

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)

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.

So I have tried a quick patch to resolve this based on the new info. It is in the trunk.

Hi,

I did download nightly build 12584 this morning.
The sources included do not contain the updated code for Pdb::Stop()
So it is unclear to me if the binary has the updated code.

I tested with 12587.

The issue is not fixed.

In the past I would get a hang up when the process locked and I had to quit TheIDE.

Now, I get a message telling me that the binary can't be opened for writing. So I guess it is an improvement. The process can't be killed by windows manager and I need to shut down TheIDE.

A few months ago I tried everything to fix this but gave up. I was using WinAPI (WaitForSingleObject if I remember correctly) to wait for the process. Yet the process would not finish and TheIDE would hang forever.

			dword exitcode;
			int start = msecs();
			while(GetExitCodeProcess(hProcess, &exitcode) && exitcode == STILL_ACTIVE && msecs(start) < 3000)
				Sleep(1);

This behaves better than WaitForSingleObject since it won't lock forever, but I suppose testing GetExitCodeProcess after 3 seconds will still give an active result in the case where the exe can't be written too. Maybe that should be logged somewhere and shown in TheIDE?

There must be a more aggressive way o killing a process as a fail safe?

Perhaps we could try to add Exclamation after that if process is still active - at least that would show us that this is the problem.

<--- Finished in (-5371:-45.-1), exitcode: 0 --->

mirek wrote on Thu, 29 November 2018 13:23

Perhaps we could try to add Exclamation after that if process is still active - at least that would show us that this is the problem.

Yes please!

Also, since I updated, when running command line programs with Ctrl-F5, I get this lovely output message:
Quote:

<--- Finished in (-5371:-45.-1), exitcode: 0 --->

Then I did see, the Ide project had the flags "GUI" and no other.
So I recompiled Theide with flags "GUI MT", because I believe, it could be multithreaded.
Apparently this cured the problem for me. It did not happen again since 2 hours now.

Could be.
Otherwise the difference was drastic.
I had written "MT" into the compiler options.
Microsoft docs for VC 2015 say /MT will define the flag _MT and this will tell the linker to link the multithreaded libraries and/or DLLs
(I use VC2017)
Is this info outdated?