[workarounded] Windows 10 - loss of control over console

[sarcasm]

I'm using Pelles 8.00 (x64) under Win 10 (pro for x64) and have some strange behaviour during debugging:
Starting Debugging opens the console, so far, so good. Usually the IDE Window hides the console window at least partitially, so i grab it at the title bar by mouse and move it to a free place on the desktop. With this action the mouseponter sometimes "loses" the console window, which stays at the point of loss.
If this happens (which can be repeated for sure, but the timepoint is unpredictable when it happens). Up from then some GUI elements are blocked, too: Quick start bar + symbols, if it was not set to auto-hide (Tablet Mode), sometimes the Pelles IDE itself becomes unreachable by mouse, too.
To regain control in this case it works only by invoking the task manager via keyboard, switching to IDE process and ending the debugging session.

Already tried: reinstallation of Pelles C, changing the graphic card, another PC, absolute fresh win 10 installation in a virtual machine. Still same result.
Strange somehow , what should i  try next?

[TimoVJL]

It could be somekind of a ConHost problem in Windows 10?

Sometimes putting break-point to main function and single step over it helps. After that console is movable.

[sarcasm]

Nope, didn't help. Plus i've found other side effects:
For my tests i've used the world's most replicated loc printf("Hello world!");  three times, setting a breakpoint on the first one, singlestepping over it. Anyhow, the freezing can still be provoked locking the complete desktop.
Win+x key unlocks the desktop, so i can reactivate the IDE via taskbar but the console window stays unmovable until i make a further single step. Sometimes the console isn't redrawn (hello world- outputs missing).
Finally, when the program is ending, the con requests "Press any key to continue ..." - this freezes never, but has the same redraw error.

Still strange and i'm sorry to say that i only have Win10.

Any more hints for me to check?

[TimoVJL]

My Windows 10 Home don't behave exactly in same way.

If you develop 32-bit programs, 32-bit poide.exe works a bit better in Windows 10.
If console window position is the only problem, a fake replacement program for idespawn64.exe might help.
For testing the original idespawn64.exe should renamed in PellesC bin-folder and a fake version should be in same folder as a test program (or in bin folder).

EDIT: Another test with PellesC 8:
rename idespawn64.exe and copy idespawn.exe to idespawn64.exe
32-bit idespawn.exe size is 25 600 bytes and original idespawn64.exe 33 280 bytes.

This trick also helps debugging a 64-bit program in poide64.exe in Windows 8.x.
No more that from conhost.exe:

Code: [Select]

sub rsp,28
call 00000000A4178E30
add rsp,28

Inform us if this doesn't work or have side effect.

[sarcasm]

Hi TimoVJL, that really works! 
Now it's even possible to debug x64- programs without annoying con freeze.

Allright, it's a workaround, but to me it does what it should. 

Thank you very much!