Aren't Windows System Error popups meant to be disabled in Cygwin?

Aren't Windows System Error popups meant to be disabled in Cygwin?

[David Allsopp]

Starting with this very trivial C program:

#include <stdio.h>
#include <zstd.h>

int main(void) {
  printf("Zstandard v%d\n", ZSTD_versionNumber());
}

and compiling with

x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd

when I then run ./test.exe, I get the Windows critical-error-handler
dialog stating "The code execution cannot proceed because
libzstd-1.dll was not found. Reinstalling the program may fix this
problem."

My question is not how to fix the problem (I'm well aware of that),
but rather why that message is being displayed at all, and is it a bug
in Cygwin somewhere? All I could find Googling was previous
suggestions that Cygwin routinely calls SetErrorMode with, amongst
other things, SEM_FAILCRITICALERRORS with the intention of suppressing
this dialog.

Is that correct, and if so is this just me? :o)

Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
I also get the same popup if I run C:\cygwin64\bin\sh -c
"/cygdrive/c/path/to/test" either from a Command Prompt or even from
"Start -> Run". Running this via "sh" called from a non-Cygwin process
(itself invoked from a Command Prompt) which has also called
SetErrorMode is how I hit this.

Thanks!


David

Re: Aren't Windows System Error popups meant to be disabled in Cygwin?

[René Berber]

On 1/31/2024 7:40 AM, David Allsopp via Cygwin wrote:

> Starting with this very trivial C program:
> 
> #include <stdio.h>
> #include <zstd.h>
> 
> int main(void) {
>    printf("Zstandard v%d\n", ZSTD_versionNumber());
> }
> 
> and compiling with
> 
> x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
> 
> when I then run ./test.exe, I get the Windows critical-error-handler
> dialog stating "The code execution cannot proceed because
> libzstd-1.dll was not found. Reinstalling the program may fix this
> problem."
[snip]

x86_64-w64-mingw32-gcc is a cross compiler, a.k.a. the Mingw compiler, 
not Cygwin's gcc.

It is quite correct for a cross compiler meant to produce Windows 
executables to do what you are seeing.  The executable is independent of 
Cygwin, i.e. doesn't use the Cygwin dll.
-- 
RB

Re: Aren't Windows System Error popups meant to be disabled in Cygwin?

[marco atzeri]

On Wed, Jan 31, 2024 at 2:41 PM David Allsopp via Cygwin  wrote:
>
> Starting with this very trivial C program:
>
> #include <stdio.h>
> #include <zstd.h>
>
> int main(void) {
>   printf("Zstandard v%d\n", ZSTD_versionNumber());
> }
>
> and compiling with
>
> x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
>
> when I then run ./test.exe, I get the Windows critical-error-handler
> dialog stating "The code execution cannot proceed because
> libzstd-1.dll was not found. Reinstalling the program may fix this
> problem."
>
> My question is not how to fix the problem (I'm well aware of that),
> but rather why that message is being displayed at all, and is it a bug
> in Cygwin somewhere? All I could find Googling was previous
> suggestions that Cygwin routinely calls SetErrorMode with, amongst
> other things, SEM_FAILCRITICALERRORS with the intention of suppressing
> this dialog.
>
> Is that correct, and if so is this just me? :o)
>
> Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
> I also get the same popup if I run C:\cygwin64\bin\sh -c
> "/cygdrive/c/path/to/test" either from a Command Prompt or even from
> "Start -> Run". Running this via "sh" called from a non-Cygwin process
> (itself invoked from a Command Prompt) which has also called
> SetErrorMode is how I hit this.
>
> Thanks!
>
>
> David
>

x86_64-w64-mingw32-gcc produces a Windows program, why Cygwin should
be involved in the execution ?

Re: Aren't Windows System Error popups meant to be disabled in Cygwin?

[Brian Inglis]

On 2024-01-31 06:40, David Allsopp via Cygwin wrote:
> Starting with this very trivial C program:
> 
> #include <stdio.h>
> #include <zstd.h>
> 
> int main(void) {
>    printf("Zstandard v%d\n", ZSTD_versionNumber());
> }
> 
> and compiling with
> 
> x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
> 
> when I then run ./test.exe, I get the Windows critical-error-handler
> dialog stating "The code execution cannot proceed because
> libzstd-1.dll was not found. Reinstalling the program may fix this
> problem."
> 
> My question is not how to fix the problem (I'm well aware of that),
> but rather why that message is being displayed at all, and is it a bug
> in Cygwin somewhere? All I could find Googling was previous
> suggestions that Cygwin routinely calls SetErrorMode with, amongst
> other things, SEM_FAILCRITICALERRORS with the intention of suppressing
> this dialog.
> 
> Is that correct, and if so is this just me? :o)
> 
> Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
> I also get the same popup if I run C:\cygwin64\bin\sh -c
> "/cygdrive/c/path/to/test" either from a Command Prompt or even from
> "Start -> Run". Running this via "sh" called from a non-Cygwin process
> (itself invoked from a Command Prompt) which has also called
> SetErrorMode is how I hit this.

Better to let you know that there is a problem, and what the problem is, so you 
can fix it!
I have spent hours trying to track down initialization failures, when daemons 
just ignored that a library they needed was not found or loaded!

Install the following package:

$ cygcheck -f /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libzstd-1.dll
mingw64-x86_64-zstd-1.5.5-1
-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: Aren't Windows System Error popups meant to be disabled in Cygwin?

[David Allsopp]

On Wed, 31 Jan 2024 at 22:27, Brian Inglis via Cygwin <cygwin@cygwin.com> wrote:
>
> On 2024-01-31 06:40, David Allsopp via Cygwin wrote:
> > Starting with this very trivial C program:
> >
> > #include <stdio.h>
> > #include <zstd.h>
> >
> > int main(void) {
> >    printf("Zstandard v%d\n", ZSTD_versionNumber());
> > }
> >
> > and compiling with
> >
> > x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
> >
> > when I then run ./test.exe, I get the Windows critical-error-handler
> > dialog stating "The code execution cannot proceed because
> > libzstd-1.dll was not found. Reinstalling the program may fix this
> > problem."
> >
> > My question is not how to fix the problem (I'm well aware of that),
> > but rather why that message is being displayed at all, and is it a bug
> > in Cygwin somewhere? All I could find Googling was previous
> > suggestions that Cygwin routinely calls SetErrorMode with, amongst
> > other things, SEM_FAILCRITICALERRORS with the intention of suppressing
> > this dialog.
> >
> > Is that correct, and if so is this just me? :o)
> >
> > Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
> > I also get the same popup if I run C:\cygwin64\bin\sh -c
> > "/cygdrive/c/path/to/test" either from a Command Prompt or even from
> > "Start -> Run". Running this via "sh" called from a non-Cygwin process
> > (itself invoked from a Command Prompt) which has also called
> > SetErrorMode is how I hit this.
>
> Better to let you know that there is a problem, and what the problem is, so you
> can fix it!

Thank you, but no - as I made clear by:

> My question is not how to fix the problem (I'm well aware of that)

I'm fully aware what has caused the issue to arise, and how to fix it
- that's not the issue. The problem is that according to previous
messages, and the Cygwin code, my impression was that mintty / bash /
sh (*Cygwin* programs) calling this executable should be returning an
exit code here, not freezing on a message dialog. The problem appears
to be a bug in the Cygwin DLL, and from previous messages on the list,
my question is whether it's a regression, and can be fixed.

The reason it's a problem is, say, a script _in Cygwin_ which is
handed a command to run, runs it, and is then completely blocked by
that popup dialog. It's the responsibility of the _caller_ (a Cygwin
program) to indicate the mode in which a program is executed - the
message box may be owned by the program called, but it's caused by it
being loaded, before it has a chance to run any code.

My understanding, based on this line:

https://github.com/cygwin/cygwin/blob/main/winsup/cygwin/dcrt0.cc#L721
in dll_crt0_0

is that Cygwin executables (in this case mintty / bash / sh, etc.)
should be running with SEM_FAILCRITICALERRORS enabled, following the
best practice recommendations in
https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode
and that that setting should be correctly inherited by processes they
call (including non-Cygwin ones).

Some ancient history, reporting my same issue in 2004:
https://cygwin.com/pipermail/cygwin/2004-March/115553.html and this
thread from 2006
https://cygwin.com/pipermail/cygwin/2006-August/150038.html strongly
indicating that that line dcrt0.cc is there precisely to stop this
popup.

Thanks,


David

Re: Aren't Windows System Error popups meant to be disabled in Cygwin?

[David Allsopp]

> x86_64-w64-mingw32-gcc produces a Windows program, why Cygwin should
> be involved in the execution ?

I perhaps should have made that crystal clear - in running "./test",
I'm invoking that excecutable _from_ a Cygwin program (in this case
mintty / bash / sh), so Cygwin is very much involved - it's the
caller.

In the actual problem which hit this, I have a non-Cygwin executable
which has called SetErrorMode(SEM_FAILCRITICALERRORS). If that program
calls test, there is no popup displayed. However, it also calls
Cygwin's sh and _that_ executes that program too, so something like
"C:\cygwin64\bin\sh -c "./test.exe | sed ..." but then the popup error
message appears. So somewhere along the line, Cygwin appears to be
resetting the system error mode, and that appears contrary to previous
(old) messages on the subject.

Thanks,


David

Re: Aren't Windows System Error popups meant to be disabled in Cygwin?

[Corinna Vinschen]

On Feb  1 08:22, David Allsopp via Cygwin wrote:
> > x86_64-w64-mingw32-gcc produces a Windows program, why Cygwin should
> > be involved in the execution ?
> 
> I perhaps should have made that crystal clear - in running "./test",
> I'm invoking that excecutable _from_ a Cygwin program (in this case
> mintty / bash / sh), so Cygwin is very much involved - it's the
> caller.
> 
> In the actual problem which hit this, I have a non-Cygwin executable
> which has called SetErrorMode(SEM_FAILCRITICALERRORS). If that program
> calls test, there is no popup displayed. However, it also calls
> Cygwin's sh and _that_ executes that program too, so something like
> "C:\cygwin64\bin\sh -c "./test.exe | sed ..." but then the popup error
> message appears. So somewhere along the line, Cygwin appears to be
> resetting the system error mode, and that appears contrary to previous
> (old) messages on the subject.

The behaviour changed in 2020

https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912

not without a discussion

https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html


Corinna

Re: Aren't Windows System Error popups meant to be disabled in Cygwin?

[Brian Inglis]

On 2024-02-01 01:18, David Allsopp via Cygwin wrote:
> On Wed, 31 Jan 2024 at 22:27, Brian Inglis via Cygwin wrote:
>> On 2024-01-31 06:40, David Allsopp via Cygwin wrote:
>>> Starting with this very trivial C program:
>>>
>>> #include <stdio.h>
>>> #include <zstd.h>
>>>
>>> int main(void) {
>>>     printf("Zstandard v%d\n", ZSTD_versionNumber());
>>> }
>>>
>>> and compiling with
>>>
>>> x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
>>>
>>> when I then run ./test.exe, I get the Windows critical-error-handler
>>> dialog stating "The code execution cannot proceed because
>>> libzstd-1.dll was not found. Reinstalling the program may fix this
>>> problem."
>>>
>>> My question is not how to fix the problem (I'm well aware of that),
>>> but rather why that message is being displayed at all, and is it a bug
>>> in Cygwin somewhere? All I could find Googling was previous
>>> suggestions that Cygwin routinely calls SetErrorMode with, amongst
>>> other things, SEM_FAILCRITICALERRORS with the intention of suppressing
>>> this dialog.
>>>
>>> Is that correct, and if so is this just me? :o)
>>>
>>> Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
>>> I also get the same popup if I run C:\cygwin64\bin\sh -c
>>> "/cygdrive/c/path/to/test" either from a Command Prompt or even from
>>> "Start -> Run". Running this via "sh" called from a non-Cygwin process
>>> (itself invoked from a Command Prompt) which has also called
>>> SetErrorMode is how I hit this.
>>
>> Better to let you know that there is a problem, and what the problem is, so you
>> can fix it!
> 
> Thank you, but no - as I made clear by:
> 
>> My question is not how to fix the problem (I'm well aware of that)
> 
> I'm fully aware what has caused the issue to arise, and how to fix it
> - that's not the issue. The problem is that according to previous
> messages, and the Cygwin code, my impression was that mintty / bash /
> sh (*Cygwin* programs) calling this executable should be returning an
> exit code here, not freezing on a message dialog. The problem appears
> to be a bug in the Cygwin DLL, and from previous messages on the list,
> my question is whether it's a regression, and can be fixed.
> 
> The reason it's a problem is, say, a script _in Cygwin_ which is
> handed a command to run, runs it, and is then completely blocked by
> that popup dialog. It's the responsibility of the _caller_ (a Cygwin
> program) to indicate the mode in which a program is executed - the
> message box may be owned by the program called, but it's caused by it
> being loaded, before it has a chance to run any code.
> 
> My understanding, based on this line:
> 
> https://github.com/cygwin/cygwin/blob/main/winsup/cygwin/dcrt0.cc#L721
> in dll_crt0_0
> 
> is that Cygwin executables (in this case mintty / bash / sh, etc.)
> should be running with SEM_FAILCRITICALERRORS enabled, following the
> best practice recommendations in
> https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode
> and that that setting should be correctly inherited by processes they
> call (including non-Cygwin ones).
> 
> Some ancient history, reporting my same issue in 2004:
> https://cygwin.com/pipermail/cygwin/2004-March/115553.html and this
> thread from 2006
> https://cygwin.com/pipermail/cygwin/2006-August/150038.html strongly
> indicating that that line dcrt0.cc is there precisely to stop this
> popup.

I do not see the problem if a native MS Windows program is not properly 
installed with native MS Windows library dependencies and MS Windows displays a 
popup to inform the user of the missing dependency.
Developer/maintainer/packager/distributor defects are never a downstream issue, 
they need to be addressed by the party who caused the failure!

There seems to be a conflict here with some native MS Windows program users 
wanting those native MS Windows programs to be able start a debugger and others 
wanting a CLI failure message.

ISTM if native MS Windows programs want specific native MS Windows behaviour, 
they should set that up before, at, or shortly after startup, as Cygwin does for 
its own programs, not rely on a foreign invoker doing so for them.

Could those native MS Windows programs not be run from a native MS Windows shell 
or wrapper script to ensure the desired behaviour?

Or just do not run native MS Windows programs, and find or build a Cygwin script 
or program to perform the desired function: that's the Cygwin way to avoid 
native MS Windows issues! ;^>

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[David Allsopp]

On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
<cygwin@cygwin.com> wrote:
>
> The behaviour changed in 2020
>
> https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912
>
> not without a discussion
>
> https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html

Aha, thank you! (congrats on the 3.5 release, in passing, btw).
Definitely not a regression, then (subject edited).

However, this patch came from MSYS2, and subsequently they seem to
have found it problematic for the same reason as me
(https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624)
and have just recently reintroduced the flag
(https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50)
to control it.

The reasoning in
https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as
valid now as it did in 2006.

Is it possible to revisit having the flag, or even just reverting the behaviour?

FWIW, it's been "hurting" us over in OCaml-land since zstd support was
added roughly a year ago - configure can tell us that mingw-w64's zstd
is available, but woe betide us if we run the test program to see if
it actually works, but the user forgot to add the sys-root into PATH,
because at that point the CI system is down...

Thanks,


David

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen]

On Feb  2 09:43, David Allsopp via Cygwin wrote:
> On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
> <cygwin@cygwin.com> wrote:
> >
> > The behaviour changed in 2020
> >
> > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912
> >
> > not without a discussion
> >
> > https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html
> 
> Aha, thank you! (congrats on the 3.5 release, in passing, btw).
> Definitely not a regression, then (subject edited).
> 
> However, this patch came from MSYS2, and subsequently they seem to
> have found it problematic for the same reason as me
> (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624)
> and have just recently reintroduced the flag
> (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50)
> to control it.
> 
> The reasoning in
> https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as
> valid now as it did in 2006.
> 
> Is it possible to revisit having the flag, or even just reverting the behaviour?
> 
> FWIW, it's been "hurting" us over in OCaml-land since zstd support was
> added roughly a year ago - configure can tell us that mingw-w64's zstd
> is available, but woe betide us if we run the test program to see if
> it actually works, but the user forgot to add the sys-root into PATH,
> because at that point the CI system is down...

I'm sympathetic, and personally I would prefer to revert the patch and
stick to SEM_FAILCRITICALERRORS by default.

The question is this: Why does, apparently, everybody expect Cygwin to
do the "right thing", with different definitions of "right", when in
fact the executable in question can easily call SetErrorMode by itself?


Corinna

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Jon Turney]

On 02/02/2024 12:55, Corinna Vinschen via Cygwin wrote:
> On Feb  2 09:43, David Allsopp via Cygwin wrote:
>> On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
>> <cygwin@cygwin.com> wrote:
>>>
>>> The behaviour changed in 2020
>>>
>>> https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912
>>>
>>> not without a discussion
>>>
>>> https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html
>>
>> Aha, thank you! (congrats on the 3.5 release, in passing, btw).
>> Definitely not a regression, then (subject edited).
>>
>> However, this patch came from MSYS2, and subsequently they seem to
>> have found it problematic for the same reason as me
>> (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624)
>> and have just recently reintroduced the flag
>> (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50)
>> to control it.
>>
>> The reasoning in
>> https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as
>> valid now as it did in 2006.
>>
>> Is it possible to revisit having the flag, or even just reverting the behaviour?
>>
>> FWIW, it's been "hurting" us over in OCaml-land since zstd support was
>> added roughly a year ago - configure can tell us that mingw-w64's zstd
>> is available, but woe betide us if we run the test program to see if
>> it actually works, but the user forgot to add the sys-root into PATH,
>> because at that point the CI system is down...
> 
> I'm sympathetic, and personally I would prefer to revert the patch and
> stick to SEM_FAILCRITICALERRORS by default.
> 
> The question is this: Why does, apparently, everybody expect Cygwin to
> do the "right thing", with different definitions of "right", when in
> fact the executable in question can easily call SetErrorMode by itself?

Yeah, if cygwin wasn't involved in the process ancestry, how would you 
get the behaviour you want?

I guess perhaps what's needed here is a command-wrapper tool like 'nice' 
or 'env' which lets you run a command with the error-handling mode you want.

But that must already exist for Windows, right? :)

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[David Allsopp]

On Fri, 2 Feb 2024 at 12:55, Corinna Vinschen via Cygwin wrote:
> On Feb  2 09:43, David Allsopp via Cygwin wrote:
> > On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
> > <cygwin@cygwin.com> wrote:
> > >
> > > The behaviour changed in 2020
> > >
> > > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912
> > >
> > > not without a discussion
> > >
> > > https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html
> >
> > Aha, thank you! (congrats on the 3.5 release, in passing, btw).
> > Definitely not a regression, then (subject edited).
> >
> > However, this patch came from MSYS2, and subsequently they seem to
> > have found it problematic for the same reason as me
> > (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624)
> > and have just recently reintroduced the flag
> > (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50)
> > to control it.
> >
> > The reasoning in
> > https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as
> > valid now as it did in 2006.
> >
> > Is it possible to revisit having the flag, or even just reverting the behaviour?
> >
> > FWIW, it's been "hurting" us over in OCaml-land since zstd support was
> > added roughly a year ago - configure can tell us that mingw-w64's zstd
> > is available, but woe betide us if we run the test program to see if
> > it actually works, but the user forgot to add the sys-root into PATH,
> > because at that point the CI system is down...
>
> I'm sympathetic, and personally I would prefer to revert the patch and
> stick to SEM_FAILCRITICALERRORS by default.
>
> The question is this: Why does, apparently, everybody expect Cygwin to
> do the "right thing", with different definitions of "right", when in
> fact the executable in question can easily call SetErrorMode by itself?

The executable can't, though (at least, I'm not aware that it can)?
The DLL not found case is being triggered by the loader, before the
entrypoint code is running?

I did have a look to see if there are manifest flags or some such
which can be set to indicate this, but it does seem to be the
responsibility of the caller, coupled with a "best practice"
recommendation on MSDN to call SetErrorMode (as Cygwin is of course
doing).

The whole system with it feels like unfortunate Windows legacy, but I
guess the behaviour vastly predates Event Viewer, etc., and slightly
better (and non-blocking) ways of reporting loader errors. Perils of a
nearly 40 year old API, if not OS <shrugs>

Thanks,


David

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[David Allsopp]

Jon Turney via Cygwin wrote:

> > I'm sympathetic, and personally I would prefer to revert the patch and
> > stick to SEM_FAILCRITICALERRORS by default.
> >
> > The question is this: Why does, apparently, everybody expect Cygwin to
> > do the "right thing", with different definitions of "right", when in
> > fact the executable in question can easily call SetErrorMode by itself?
>
> Yeah, if cygwin wasn't involved in the process ancestry, how would you
> get the behaviour you want?

Ah, but that's how I hit this (and started digging further) -
precisely because the non-Cygwin program I'm using _has_ called
SetErrorMode and its direct calls to the faulty program _are_ doing
what's wanted (no popup dialog) but the calls which happen via Cygwin
are then torching that preference.

Not really suggesting it be done this way (it feels more complicated
than just reverting the change), but in some ways perhaps Cygwin
should be using GetErrorMode on startup and instead of not inheriting
it, ensuring that it sets whatever it received? i.e. just before the
call to CreateProcess for a non-Cygwin binary, Cygwin restores the
error mode (for that thread only) to the value read at startup, calls
CreateProcess and then sets the error mode back.

To explain in the context of the actual call chain:
- I have opam.exe (compiled with mingw-w64), which is calling
SetErrorMode in main
- It's calling ocamlc.exe (in PATH) which requires the zstd DLL, but
that has not been put in PATH
- A direct call - not via Cygwin - to ocamlc -vnum therefore returns
an exit code
- Another call, already there from the Unix side, instead does sh -c
"ocamlc -config | sed ......." but Cygwin has then _removed_ the
calling applications preference

Thanks,


David

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen]

