DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 52VATXrr1686885
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 52VATXrr1686885
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=f7PbxkvT
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org C6A8C3857358
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1743416970;
	bh=tg0eEqMpjMqK0ORCdXLqQBoGqFNZqGs7n0iKp7nf7xE=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	From;
	b=f7PbxkvTy9CeyYLtS34WpKsybHoCJ4a2d3cx915iKzRmmvze76PHU6GDMcvyN5NBv
	nnAgOWBrzajPeUPeyggXZbKQfXrSOvMgmGX372TF9i36EfXnfBJOUOq6webPjazlG/
	ry6J6PvZ4oLvz3KDPJRRZgm+fJ5jXVtDc1C6j2BU=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 44DD23858C53
Date:	Mon, 31 Mar 2025 12:29:06 +0200
To:	cygwin AT cygwin DOT com
Subject:	Re: Terminate handler not called for C++ Cygwin programs on Windows 11
Message-ID:	<Z-puchrLbdqnT9WU@calimero.vinschen.de>
Mail-Followup-To:	cygwin AT cygwin DOT com,
	"Joerg Markus (LBC)" <Markus DOT Joerg AT liebherr DOT com>
References:	<AS8P192MB199990984F1754C344740362F2AD2 AT AS8P192MB1999 DOT EURP192 DOT PROD DOT OUTLOOK DOT COM>
MIME-Version:	1.0
In-Reply-To:	<AS8P192MB199990984F1754C344740362F2AD2@AS8P192MB1999.EURP192.PROD.OUTLOOK.COM>
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	cygwin AT cygwin DOT com
Cc:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Errors-To:	cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 52VATXrr1686885

Hi Jörg,

On Mar 31 09:00, Joerg Markus (LBC) via Cygwin wrote:
> Hi,
> 
> a colleague and I are facing a problem with unhandled exceptions in
> our C++ programs in Cygwin.  The C++ standard guarantees, that
> std::terminate() shall be called for thrown exceptions, that are not
> caught [0].  Unfortunately for C++ applications compiled for Cygwin64
> running on recent Windows systems,  std::terminate_handler is never
> executed.
> 
> A minimal example for showing the non-standard conform behaviour can
> be found here [1]:
> 
> ```
> #include <cstdlib>
> #include <exception>
> #include <iostream>
>  
> int main()
> {
>     std::set_terminate([]()
>     {
>         std::cout << "Unhandled exception\n" << std::flush;
>         std::abort();
>     });
>     throw 1;
> }
> ```
> 
> In Cygwin64 on Windows 11, Windows Server 2022 and Windows Server 2025
> the above program doesn't print anything to stdout and exits with
> status code 0.  The expected behaviour would be a non-zero exit code
> and the above error message on stdout.
> 
> Windows 10 and Windows Server 2019 are not affected. As another data
> point, Cygwin 32bit on Windows Server 2022 works as well. We actually
> found this behaviour, while migrating some programs from Cygwin 32bit
> to 64bit.  I also disabled SEHOP, which had no effect.
> 
> My colleague started an investigation and traced the error back to a
> change in behaviour in RtlRaiseException() from ntdll.dll, that's
> where our investigation hit a wall.  Here is a thread [2], discussing
> a possibly related problem for some Windows applications, which
> apparently can be traced back to a change of behaviour in the
> SetUnhandledExceptionFilter API in Windows Server 2022.
> 
> That's all we know. It would be great, if this could be fixed on the
> Cygwin side. While some Windows programs seem to be affected as well,
> under Cygwin all C++ programs with unhandled exceptions are currently
> affected.

I tested this on W10 and W11 and, as you wrote, it works fine on W10 and
simply exits on W11.

I even tried to add a new unhandled exception handler, but this didn't
work either and I was just as stumped as you were.

But there's light at the end of the tunnel:

I ran this under GDB and it turns out that there's an interesting
difference.  When the throw is performed, we reach Cygwin's exception
handler.

On W10, EXCEPTION_RECORD::ExceptionFlags is 0.

On W11, EXCEPTION_RECORD::ExceptionFlags is 128, i.e.,
EXCEPTION_SOFTWARE_ORIGINATE.

However, our exception handler returns prematurely with
ExceptionContinueSearch if ExceptionFlags is non-0.

I patched our execption handler to exit prematurely only if any other
flag apart from EXCEPTION_SOFTWARE_ORIGINATE is set in ExceptionFlags,
and your testcase starts working on Windows 11.

Before:

$ ./throw
$

After:

$ ./throw
Unhandled exception
Abort

just as on W10.

I just pushed the patch.  Please test the next test release
cygwin-3.7.0-0.27.g0d73c040676a.


Thanks,
Corinna

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -