Hello,

this isn't technically a Lazarus issue but a gdb one, but maybe someone here (Sven?) has encountered this before and knows what to do. I think this is related to the discussion we had on #24908, and my lack of understanding back then...

Take this example program, compile with -Pi386 and execute on a 64bit Windows (Wow64, reproduced on 8.1 and 10). This might also apply to pure 32bit Windows, but I currently don't have any available to test.

program Project1;
uses Windows;
begin
  CloseHandle(1);
  WriteLn('Done');
end.

This will execute fine when called directly:

...\Temp>project1.exe
Done

But from gdb, Windows' internal use of exceptions confuses gdb and it doesn't continue properly:

(gdb) r
Starting program: ...\Temp\project1.exe
[New Thread 1444.0x1240]
gdb: unknown target exception 0xc0000008 at 0x7737c56c

Program received signal ?, Unknown signal.
0x7737c56c in ntdll!ZwClose () from C:\Windows\SYSTEM32\ntdll.dll (gdb) c
Continuing.
[Inferior 1 (process 1444) exited with code 030000000010]

This issue is not new, an explanation can be found in this 9 year old list reply: <https://sourceware.org/ml/gdb/2007-10/msg00162.html> In a nutshell, gdb passes an exception back to the application that was only intended as a hint for the debugger. It goes unhandled there (obiously) and Windows then kills the application. There was a patch that would have fixed the situation, but apparently that never landed
(<https://sourceware.org/ml/gdb-patches/2007-10/msg00502.html>).

Is there any way to "fix"/avoid this from our side? This currently completely breaks debugging on Wow64 in some situations... note that the example above is just a simple version, gdb chokes as soon as anyone in the current process throws an EXCEPTION_INVALID_HANDLE: drivers, codecs, ActiveX-objects, ...

I'd be grateful for any help,

Regards,

Sebastian