On Feb  2 13:35, David Allsopp via Cygwin wrote:
> Jon Turney via Cygwin wrote:
> 
> > > I'm sympathetic, and personally I would prefer to revert the patch and
> > > stick to SEM_FAILCRITICALERRORS by default.
> > >
> > > The question is this: Why does, apparently, everybody expect Cygwin to
> > > do the "right thing", with different definitions of "right", when in
> > > fact the executable in question can easily call SetErrorMode by itself?
> >
> > Yeah, if cygwin wasn't involved in the process ancestry, how would you
> > get the behaviour you want?
> 
> Ah, but that's how I hit this (and started digging further) -
> precisely because the non-Cygwin program I'm using _has_ called
> SetErrorMode and its direct calls to the faulty program _are_ doing
> what's wanted (no popup dialog) but the calls which happen via Cygwin
> are then torching that preference.
> 
> Not really suggesting it be done this way (it feels more complicated
> than just reverting the change), but in some ways perhaps Cygwin
> should be using GetErrorMode on startup and instead of not inheriting
> it, ensuring that it sets whatever it received? i.e. just before the
> call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> error mode (for that thread only) to the value read at startup, calls
> CreateProcess and then sets the error mode back.

This sounds like a good ide, but...

Is it actually a safe bet that the error mode set by SetThreadErrorMode
is then propagated as process error mode to the child process?

I have to ask that because Microsoft conveniently forgot to document
this scenario in the MSDN docs.


Corinna

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[David Allsopp]

On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
>
> On Feb  2 13:35, David Allsopp via Cygwin wrote:
> > Jon Turney via Cygwin wrote:
> >
> > > > I'm sympathetic, and personally I would prefer to revert the patch and
> > > > stick to SEM_FAILCRITICALERRORS by default.
> > > >
> > > > The question is this: Why does, apparently, everybody expect Cygwin to
> > > > do the "right thing", with different definitions of "right", when in
> > > > fact the executable in question can easily call SetErrorMode by itself?
> > >
> > > Yeah, if cygwin wasn't involved in the process ancestry, how would you
> > > get the behaviour you want?
> >
> > Ah, but that's how I hit this (and started digging further) -
> > precisely because the non-Cygwin program I'm using _has_ called
> > SetErrorMode and its direct calls to the faulty program _are_ doing
> > what's wanted (no popup dialog) but the calls which happen via Cygwin
> > are then torching that preference.
> >
> > Not really suggesting it be done this way (it feels more complicated
> > than just reverting the change), but in some ways perhaps Cygwin
> > should be using GetErrorMode on startup and instead of not inheriting
> > it, ensuring that it sets whatever it received? i.e. just before the
> > call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> > error mode (for that thread only) to the value read at startup, calls
> > CreateProcess and then sets the error mode back.
>
> This sounds like a good ide, but...
>
> Is it actually a safe bet that the error mode set by SetThreadErrorMode
> is then propagated as process error mode to the child process?
>
> I have to ask that because Microsoft conveniently forgot to document
> this scenario in the MSDN docs.

:o) Never knowingly clear, are they! It would seem to be the intent of
SetThreadErrorMode that it would behave that way but who knows.

Happy to set up a quick experiment to check that it does work (i.e.
the invoked process has GetErrorMode set as expected) and that there's
no possible race between two threads in the calling process with
differing values (i.e. that having SEM_FAILCRITICALERRORS in one
thread and not in another behaves as expected. If it does appear to
work consistently, would you be willing to go down this route? Happy
to do the patch, although it'd be very helpful to have a couple of
pointers: I'm guessing the value would want to be captured just before
the one place where SetErrorMode is already called, but in which
structure should it then be stashed away to be reused in spawn?


David

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen]

On Feb  2 14:56, David Allsopp via Cygwin wrote:
> On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > On Feb  2 13:35, David Allsopp via Cygwin wrote:
> > > Not really suggesting it be done this way (it feels more complicated
> > > than just reverting the change), but in some ways perhaps Cygwin
> > > should be using GetErrorMode on startup and instead of not inheriting
> > > it, ensuring that it sets whatever it received? i.e. just before the
> > > call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> > > error mode (for that thread only) to the value read at startup, calls
> > > CreateProcess and then sets the error mode back.
> >
> > This sounds like a good ide, but...
> >
> > Is it actually a safe bet that the error mode set by SetThreadErrorMode
> > is then propagated as process error mode to the child process?
> >
> > I have to ask that because Microsoft conveniently forgot to document
> > this scenario in the MSDN docs.
> 
> :o) Never knowingly clear, are they! It would seem to be the intent of
> SetThreadErrorMode that it would behave that way but who knows.
> 
> Happy to set up a quick experiment to check that it does work (i.e.
> the invoked process has GetErrorMode set as expected) and that there's
> no possible race between two threads in the calling process with
> differing values (i.e. that having SEM_FAILCRITICALERRORS in one
> thread and not in another behaves as expected. If it does appear to
> work consistently, would you be willing to go down this route? Happy
> to do the patch, although it'd be very helpful to have a couple of
> pointers: I'm guessing the value would want to be captured just before
> the one place where SetErrorMode is already called, but in which
> structure should it then be stashed away to be reused in spawn?

Wanna try this?  It ignores the case of starting a process
under another user account for now, but that can be added easily
if this proves to work as expected.

diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
index a40129c22232..f1017e69b6b2 100644
--- a/winsup/cygwin/dcrt0.cc
+++ b/winsup/cygwin/dcrt0.cc
@@ -718,7 +718,8 @@ dll_crt0_0 ()
   init_windows_system_directory ();
   initial_env ();
 
-  SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
+  orig_proc_error_mode = SetErrorMode (SEM_FAILCRITICALERRORS
+				       | SEM_NOGPFAULTERRORBOX);
 
   lock_process::init ();
   user_data->impure_ptr = _impure_ptr;
diff --git a/winsup/cygwin/globals.cc b/winsup/cygwin/globals.cc
index 885ada85e7b8..d2861ba98b42 100644
--- a/winsup/cygwin/globals.cc
+++ b/winsup/cygwin/globals.cc
@@ -28,6 +28,7 @@ PWCHAR windows_directory = windows_directory_buf + 4;
 UINT windows_directory_length;
 UNICODE_STRING windows_directory_path;
 WCHAR global_progname[NT_MAX_PATH];
+UINT orig_proc_error_mode;
 
 /* program exit the program */
 
diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc
index 8a2db5cf72e2..df83f25d13c6 100644
--- a/winsup/cygwin/spawn.cc
+++ b/winsup/cygwin/spawn.cc
@@ -648,6 +648,10 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv,
 	      && !::cygheap->user.groups.issetgroups ()
 	      && !::cygheap->user.setuid_to_restricted))
 	{
+	  UINT orig_thread_error_mode = SEM_FAILCRITICALERRORS
+					| SEM_NOGPFAULTERRORBOX;
+	  if (!iscygwin ())
+	    SetThreadErrorMode (orig_proc_error_mode, &orig_thread_error_mode);
 	  rc = CreateProcessW (runpath,		/* image name w/ full path */
 			       cmd.wcs (wcmd),	/* what was passed to exec */
 			       sa,		/* process security attrs */
@@ -658,6 +662,8 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv,
 			       NULL,
 			       &si,
 			       &pi);
+	  if (!iscygwin ())
+	    SetThreadErrorMode (orig_thread_error_mode, NULL);
 	}
       else
 	{

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen]

On Feb  2 18:22, Corinna Vinschen via Cygwin wrote:
> On Feb  2 14:56, David Allsopp via Cygwin wrote:
> > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > > On Feb  2 13:35, David Allsopp via Cygwin wrote:
> > > > Not really suggesting it be done this way (it feels more complicated
> > > > than just reverting the change), but in some ways perhaps Cygwin
> > > > should be using GetErrorMode on startup and instead of not inheriting
> > > > it, ensuring that it sets whatever it received? i.e. just before the
> > > > call to CreateProcess for a non-Cygwin binary, Cygwin restores the
> > > > error mode (for that thread only) to the value read at startup, calls
> > > > CreateProcess and then sets the error mode back.
> > >
> > > This sounds like a good ide, but...
> > >
> > > Is it actually a safe bet that the error mode set by SetThreadErrorMode
> > > is then propagated as process error mode to the child process?
> > >
> > > I have to ask that because Microsoft conveniently forgot to document
> > > this scenario in the MSDN docs.
> > 
> > :o) Never knowingly clear, are they! It would seem to be the intent of
> > SetThreadErrorMode that it would behave that way but who knows.
> > 
> > Happy to set up a quick experiment to check that it does work (i.e.
> > the invoked process has GetErrorMode set as expected) and that there's
> > no possible race between two threads in the calling process with
> > differing values (i.e. that having SEM_FAILCRITICALERRORS in one
> > thread and not in another behaves as expected. If it does appear to
> > work consistently, would you be willing to go down this route? Happy
> > to do the patch, although it'd be very helpful to have a couple of
> > pointers: I'm guessing the value would want to be captured just before
> > the one place where SetErrorMode is already called, but in which
> > structure should it then be stashed away to be reused in spawn?
> 
> Wanna try this?  It ignores the case of starting a process
> under another user account for now, but that can be added easily
> if this proves to work as expected.

During dinner it occured to me that I forgot to remove setting the
default error mode via CreateProcess.  So this patch would have
to be applied as well:

diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc
index 8a2db5cf72e2..2e0f0fcf2146 100644
--- a/winsup/cygwin/spawn.cc
+++ b/winsup/cygwin/spawn.cc
@@ -401,13 +401,6 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv,
 
       c_flags |= CREATE_SEPARATE_WOW_VDM | CREATE_UNICODE_ENVIRONMENT;
 
-      /* Add CREATE_DEFAULT_ERROR_MODE flag for non-Cygwin processes so they
-	 get the default error mode instead of inheriting the mode Cygwin
-	 uses.  This allows things like Windows Error Reporting/JIT debugging
-	 to work with processes launched from a Cygwin shell. */
-      if (!real_path.iscygexec ())
-	c_flags |= CREATE_DEFAULT_ERROR_MODE;
-
       /* We're adding the CREATE_BREAKAWAY_FROM_JOB flag here to workaround
 	 issues with the "Program Compatibility Assistant (PCA) Service".
 	 For some reason, when starting long running sessions from mintty(*),

However, it occured to me that this won't work at all.

Consider fork/exec.  In Windows terms, the forked process is a child
process started with CreateProcess.  The forked child is a Cygwin
process, so at DLL init time, it sets

  orig_proc_error_mode = SetErrorMode (SEM_FAILCRITICALERRORS
                                       | SEM_NOGPFAULTERRORBOX);

However, given the parent is always a Cygwin parent, orig_proc_error_mode
will always be SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX.

The following exec starting a non-Cygwin process will set the thread
error mode to the above value.  So any non-Cygwin process started from
your typical Cygwin process like bash, will always have the error mode
set to the same mode as any Cygwin application.

Ultimately this means, the effect is the same as if we had just reverted
commit 21ec498d7f912 ("cygwin: use CREATE_DEFAULT_ERROR_MODE in spawn").


Corinna

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen]

On Feb  2 19:51, Corinna Vinschen via Cygwin wrote:
> On Feb  2 18:22, Corinna Vinschen via Cygwin wrote:
> > On Feb  2 14:56, David Allsopp via Cygwin wrote:
> > > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > > > Is it actually a safe bet that the error mode set by SetThreadErrorMode
> > > > is then propagated as process error mode to the child process?
> > > >
> > > > I have to ask that because Microsoft conveniently forgot to document
> > > > this scenario in the MSDN docs.
> > > 
> > > :o) Never knowingly clear, are they! It would seem to be the intent of
> > > SetThreadErrorMode that it would behave that way but who knows.
> > > 
> > > Happy to set up a quick experiment to check that it does work (i.e.
> > > [...]
> > Wanna try this?
> [...]
> However, it occured to me that this won't work at all.
> [...]

Sorry to say that, but SetThreadErrorMode/CreateProcess don't do what we
want them to do.  I just tested this myself with a modified Cygwin DLL
(code below) and it turns out that the child process error mode is
the same as the parent's process error mode.  Changing the thread
error mode from the Cygwin default 3 (aka SEM_FAILCRITICALERRORS |
SEM_NOGPFAULTERRORBOX) to 0 doesn't have any effect.

Check the below Cygwin patch and look at output ("gem" is my MingW test
app just printing the process error mode retrieved via GetErrorMode):

  $ ./gem
	0 [main] dash 990 child_info_spawn::worker: 1 = SetThreadErrorMode (0, 0) GT:0 GP:3
    16158 [main] dash 990 child_info_spawn::worker: 1 = SetThreadErrorMode (3, 0)
  Error mode 0x3
  $

The terrible thing here is the output of the old thread error mode
from GetThreadErrorMode as well as from SetThreadErrorMode.

MSDN says:

  Each process has an associated error mode that indicates to the system
  how the application is going to respond to serious errors. A thread
  inherits the error mode of the process in which it is running. To
  retrieve the process error mode, use the GetErrorMode function. To
  retrieve the error mode of the calling thread, use the
  GetThreadErrorMode function.

What that means is, even though the process error mode is 3 , and even
though "A thread inherits the error mode of the process in which it is
running", GetThreadErrorMode/SetThreadErrorMode return a thread error
code of 0!!!

So if GetThreadErrorMode returns 0, you *have* to call GetErrorMode to
retrieve the *actual* thread error mode, because the thread error mode
just says "yo man, it's default".

In extension this probably *also* means, setting the thread error mode
to 0 does NOT mean "set it to system default" as MSDN claims, but it
means "set it to process default".

But in fact, even if I set a non-0 thread error mode, this has no effect
on the child process.  I forced the thread error mode to 1 before calling
CreateProcess, and the resulting child process error mode was still the
Cygwin process error mode 3.

Isn't that completely screwed up?

Ok, my Cygwin DLL test patch follows below.


Corinna


diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
index a40129c22232..14ba4e3769f1 100644
--- a/winsup/cygwin/dcrt0.cc
+++ b/winsup/cygwin/dcrt0.cc
@@ -718,7 +718,8 @@ dll_crt0_0 ()
   init_windows_system_directory ();
   initial_env ();
 
-  SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
+  UINT proc_error_mode = SetErrorMode (SEM_FAILCRITICALERRORS
+				       | SEM_NOGPFAULTERRORBOX);
 
   lock_process::init ();
   user_data->impure_ptr = _impure_ptr;
@@ -738,6 +739,13 @@ dll_crt0_0 ()
   if (!child_proc_info)
     {
       setup_cygheap ();
+      /* Memorize the original error mode when this Cygwin process
+	 has been called from a non-Cygwin process.  We restore to
+	 this error mode on spawning a non-Cygwin process.  This allows
+	 to set a non-default error mode prior to calling the first
+	 Cygwin process and forward it to any subsequent non-Cygwin
+	 child process at spawn time. */
+      cygheap->orig_proc_error_mode = proc_error_mode;
       memory_init ();
     }
   else
diff --git a/winsup/cygwin/local_includes/cygheap.h b/winsup/cygwin/local_includes/cygheap.h
index b6acdf7f18b7..02e3cb4621e3 100644
--- a/winsup/cygwin/local_includes/cygheap.h
+++ b/winsup/cygwin/local_includes/cygheap.h
@@ -517,6 +517,7 @@ struct init_cygheap: public mini_cygheap
   mode_t umask;
   LONG rlim_as_id;
   unsigned long rlim_core;
+  UINT orig_proc_error_mode; /* Set when started from non-Cygwin process */
   HANDLE console_h;
   cwdstuff cwd;
   dtable fdtab;
diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc
index 8a2db5cf72e2..85dbec431b28 100644
--- a/winsup/cygwin/spawn.cc
+++ b/winsup/cygwin/spawn.cc
@@ -401,13 +401,6 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv,
 
       c_flags |= CREATE_SEPARATE_WOW_VDM | CREATE_UNICODE_ENVIRONMENT;
 
-      /* Add CREATE_DEFAULT_ERROR_MODE flag for non-Cygwin processes so they
-	 get the default error mode instead of inheriting the mode Cygwin
-	 uses.  This allows things like Windows Error Reporting/JIT debugging
-	 to work with processes launched from a Cygwin shell. */
-      if (!real_path.iscygexec ())
-	c_flags |= CREATE_DEFAULT_ERROR_MODE;
-
       /* We're adding the CREATE_BREAKAWAY_FROM_JOB flag here to workaround
 	 issues with the "Program Compatibility Assistant (PCA) Service".
 	 For some reason, when starting long running sessions from mintty(*),
@@ -648,6 +641,17 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv,
 	      && !::cygheap->user.groups.issetgroups ()
 	      && !::cygheap->user.setuid_to_restricted))
 	{
+	  if (!iscygwin ())
+	    {
+	      UINT old, old2, old3;
+	      BOOL ret;
+
+	      old2 = GetThreadErrorMode ();
+	      old3 = GetErrorMode ();
+	      ret = SetThreadErrorMode (cygheap->orig_proc_error_mode, &old);
+	      system_printf ("%d = SetThreadErrorMode (%u, %u) GT:%u GP:%u\r\n",
+			     ret, cygheap->orig_proc_error_mode, old, old2, old3);
+	    }
 	  rc = CreateProcessW (runpath,		/* image name w/ full path */
 			       cmd.wcs (wcmd),	/* what was passed to exec */
 			       sa,		/* process security attrs */
@@ -658,6 +662,19 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv,
 			       NULL,
 			       &si,
 			       &pi);
+	  if (!iscygwin ())
+	    {
+	      UINT old;
+	      BOOL ret;
+
+	      ret = SetThreadErrorMode (SEM_FAILCRITICALERRORS
+					| SEM_NOGPFAULTERRORBOX,
+					&old);
+	      system_printf ("%d = SetThreadErrorMode (%u, %u)\r\n",
+			     ret,
+			     SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX,
+			     old);
+	    }
 	}
       else
 	{

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Jeremy Drake]

On Fri, 2 Feb 2024, Corinna Vinschen wrote:

> On Feb  2 09:43, David Allsopp via Cygwin wrote:
> > However, this patch came from MSYS2, and subsequently they seem to
> > have found it problematic for the same reason as me
> > (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624)
> > and have just recently reintroduced the flag
> > (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50)
> > to control it.
> >
> > The reasoning in
> > https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as
> > valid now as it did in 2006.
> >
> > Is it possible to revisit having the flag, or even just reverting the behaviour?
> >
>
> I'm sympathetic, and personally I would prefer to revert the patch and
> stick to SEM_FAILCRITICALERRORS by default.
>
> The question is this: Why does, apparently, everybody expect Cygwin to
> do the "right thing", with different definitions of "right", when in
> fact the executable in question can easily call SetErrorMode by itself?

The different definitions of "right" is the reason the flag/option was
re-added in MSYS2.  I think the most "right" thing Cygwin could do (if it
were to only do one thing, rather than having an option) would be to
somehow have native processes inherit the error mode as though Cygwin were
not in the mix.  The issue with that, as you've seen, is that there are
any number of Cygwin processes in the hierarchy.

As far as the executable being able to call SetErrorMode itself, that
would be OK except for when the error is coming from the loader, before
anything from the executable is run (such as for missing DLL or missing
export from DLL).

I do like the idea of a native Windows program like "nohup" that sets the
error mode and then runs a subprocess.  Why doesn't Windows come with
something like that? ;)

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[Corinna Vinschen]

On Feb  3 13:39, Corinna Vinschen via Cygwin wrote:
> On Feb  2 19:51, Corinna Vinschen via Cygwin wrote:
> > On Feb  2 18:22, Corinna Vinschen via Cygwin wrote:
> > > On Feb  2 14:56, David Allsopp via Cygwin wrote:
> > > > On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
> > > > > Is it actually a safe bet that the error mode set by SetThreadErrorMode
> > > > > is then propagated as process error mode to the child process?
> > > > >
> > > > > I have to ask that because Microsoft conveniently forgot to document
> > > > > this scenario in the MSDN docs.
> > > > 
> > > > :o) Never knowingly clear, are they! It would seem to be the intent of
> > > > SetThreadErrorMode that it would behave that way but who knows.
> > > > 
> > > > Happy to set up a quick experiment to check that it does work (i.e.
> > > > [...]
> > > Wanna try this?
> > [...]
> > However, it occured to me that this won't work at all.
> > [...]
> 
> Sorry to say that, but SetThreadErrorMode/CreateProcess don't do what we
> want them to do.  I just tested this myself with a modified Cygwin DLL
> (code below) and it turns out that the child process error mode is
> the same as the parent's process error mode.  Changing the thread
> error mode from the Cygwin default 3 (aka SEM_FAILCRITICALERRORS |
> SEM_NOGPFAULTERRORBOX) to 0 doesn't have any effect.
> [...etc.]

MSYS2 has introduced the environment variable option CYGWIN=winjitdebug.
I backported this patch now.  So default is back to propagating Cygwin's
error mode and if you want to reset the error mode of a non-Cygwin child
process back to OS default, just set the option, for instance, like
this:

  $ CYGWIN=winjitdebug env <your-non-Cygwin.exe>

This patch will be in Cygwin 3.5.1.  For the time being, it will be
available in the next test release cygwin-3.6.0-0.28.g918c3eda4176 as
well.


HTH,
Corinna

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

[David Allsopp]

On Sat, 3 Feb 2024 at 19:25, Corinna Vinschen wrote:
> > Sorry to say that, but SetThreadErrorMode/CreateProcess don't do what we
> > want them to do.  I just tested this myself with a modified Cygwin DLL
> > (code below) and it turns out that the child process error mode is
> > the same as the parent's process error mode.  Changing the thread
> > error mode from the Cygwin default 3 (aka SEM_FAILCRITICALERRORS |
> > SEM_NOGPFAULTERRORBOX) to 0 doesn't have any effect.
> > [...etc.]

Oh dear, what a mess!

> MSYS2 has introduced the environment variable option CYGWIN=winjitdebug.
> I backported this patch now.  So default is back to propagating Cygwin's
> error mode and if you want to reset the error mode of a non-Cygwin child
> process back to OS default, just set the option, for instance, like
> this:
>
>   $ CYGWIN=winjitdebug env <your-non-Cygwin.exe>
>
> This patch will be in Cygwin 3.5.1.  For the time being, it will be
> available in the next test release cygwin-3.6.0-0.28.g918c3eda4176 as
> well.

This completely fixes it for us, thank you very much

Thanks,


David